@noelpd said in HP 210 Netbook (RealTek NIC) - DHCP Failed on PXE Boot:

So rebuilding a custom bzImage file will not effect it at all

No it won’t

The typical flow is PXE ROM -> tftpserver -> iPXE kernel (what you see in the OP post, and why the iPXE error message) -> FOG httpserver -> bzImage + init.xz (FOS image)

The issue is for some reason iPXE can find the nic (no problem) but it can’t pick up a dhcp address. To me this still screams of being a spanning tree issue, but you have tested otherwise.

Thanks for the suggestions! All our other systems are imaging just fine. I Dell has some kinks to work out with this system. When I try to PXE boot with the drive in AHCI mode the system hangs at a black screen and doesn’t even attempt to boot.

@drc0nc Thanks! Definitely worth a shot for $11

@oraniko can you update to 1.3.5 and see if the problem is still present?

Hi there,

same Problem…

Z400 - BIOS-Version: 7G3_0357 / 19. Nov. 2013
FOG-Version: 1.3.5

I just added to Host:
Host Kernel Arguments: “acpi=off”

Worked for me 😉

BR
Beekay

Many thanks george1421 . The FOS method worked. I was able to capture the image finally 🙂 Case closed.

Some posts showing FOG is capable of using these particular machines, but the users are using new versions (beyond 1.2.0) of FOG.

https://forums.fogproject.org/topic/8902/dell-optiplex-5040-m-2-256gb-pcie-nvme-class-40-solid-state-drive
https://forums.fogproject.org/topic/6686/can-t-register-optiplex-5040-tsc-fast-tsc-calibration-failed
https://forums.fogproject.org/topic/7443/0-10-6-client-breaking-sysprep
https://forums.fogproject.org/topic/7759/pxe-chaining-fails-on-ssd/7
https://forums.fogproject.org/topic/9587/blinking-cursor-after-booting-from-hard-drive-in-fog-menu-on-optiplex-5040s

Glad I took two different kind of images.

Single disk clone - Went through the process, on boot the file I created was still there, the only difference was it had uninstalled a lot of the drivers such as the NIC…

Multiple partition clone - Seems to have worked!

Thanks again for the help guys, much appreciated

@george1421 You’re absolutely right, thanks a lot. I upgraded to Ubuntu 14.04 / fog 1.3.4 and can boot and run the inventory on Lenovo T560 with Kernel 4.4.0 and 4.9.11

@daniell Try downgrading one system first, this will ensure it is indeed a problem with the firmware or not.

Unfortunately there’s not much we can do to fix it. Did you try seeing if the “legacy usb mode” was enabled/disabled?

@Tom-Elliott
Thanks for the info Tom.

Yes the firmware is up to date.
Bios N75 Ver 01.13 11/01/2016

Although older, I can confirm the Dell Poweredge R410 runs CentOS 7 just fine. It runs VMs like a champ using the Linux kernel’s built-in virtualization capabilities.

We are over some tests at last. As you suggested I did the following:

used a total dumb “link” between the pc and the network (hub): no change, still no boot properly I used undionly.kkpxe and ipxe.pxe one by one. unfortunatelly no change.

Still no change, that means this hardware has somehow problems. Any other suggestion maybe? The problem is that we will surely get such hw, so it would be good to have a workaround somehow. Ah, one more thing. ipxe.pxe file gave a little difference. It said during boot that it boots from SAN device. Does it changes a thing?

@SDToone Clear screen shots of the errors would help to set the context of the error you see.

@Tom-Elliott Great stuff! Yeah from what I see in those MS surface posts it was only the CDC -ether driver causing the issue. Keeping my fingers crossed…

@falko I’ve generally had no problems with Lenovo & FOG overall. Can’t speak to this particular model. Figure out what chipset the NIC uses if you can, and research linux support for that chipset.

@jjacobs said in Dell 7040 NVMe SSD Boot Issue:

@george1421, no we are using the legacy mode, i didn’t knew that the uefi mode worked in Fog 🙂

OK thanks for clearing that up.

Yes, uefi (working well) and nvme disks were added in an early 1.2.0 trunk release of FOG. With FOG 1.3.x both are fully supported and work very well. UEFI (EFI) is here to stay so its either support or die. Many new systems are coming uefi only (i.e. MS Surface Pro)

@chief Ok if you put a dumb switch in between the target computer and building switch and it resolved the problem. Then its probably one of the advanced protocols causing the issue.

This is typically spanning tree being enabled and not using one of the fast stp protocols.

Or you have green ethernet (802.3az) enabled on the building switch. We’ve seen this to be an issue with some realtek nics.

@fritoss007 Then you might be better doing the fixparts methodology. Now I’ve added postinitscripts to the working branch data so things should be able to be automated much more nicely for those 18 or so systems you’re seeing with this issue. (You can add checks to get things working how you need it).