• Register
    • Login
    • Search
    • Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search

    Disable USB support in iPXE?

    FOG Problems
    4
    8
    249
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      MarkG last edited by

      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.

      Greg Plamondon 1 Reply Last reply Reply Quote 0
      • M
        MarkG @Greg Plamondon last edited by

        @greg-plamondon Yes, I never enable that nonsense 🙂

        1 Reply Last reply Reply Quote 0
        • Greg Plamondon
          Greg Plamondon Testers @MarkG last edited by Greg Plamondon

          @markg said in Disable USB support in iPXE?:

          FOG.

          Do you have Secure boot disabled in BIOS?

          M 1 Reply Last reply Reply Quote 0
          • M
            MarkG @george1421 last edited by

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

            1 Reply Last reply Reply Quote 0
            • george1421
              george1421 Moderator @MarkG last edited by

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

              Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

              M 1 Reply Last reply Reply Quote 1
              • M
                MarkG @Sebastian Roth last edited by

                @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 1 Reply Last reply Reply Quote 0
                • S
                  Sebastian Roth Moderator last edited by

                  @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

                  Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                  Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                  M 1 Reply Last reply Reply Quote 0
                  • M
                    MarkG last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • 1 / 1
                    • First post
                      Last post

                    189
                    Online

                    10.4k
                    Users

                    16.4k
                    Topics

                    150.5k
                    Posts

                    Copyright © 2012-2023 FOG Project