Advanced iPXE script

[Sebastian Roth]

@Tom-Elliott, @Developers, @Moderators
I got carried away trying to improve the current iPXE script. Now that I’ve dug into the syntax and found some interesting new stuff I want to see what you guys think about this:

#!ipxe
isset ${net0/mac} && dhcp net0 || goto dhcpnet1
echo Received DHCP answer on interface net0 && goto proxycheck

:dhcpnet1
isset ${net1/mac} && dhcp net1 || goto dhcperror
echo Received DHCP answer on interface net1 && goto proxycheck

:dhcperror
prompt --key s --timeout 10000 DHCP failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

:proxycheck
isset ${proxydhcp/next-server} && isset ${next-server} && echo Duplicate option 66 (next server) from DHCP proxy and DHCP server && echo Using IP sent by DHCP proxy ${proxydhcp/next-server} && prompt --timeout 5000 || goto nextservercheck

:nextservercheck
isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} ||
isset ${next-server} && goto netboot || goto setserv

:setserv
echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv

:netboot
chain tftp://${next-server}/default.ipxe ||
prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

Feel free to comment and improve. I’ve tested the script and tried to remember all the issues I came across in the last months but I am sure we’re not there yet.

[Tom Elliott]

@Sebastian-Roth said:

#!ipxe
isset ${net0/mac} && dhcp net0 || goto dhcpnet1
echo Received DHCP answer on interface net0 && goto proxycheck

:dhcpnet1
isset ${net1/mac} && dhcp net1 || goto dhcperror
echo Received DHCP answer on interface net1 && goto proxycheck

:dhcperror
prompt --key s --timeout 10000 DHCP failed, hit ‘s’ for the iPXE shell; reboot in 10 seconds && shell || reboot

:proxycheck
isset ${proxydhcp/next-server} && isset ${next-server} && echo Duplicate option 66 (next server) from DHCP proxy and DHCP server && echo Using IP sent by DHCP proxy ${proxydhcp/next-server} && prompt --timeout 5000 || goto nextservercheck

:nextservercheck
isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} ||
isset ${next-server} && goto netboot || goto setserv

:setserv
echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv

:netboot
chain tftp://${next-server}/default.ipxe ||
prompt --key s --timeout 10000 Chainloading failed, hit ‘s’ for the iPXE shell; reboot in 10 seconds && shell || reboot

I like it and feel this should be amazing. And more informative to boot.

If others don’t like it I can revert if needed, but I think more info is better.

Thank you.

[Tom Elliott]

In simpler terms, I added it

[Jean-Jacques Morda]

In my case, i have severals DHCP on my network and this script (i suppose) make the ipxe boot taking the wrong dhcp server and trying to boot on it. You can see here the dhcp is swapping between 172.31.43.1 and 172.31.37.252. Each time i restart the fog isc dhcp server, it took the good one but each time i reboot the client, 1/2 chance the iPxe took the wrong one because my other dhcp is responding. Is that strange ?

[Sebastian Roth]

@Jean-Jacques-Morda Why do you have more than one DHCP server in your network? And why do they offer different information (next-server/option 66) to the clients. This is not strange but kind of expected and it just does not make any sense to me why you would want to have this.

[Wayne Workman]

@Jean-Jacques-Morda said:

In my case, i have severals DHCP on my network and this script (i suppose) make the ipxe boot taking the wrong dhcp server and trying to boot on it. You can see here the dhcp is swapping between 172.31.43.1 and 172.31.37.252. Each time i restart the fog isc dhcp server, it took the good one but each time i reboot the client, 1/2 chance the iPxe took the wrong one because my other dhcp is responding. Is that strange ?

If you already have another DHCP service, configure that one and turn fog’s DHCP off - or - turn off the other DHCP service, and just use FOG’s DHCP.

If you don’t have split-scope configured correctly, you cannot run two DHCP services on the same broadcast domain anyways. You’ll have IP conflicts like crazy.