Some machines won't boot to Fog menu
-
@SBodager try
undionly.kkpxe
first as the filename.I’ll give you a better configuration tonight to support more stuff.
Also, do the tests that @george1421 posted - based on the outcome of that we will know for certain if it is or isn’t a network issue. Don’t assume it’s not, test and know.
-
Thank you for the info. I am looking into this but the machine is in another location so it is taking me some time to get the time to get out there.
-
I’m too having this same problem. Client machines fail to boot to FOG mneu about 40% and if they reboot the 2nd time the failure rate usually go down to 10%. However, if I hit “s” and then type “autoboot” at the prompt, they are able to get to FOG menu. I’ve spoken with our network admins and they said that nothing has changed in their switches configuration in a few years. This only happened recently when I upgraded FOG to 1.3.3 and 1.3.4. Is there anyway we can delay FOG or speed up iPXE?
-
@TaTa we have 10 second delayed ipxe files that would likely fit the bill for your systems.
While the network, itself, may not have changed, I’m willing to guess that the systems having problems are relatively new?
-
@SBodager You can also try the 10 second delay files. These were created for cases exactly such as this.
-
@Tom-Elliott Where can I get it?
They are old systems. Some as old as 5 yrs others about 3 years. -
Thanks @Tom-Elliott I saw the folder. Sorry for being lazy. I’ll try it out and report back.
-
@Tom-Elliott Thank you. Are the 10-second delay files the .kkpxe files? I’m new to all this, since the guys who set it up are no longer with the company I’m being pressed into learning it on my own.
-
@SBodager In theory (I only say that because I haven’t personally tested it). You can change your dhcp option 67 to
10secdelay/undionly.kpxe
or what ever boot file you need.But to answer your question they 10 second delay files are on the FOG server in /tftpboot/10secdelay
-
@SBodager That seems to have fixed the issue for the physical machines that were having issues but not the vm’s