Chainloading failed, hit 's'
-
Hi,
im using current dev version of fog 1.5.9.246 as cloning solution… im getting this error for some models of pcs (for example HP EliteDesk 800 G1 usdt, and for MS hyperv virtual machine). Most other PCs boot fine.
any ideas?
-
@dugi007 This boot sequence doesn’t look right.
The top part of the screen, it appears you are using dnsmasq for dhcp services (Auto-select: Boot to FOG) and IP gateway of 192.168.1.1. But then we see in the ipxe section that its trying to get default.ipxe from 192.168.1.1, from your gateway? That should be your fog server not your router.
You need to describe how you have things setup.
What device is 192.168.1.1
What device is 192.168.1.232
What device is your dhcp server?
Are you using dnsmasq for some reason?
Is this network using a home router for dhcp?
Is it possible you have more than one dhcp server on your network? -
Hi George, tnx for answer.
192.168.1.1 is gateway/router/dhcp (mikrotik device configured BY ISP)
192.168.1.232 is fog server
im using dnsmasq as i dont have access to dhcp server
there arent more than one dhcp server on network.Interesting thing is that problem occurs on every HP 800 G1 USDT (tried with 10+ pcs), but for most other devices everything works just fine.
“But then we see in the ipxe section that its trying to get default.ipxe from 192.168.1.1, from your gateway? That should be your fog server not your router.”
i noticed this, and checked dnsmasq conf file but everything looks fine (im using config from: https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq)
-
@dugi007 This is strange. Your bios sees the proxy dhcp response because it displays the dnsmasq stuff. But for some reason iPXE is not seeing/hearing the dnsmasq response.
Many soho routers will send their IP address as the boot server IP address for some silly reason. That appears to be what is happening in your case. What should happen is dnsmasq should send out a proxydhcp response that will override what the dhcp server is telling the client. I don’t understand why in your environment the target computer is not hearing that second dnsmasq response.
Is this problem with one specific hardware or are all target computes doing this?
Lets have you post your ltsp.conf configuration here so I can look at it. -
i would agree, but the issue started occuring after i upgraded from older version 1.5.x to 1.5.9 (we also changed switch but i dont see if that could have any impact).
issue occurs with every peace of the same model but works good with all other different vendors and/or models…
ltsp.conf:
-
@dugi007 OK what I want you to do because the FOG server and pxe booting computer is on the same subnet. I want you to use the fog server to do a packet capture of the failing pxe booting process. I have the workflow outlined here: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue?_=1677536165233
Upload the pcap to a file share and either post the link here or DM me using FOG IM and I will take a look at it. The pcap will show us what is flying down the wire in regards to pxe booting. There has to be something going on here. I need the entire pcap file and not a screen shot of the pcap.
Your dnsmasq configuration looks good so we can probably rule out a misconfiguration error here.
-
Hi George,
please find output.pcap on dropbox link:
https://www.dropbox.com/s/wqxupwibwew9m66/output.pcap?dl=0Tnx!
-
@dugi007 Well I see what its doing but not sure why. With DHCP there is a process called D O R A (Discover, Offer, Request, ACK).
If you look at the picture below, the section above the green bar is the initial download of the iPXE boot loader. You see an Discover sent out by the target computer, two offers once from your dhcp server and one from dnsmasq. Then a request from the client and finally an ACK from your dhcp server. After that you see two proxy dhcp packets where the client computer asks dnsmasq about the boot info. And finally the download of undionly.kpxe from the fog server. This is what I would call a perfect pxe boot sequence.
Then below the greenbar is when iPXE starts up sends a discover, the dhcp server sends an offer, the client sends a request ahd dhcp server sends an ack. But dnsmasq is late to the party because by the time it sends hey I have some info too,its too late in time. BUT the issue is the client (iPXE) didn’t wait to see if it would get any more offers before it just took the first answer and ran with it.
So if I had to point fingers, I would say its iPXE at the root of the issue, but the question is why, and only on this one hardware.
I guess lets start out by having you recompile iPXE and installing it using this tutorial: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe?_=1677581355219 My confidence level is below 50% on if this will solve the problem. Its not a bad idea to have the latest iPXE version on your fog server, but I’m not confident that it will solve the problem.
What hardware is this one that is using bios mode (in 2023). I don’t recognize the hardware ID of this device.
-
@george1421 said in Chainloading failed, hit ‘s’:
So if I had to point fingers, I would say its iPXE at the root of the issue, but the question is why, and only on this one hardware.
Maybe try a different iPXE binary as well as compiling the latest version (as suggested by George), like
ipxe.pxe, in your dnsmasq config. -
@dugi007 Did you get this solved? Do you still need further help on this?
