dhcp failed on HP prodesk 400 G2

[goempie]

We have different hp desktop’s one type of desktops won’t boot to the fogserver.
Allready updated the bios, but nothing changed. The prodesk 600 boot perfectly to the server.

[george1421]

We’ll need a bit more infromation to know how things are installed.

1. What version of FOG are you using (look for the numbers on the cloud on the management gui home page). \
2. From your post, it sounds like you have other systems that do boot correctly?
3. Is this computer booting in uefi or bios mode? (I think I know the answer already)
4. What switch is this device plugged into (manufacturer and model)

If you have a dumb (unmanged switch), just as a test insert it between the building switch and this target computer. See if it can pick up a dhcp address in this configuration. IF it does, then we have a solid direction to move in.

Just saying: Ugh its another realtek nic

[goempie]

1. I’m using the latest fog version updated this morning through git
   You are currently running version: 7254

2. Yes i have allready imaged multiple computers, and they where all done on the same port.

3. I think in bios mode, i’m not shure about this, allready searched the bios but can’t find a setting to change

4. Can’t tell the exact make and model.

[george1421]

@goempie

ok for grins please put an unmanaged switch between your building switch and this computer. The issue here (I think is your spanning tree setup) is that as the booting process transitions from the PXE ROM to iPXE the network link (winks) as the iPXE kernel starts and takes over the network adapter. If spanning tree is enabled but you don’t have RSTP or portfast it may take up to 27 seconds for the switch port to go into the forwarding state. If this was the case I might expect your other systems to have a similar issue. The other thing we are seeing is that some switches and network adapters support green ethernet 802.1az. This also cause dhcp issues because of the network wink. Putting an unmanaged switch in between breaks the 802.1az handshake plus keeps the building switch port from transitioning as the target boots through the stages.

Understand this is only a test to see if we can narrow in on the root of the problem. You may need to get your networking group involved if we can prove this out.

[goempie]

@george1421 Nope just tested with a dumb switch and it’s exactly the same result.

[george1421]

@goempie Nuts…

OK back on the screen above… hit S to go into the ipxe shell.

When you get to the command prompt wait 30 seconds. the key in

dhcp net0

This will start the dhcp discovery process

Something just hit me, does this device have wireless plug built in ethernet? Is the mac address above for the wireless card or ethernet card?

back on point
if the net0 fails to pick up a dhcp address then try
dhcp net1 (you may get an error here if there isn’t a second nic).

[george1421]

Just an observation, if you just updated to the latest trunk build. I’m a bit surprised that the iPXE kernel is about 9 commits behind the current release. But that may be a question more for the developers to answer.

[Quazz]

This is anecdotal but I get this all the time in VMs when I reboot (but not when I shutdown and then boot). Don’t know if that’s something you’ve already tried, though.

This is a known issue (source: http://ipxe.org/err/040ee1)

[george1421]

Thinking about this and referencing a different thread [https://forums.fogproject.org/topic/7226/hp-260-g1-realtek-pcie-gbe], what iPXE boot image are you using? undionly.kpxe or something else. You might want to try the ipxe.pxe iPXE boot kernel to see if that addresses the dhcp issue. Again this is just a guess, but I know these realtek nics can be a big PITA at times.

[goempie]

@george1421

I the command dhcp net0 gives me the same error.
dhcp net1 say’s no adapter was found.

I have another problem with upgrading the kernel, maybe that why i’m a few build behind.

https://forums.fogproject.org/topic/7216/kernel-update-problem-github-7238-ubuntu-14-04/4

It has wireless build in, not sure how to test if the mac adress is wireless or not?

[Quazz]

@goempie Upgrading the kernel is unrelated to the ipxe binaries, don’t worry.

Try pointing your DHCP server to the realtek.kpxe binary instead of undionly.kpxe like George suggested.

Don’t worry about wireless for now, wireless cards rarely ever support PXE, same goes for the BIOS supporting wireless PXE booting. So, it is most likely already trying to boot of the wired connection.

[goempie]

@george1421 Indeed changing to ipxe.pxe solved the problem. Thanks for the help.

[george1421]

@goempie said in dhcp failed on HP prodesk 400 G2:

@george1421 Indeed changing to ipxe.pxe solved the problem. Thanks for the help.

Great!! @Sebastian-Roth mentioned that the undi code in the realtek nics were a bit flaky. The ipxe.pxe image can be used as a direct replacement for unidonly.pxe. The kernel is a bit bigger in the ipxe.pxe since it has all known drivers for nic in production. But with GbE networks and many Gb of memory there is no real performance difference between the two.

Marking as solved.

[craigj1222]

@george1421 @goempie

Can you guys please provide instructions on where/how to change to the ipxe.pxe boot kernel? I am seeing this same issue after creating a new image for an HP ProDesk 400 G3 with the same Realtek NIC drivers.

[george1421]

@craigj1222 Typically you will update your dhcp server, change dhcp option 67 {boot-file} from undionly.kpxe to ipxe.pxe. Then pxe boot the target computer. Now understand that this change will allow all uefi systems to pxe boot. If you need to boot a legacy (bios) system you will need to change this dhcp option back to undionly.kpxe.

If your dhcp server is based on Windows server 2012 you have an option to have the dhcp server automatically switch between the two boot files based on the target system that is booting.

[goempie]

@george1421 How can you set this up on server 2012 to automatically change?
Cause now i have to change sometimes, would be handy if it’s automatic

[Quazz]

@george1421 ipxe.pxe does not allow UEFI booting, you’re thinking of ipxe.efi

In my experience ipxe.kpxe is more compatible than undionly.kpxe, I’ve been using it as the default for a while now to great success.

[george1421]

@goempie There is a posting on the FOG wiki that discusses this: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

As for the differences between undionly.kpxe and ipxe.kpxe. The difference is that undionly,kpxe is smaller and is only has a shim between the iPXE kernel and the network adapter. It relies on some firmware on the network adapter to provide basis undi network services. As long as the network card firmware is well behaved then everything works great in this model. The ipxe.kpxe contains the majority of known or common network drivers right in the kernel. This iPXE kernel is bigger for sure but also include very well behaved network drivers.

Just a comparison between the two kernels.
undionly.kpxe is about 93KB in size
ipxe.kpxe is about 343KB in size.

These days with multi GB workstations this is really a trivial matter, but smaller kernels make faster boots. But in reality find the iPXE kernel that works best for your environment and stick with it.