Disable USB support in iPXE?

[MarkG]

Running FOG 1.5.9. I have a specific problem with an AMD-based Lenovo. When booting normally it’s fine but when booting via iPXE all the USB-C ports are disabled. This happens the moment that it downloads the NBP file from FOG.

From searching forums it seems this is a known iPXE problem and the only solution I’ve found is that you need to completely disable usb support in iPXE by rebuilding iPXE with some special options, but I don’t know how to do this using FOG’s buildipxe.sh. I’ve tried just running that to get the latest version of iPXE but that hasn’t helped.

[MarkG]

I found another possible solution though I’ve no idea why it works. I switched every instance of ‘ipxe.efi’ in my dhcpd.conf to ‘realtek.efi’. This was a complete guess, but now the USB-C ports work.

How can I work our what to use as the string match so that I can ensure that only this Lenovo PC uses realtek.efi?

Also can anybody explain why this made a difference? The main USB controller is an AMD controller. There is a Realtek USB SD Card Reader and a Realtek NIC but I was never having any issues with those.

[Sebastian Roth]

@MarkG said:

I found another possible solution though I’ve no idea why it works. I switched every instance of ‘ipxe.efi’ in my dhcpd.conf to ‘realtek.efi’. This was a complete guess, but now the USB-C ports work.

That is a pretty interesting find! Well done. If you are really keen you can post this on the iPXE developers mailinglist and see what they think about it. Though I have to say that they are not as responsive at times.

How can I work our what to use as the string match so that I can ensure that only this Lenovo PC uses realtek.efi?

I guess the best way to go about this is matching for MAC addresses (or better the first three bytes as they make up the vendor “id”):

...
    class "LenovoFoo" {
        match if substring(hardware,1,3) = xx:yy:zz;
        filename "realtek.efi";
    }
...

Make sure you put that class first before all the others so it will match first for these MAC addresses.
[1]: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Example_2
[2]: https://serverfault.com/questions/775123/match-hardware-in-dhcpd-conf-not-working

[MarkG]

@sebastian-roth Thanks. In the end I found that even realtek.efi didn’t entirely work. The PC is connected to a KVM and using realtek.efi it will only boot if the active KVM port is the one the PC is connected to. Otherwise it gets stuck in and endless loop of retrieving the file, crashing, and rebooting. ‘snp.efi’ does seem to work but I’d really like to know what the difference is. Do you know if it’s documented anywhere or shall I have to rely on the mailing list? I haven’t found anything on the iPXE website.

This is what I came up with in dhcpd.conf

class "Realtek-64Bit-UEFI" {
    match if binary-to-ascii(16,8,":",substring(hardware, 1, 3)) = "1c:69:7a";
    filename "snp.efi";
}

[george1421]

@markg When we are talking about ipxe its important to know a few use cases.

ipxe.kpxe (bios) and ipxe.efi (uefi) they are in a way kind of akin to the linux kernel. They have all of the known network drivers built into the bootloader (kernel). If new hardware comes out and has slighly different requirements than legacy hardware it may take the iPXE developer some time to create/import the drivers into a new release of iPXE. Since this version of iPXE has all of the known drivers on board the boot loader is quite large (in early 2000 standards).

realtek.kpxe/realtek.efi or intel.kpxe/intel.efi. These are slimmed down versions of the larger ipxe.efi in that they only contain realtek or intel drivers with a few tweaks. Other than the few tweaks they are basically the same as ipxe.kpxe and ipxe.efi.

The interesting ones are undionly.kpxe and snponly.efi. These bootloaders only contain either the generic undi (bios) or snp (efi) network drivers. Both of these use the network adapters built in firmware network interface to communicate on the network. For bios the ndi protocol has been around for 30 years and is very stable. For fog the recommended boot loader for bios is undionly.kpxe. Since undionly.kpxe only contains one network driver, its very small and fast (since it only has to test and setup one network interface). As for the snp protocol that has been around only for a few years 8 or so, and only really has become a stable protocol in the last few years. Up until last year the recommended uefi boot loader was ipxe.efi (because the snp protocol wasn’t stable FOG recommended the built in network drivers, because they basically worked). Within the last year or so the developers have been thinking that snp has matured enough and to start recommended snponly.efi as the default uefi boot loader. The network adapters support for snp protocol comes from the network adapter’s firmware creator so it will most likely be current with newly released hardware, where ipxe.efi may take several months to include drivers for newly released hardware.

So the white elephant is, what is the difference between snp.efi and snponly.efi since they both use the snp protocol? The answer is simple and a bit complex. The short answer is snponly.efi will only init the network adapter that was used to download snponly.efi. snp.efi will initialize all snp network interfaces and not just the one that transferred snp.efi to the target computer. So with snp.efi, you could PXE boot from one network adapter and then image from a second network adapter. Its not likely to happen, but from a hardware standpoint its possible.

[MarkG]

@george1421 Thank you, that’s a very helpful explanation. I think I will start experimenting with using snp.efi as my default and create specific rules for machines where it does not work.

[Greg Plamondon]

@markg said in Disable USB support in iPXE?:

FOG.

Do you have Secure boot disabled in BIOS?

[MarkG]

@greg-plamondon Yes, I never enable that nonsense