DHCP Lease Failing
-
@Brenth453 I guess I should have been a bit clearer. I was asking for a clear picture of the error screen taken with a mobile phone. That will allow us to view the context of the error, not just the error message.
But can you think of a reason why a computer on the same subnet as the pxe booting computer, couldn’t reach the url page displayed on that error screen?
The other thought that comes to mind is that you have spanning tree enabled, but you are not running one of the fast spanning tree protocols. Normally this issue should have presented itself earlier in the booting process, but its also possible to impact this spot too. One quick test is to place a sumb (unmanged) switch between the building switch and the pxe booting computer. If the computer boots into FOS correctly then it is a networking infrastructure issue.
-
-
@Brenth453 OK can you place a dumb switch between the pxe booting computer and the building switch, or confirm that your building switch has fast spanning tree enabled?
-
@george1421 All switches have FastPort Active. Spanning tree status is running in rapid-pvst.
-
@george1421 I feel the need to add that I can do it to a virtual machine just fine. No trouble getting the lease.
-
@george1421 Wireshark traffic shows pxe file pulling just fine. TFTP being reached through network. Confused as to why the DHCP isn’t pulling.
-
@Brenth453 Well there are only a handful of reasons for it to fail here.
- The dhcp server can’t be reached
- The FOG server url can’t be reached from that subnet
- FOS does not support the network adapter used
I’m kind of going to rule out #1, since the device is pxe booting and starting FOS. Typically a spanning tree issue will show up where iPXE can’t get an IP address. But it has happened at this point too.
For #2. You should confirm that you can reach the URL defined in the error screen from a computer on the same subnet as the pxe booting computer so we can rule out any kind of screening router blocking the call to the fog server.
For #3, this one is going to be a bit harder to diagnose, but its surely possible.
- Manually register this device.
- Go in and schedule an image deployment or capture to this device (no worries because we are not going to do either). But before you submit the task, tick the check box that says debug.
- PXE boot the target computer. It should jump into FOS right away. You may see the same warnings about IP address, but FOS will contine.
- After several enter key presses and pages of text FOS should drop you to a linux command prompt. At that command prompt key in
ip addr show - If you get an IP address then try to ping the fog server.
- If you don’t get an ip address then we will need to dig into what hardware you are using.
-
-
@george1421 Using an HP Prodesk 400 G4
-
@Brenth453 OK it looks like eth0 is not getting an ip address.
At the FOS command prompt lets try.
udhcpc -i eth0then wait until it completes then run theip addr showcommand and see if eth0 picks up an IP address. This is going to tell us if time fixes the issue- If that doesn’t work then lets find out what network adapter is installed in that system
lspci -nn |grep etwork
-
@george1421 after doing step 1.
-
@Brenth453 Well that IS telling us time IS correcting your issue. I’m still thinking spanning tree here.
Interesting that lspci is not returning… Ugh, I’m a fool. its
lspci -nn|grep thernetnot network.But back on point, do you have a dumb (unmanaged) switch to place between your pxe booting computer and building switch. Then pxe boot the computer. Lets see if that masks the issue.
-
@george1421 If spanning tree is the issue though what needs to be different if RSTP is enabled and we even went as far as setting an IP helper. Sorry this image refuses to rotate.
-
@Brenth453 IP helper is not the issue here. RSTP is one of the right answers. But again try a dumb switch. Because we know that time fixes being able to get an IP address.
Eventhough your image was rotated I got the number I needed [10ec:8168] “Realtek 8169”. FOS Supports that network adapter.
-
@george1421 Tried a dumb switch. Cannot get it to PXE boot through a dumb switch.
-
@Brenth453 Well I have to admit you have me stumped on this one.
Is the fog server on the same subnet as the pxe booting client? If so we can use the fog server to do collect a pcap of the boot up sequence. If not then we can use wireshark to at least see the dhcp bits since they are sent out broadcast.
For the FOG server we can use this tutorial: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
For wireshark use the capture filter of
port 67 or port 68to only collect dhcp communications. I would prefer to use the FOG server because then we will get the unicast communications between the pxe booting client and the fog server, wireshark will only see the broadcast messages unless you are on a mirrored port.Post the results of the pcap here (or DM me a link to the file on a google drive) and I’ll take a look at it.
-
@george1421 So we have gotten somewhere. I have the image uploaded and am attempting to deploy to another machine of the same model.
-
@Brenth453 is the disk you’re deploying to smaller than the disk that was captured from?
-
@Tom-Elliott Yes it does unfortunately. I’m assuming the image deploy works from smaller hard drives onto larger ones? If it does then I could probably capture an image off of this and then deploy to the other one.
-
@Tom-Elliott I am going to capture another image and set it to single disk resizable. I am getting an error though about “The disk contains an unclean file system.”
