Dell Latitude 5410 - boot.php timeout

[cmachado]

@sebastian-roth It’s not that I don’t want to, rather I have time restraints. We have a large environment running 10 nodes and I usually run into DB issues when upgrading. Perhaps I’m not upgrading in the correct manner? What’s best practice? The main server is a VM so I have lots of flexibility.

[cmachado]

@sebastian-roth I just updated to 1.5.9 and getting same issue. Still works on older Dell PCs. Also, updated kernel to version 5.10.34.

[Tom Elliott]

@cmachado Can you ensure the 5410 is on the exact same network as the other machines that seem to work?

The message seems to indicate the connection is timed out. This makes me think it’s a Firewall issue between the 5410 connecting network and the fog server. It’s not having an issue with the ipxe files. It’s literally having an issue connecting to the http side of things.

[cmachado]

@tom-elliott The other machine is on the same subnet. I have it plugged into the same switch as the nonworking devices. This also occurs on Dell AIO 7490 and later release than the working Dell 7450 AIO.

[cmachado]

@tom-elliott Here is the 7450.

[cmachado]

@tom-elliott 7450 iPXE config

7490 iPXE config

[Tom Elliott]

@cmachado Do you have a dumb switch that you could put between the machine and the server? It almost seems like the nic could be powering off, so my thoughts:

Machine:

Boots
PXE
iPXE
Gets tftp and in-between this shuts down before attempting to get http.

So from what I can tell, everything is working up until the switchover from TFTP to HTTP.

Maybe these machines have a powersaving nic mode that is causing the request to timeout?

[cmachado]

@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

[Sebastian Roth]

@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.

[cmachado]

@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.

[Sebastian Roth]

@cmachado Exactly as I said, it works but only after waiting for some kind of delay…

[cmachado]

This post is deleted!

[Tom Elliott]

@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)

[cmachado]

@tom-elliott bummer no luck. The NIC activity lights have continuous blinking during the http chaining. Would this indicate it’s not sleeping?

[Sebastian Roth]

@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 with sleep 30 above the last line where it chainloads to boot.php.

[cmachado]

@sebastian-roth Prior to NIC configuring it states Sleeping 10 seconds to wait for STP/Powersave to switchoff and on

[Sebastian Roth]

@cmachado I just updated my last post…

[cmachado]

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?"