Dell Latitude 5410 - boot.php timeout
-
@tom-elliott I hit ‘s’ to access iPXE shell after boot.php timeout, typed in http command found in default.ipxe and was able to reach boot.php.
Default.ipxe contents:
#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch ${buildarch}
params
param mac0 ${net0/mac}
param arch ${arch}
param platform ${platform}
param product ${product}
param manufacturer ${product}
param ipxever ${version}
param filename ${filename}
param sysuuid ${uuid}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain http://10.20.164.94/fog/service/ipxe/boot.php##params -
@cmachado said in Dell Latitude 5410 - boot.php timeout:
I hit ‘s’ to access iPXE shell after boot.php timeout, typed in http command found in default.ipxe and was able to reach boot.php.
So it does work after a certain amount of time by the look of things. You can try Tom’s suggestion and use a dumb mini switch to connect the problematic system to see if the issue goes away or use the iPXE binaries with delay. Find those in /tftpboot/10secdelay folder on your FOG server.
-
@sebastian-roth Nope. It’s still an issue. I’m just demonstrating after boot.php timeout I can reach the http address manually from ipxe shell. So port 80 isn’t blocked but for some reason it times out.
-
@cmachado Exactly as I said, it works but only after waiting for some kind of delay…
-
This post is deleted! -
@cmachado There are 10secdelay files within the /tftpboot/10secdelay folder. You can try to use the ipxe.efi file from this subfolder:
Change file from ipxe.efi to 10secdelay/ipxe.efi (however that’s handled)
-
@tom-elliott bummer no luck. The NIC activity lights have continuous blinking during the http chaining. Would this indicate it’s not sleeping?
-
@cmachado said in Dell Latitude 5410 - boot.php timeout:
bummer no luck.
Do you actually see a difference when using the 10secdelay iPXE binary? I mean, do you see it wait for some time before it tries to get an IP from the DHCP and chainload to boot.php? Should also see the message “Sleeping 10 seconds to wait for STP/Powersave to switchoff and on” on screen, right?
If you see that message but it still doesn’t work you might want to try customizing your
/tftpboot/default.ipxe
file to wait before querying boot.php. Sounds kind of weird but from what you told us so far it sounds as if this might help with the Dell Latitude 5410. Edit that file on your FOG server and add a line withsleep 30
above the last line where it chainloads to boot.php. -
@sebastian-roth Prior to NIC configuring it states Sleeping 10 seconds to wait for STP/Powersave to switchoff and on
-
@cmachado I just updated my last post…
-
From what I’m finding this may be a router issue. I created a VM FOG server on VLAN 192, connected the client to the same VLAN and successfully PXE booted. When I plugged in the client to VLAN 194, PXE times out on http again. Are there any suggestions to resolve this?
I saw in this post https://forums.fogproject.org/topic/12368/fog-dhcp-server-on-multiple-vlan-network/4 mention of properly configuring Windows 2012 DHCP by Goerge1421. He also mentioned PXE roms may be an issue.
"Lets take a step back here. With such a complex network why are you using the FOG DHCP server instead of your network infrastructure dhcp servers?
FOG does work across subnets, what you need is the dhcp server responsible for those other subnets to set dhcp option 66 to the fog server IP and dhcp option 67 to the boot kernel. The issue you will run into now is that if you have both bios and uefi systems on your network, your dhcp server will need to be smart enough to send the right boot kernel name based on the target hardware. Windows dhcp on 2012 and newer will do this correctly if configured right. Linux dhcp server does that automatically like FOG uses.
If you have inter vlan routing working correctly, you can/should be able to image with FOG. There are some pxe roms that are not very smart and may not like pxe booting across subnets.
Instead of messing with all of these dhcp helpers, you should take a step back and answer what device provides your dhcp services for these other subnets?"