Ipxe boot Marvel/Yukon nic to FOG successfully

[Hanz]

Has anyone found a way to successfully pxe boot a machine with Marvel Yukon NIC ?

[Sebastian Roth]

iPXE actually has a native driver for Marvell Yukon 2 chipset. Depending on which iPXE binary you tried this native driver is not used (undionly does not have native drivers but uses UNDI which does not work with all NICs). Maybe try using ipxe.pxe/.kpxe and see if this is working for you.

Please upload a picture if you see an error or hang.

[Quazz]

@Sebastian-Roth If this is the case, would it be possible for the FOG DHCP to automatically create specific classes for those manufacturers so that it will choose the right binary regardless?

I created one for realtek because of certain NICs and it’s been working great.

You need to add the following option for the code below:

option architecture-type code 93 = unsigned integer 16;

class "realtek" {
  match if option vendor-class-identifier = "realtek";
 if option architecture-type = 00:00 {
  filename "realtek.kpxe";
  } elsif option architecture-type = 00:09 {
  filename "realtek.efi";
  } elsif option architecture-type = 00:07 {
  filename "realtek.efi";
  } elsif option architecture-type = 00:06 {
  filename "i386-efi/realtek.efi";
  } else {
  filename "realtek.kpxe";
  }
}

[Sebastian Roth]

@Quazz Would be great if we could but IMHO architecture type has absolutely nothing to do with the type of NIC installed. But you could check the vendor part of the clients MAC address I suppose.

[Quazz]

@Sebastian-Roth It doesn’t, you’re correct, it’s merely used to support UEFI booting based on the client’s capabilities.

[Sebastian Roth]

Yes but you could use matching to check on MAC addresses to find specific NIC vendors like Marvell in this case. See here for an example: http://serverfault.com/questions/715011/isc-dhcpd-class-is-not-assigned#717009

[Hanz]

@Sebastian-Roth

ipxe.kpxe fixed this issue

[Sebastian Roth]

@Hanz said:

ipxe.kpxe fixed this issue

I am not sure if I understand what you are saying? The picture shows an error. So I guess this is an earlier picture of using undionly.kpxe (filesize of 91341 KB must be it). And I guess using ipxe.kpxe is working for you!?

[Hanz]

@Sebastian-Roth yes that is correct, I’m sorry I didn’t really explain it thoroughly. ipxe.kpxe works really well so far with all our systems, is there any particular advantages to undionly.kpxe over ipxe.kpxe ?

[Sebastian Roth]

@Hanz undionly (as the name says) is only using the UNDI interface. ipxe.pxe/kpxe also has native drivers included. The binary is bigger and takes a little longer/more resources to load via TFTP on bootup. Whichever works for you is fine.

[Hanz]

@Sebastian-Roth why would the ipxe.kpxe load very slowly once it gets to bzimage

[Sebastian Roth]

I meant slow because the ipxe.kpxe binary being 3-4 times the size of undionly.kpxe - 320 KB vs 90 KB. It’s not an issue with proper network equipment but still some more data a client has to download each time it boots via PXE.

[Hanz]

@Sebastian-Roth no once it goes past the default.ipxe, and boot.php, bzimage is really slow

[Sebastian Roth]

@Hanz Ahhhh, now I understand. You experience bzImage download being very slow… Well this might have to do with native Marvell driver in iPXE not being great. If you really want to know I guess we need you to capture a paket dump (https://wiki.fogproject.org/wiki/index.php/TCPDump) and we might find something there.

[Hanz]

@Sebastian-Roth Ok gotta get squared away here, I have one machine with a Yukon nic and it will only work (otherwise ipxe error indicating tftp timeout) with the ipxe.kpxe, another machine (indicative of most machines in our network) with realtek nics that works well with the undionly.k/kkpxe (either)…

Problem is that if I use the ipxe.kpxe to boot (all computers will get to menu) however the majority of our machines with the realtek nics take about 5 mins to load bzimage, whereas the yukon nic goes like normal…about 3 seconds.

If I use the undionly.kpxe, not all machines will contact server for pxe boot either tasked or not.

My only option it seems (that’s why I’m asking) is to change option 67 when dealing with the “problem children.”

Does the installer download the newest ipxe.k/kkpxe and/or undionly.k/kkpxe ? I have a lot of questions about the inner workings, hate to be a pain, just too curious for my own good.

It also seems that setting the custom kernel per GUI for the individual machine won’t work.

[Quazz]

@Hanz As far as I know, the pxe binaries come with the FOG package itself, whereas the bzimage is downloaded upon installation.

[Sebastian Roth]

@Hanz said:

Problem is that if I use the ipxe.kpxe to boot (all computers will get to menu) however the majority of our machines with the realtek nics take about 5 mins to load bzimage, whereas the yukon nic goes like normal…about 3 seconds.

This is interesting. Can you please try realtek.pxe/kpxe? This binary comes with a native realtek driver only. If this one is slow we know where to start digging. Are all the NICs the same realtek model??

[Hanz]

@Sebastian-Roth It’s really a hodge podge of different machine types. I understand why I get timeout (because drivers aren’t present) but not why the slow bzimage when using the driver that’ll get me there. Apparently Yukon nic doesn’t have any UNDI drivers, as I see most manufacturers UNDI PXE loading when initiating pxe boot.

I’m trying to get “one” to work with all, or maybe build an undionly to include whatever is in the ipxe.kpxe krnl that makes this one nic type work. I guess I’ll just change option 67 when dealing with these machines until I find a better solution.

Any idea why the individually specified kernel doesn’t seem to help any ?

@Quazz I would like a setup like yours shown below that might allow me to make fog switch the little kernel by yukon, else use undionly.kkpxe. Could you guide me ?

Possibly something I could add to default.ipxe or something ? I just realized the kernel on gui is really the bzimage not the udionly or ipxe “little kernels”

[KKTwenty101]

old topic but I had a similar issue, I simply created a DHCP reservation for the problem laptops (I only had a few) and set the 67 for those laptops on the reservation. That way I could leave fog alone and let the DHCP service give the appropriate details out (and being a reservation it is a permanent solution as far as I care).

[Hanz]

@KKTwenty101 I finally got this to work by updating the bios on my marvel/yukon nic machines.
PXE took off immediately afterwards. Just an option to try.