DHCP Lease Failing

[george1421]

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

[Brenth453]

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

[george1421]

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

[Brenth453]

@george1421 Tried a dumb switch. Cannot get it to PXE boot through a dumb switch.

[george1421]

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

[Brenth453]

@george1421 So we have gotten somewhere. I have the image uploaded and am attempting to deploy to another machine of the same model.

[Tom Elliott]

@Brenth453 is the disk you’re deploying to smaller than the disk that was captured from?

[Brenth453]

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

[Brenth453]

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

[Tom Elliott]

@Brenth453 resizable will be better. I can’t guarantee it’ll work.

[Brenth453]

@Tom-Elliott How do you tell fog to only image the C drive? I can’t use single disk unless I specify the correct disk to capture an image of.

[rmontagne]

Hi guys,

I have the same error, on a new fog server.

Regards,

[Brenth453]

@Brenth453 I was able to use a router as DHCP and it worked flawlessly. Windows is just a flat out sketchy DHCP.

[Brenth453]

@Tom-Elliott Deployed from smaller hard drive image to larger hard drive. Computer is stuck preparing automatic repair and infinite reboots.

[Sebastian Roth]

@Brenth453 I am marking this solved as the initial question indeed is. Please feel free to open a new thread if you still have problems with infinite reboots after deploying to a larger disk.

[totoro]

@Brenth453
I have the same problem with a HP Prodesk 400 G3, I make a Bios update and the problem is gone .

Hop it’s can help.

I think using a different kernel can help too.

[totoro]

Hi again.

Today I need to install some HP Prodesk 400 G4
And the problem come back in both mod (uefi and legacy) I try to check for a Bios update, and I done it but the problem steal here.

I already try with a old no managed dumb switch.

In my case I make a upgrade from 1.4.4 to 1.5.5 it was working like a charm with the 1.4.4. Now I have this problem with the 1.5.5.

Any idea ?