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

    PXE boot - HP Elitebook 650 G10 - No configuration methods succeeded ...

    Scheduled Pinned Locked Moved Unsolved
    FOG Problems
    3
    6
    2.0k
    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.
    • D
      Dominique
      last edited by

      Hi all

      We are having following problem when executing a PXE boot on a HP Elitebook 650 G10:

      fog_error_1.5.10.jpg

      As you can see, we’re using snponly.efi and already updated the binary as mentioned here: https://docs.fogproject.org/en/latest/kb/reference/compile_ipxe_binaries/.
      Snp.efi or other .efi binaries don’t work either.

      The DHPC options 66 and 67 are correctly specified.

      Bios settings on the device

      • secure boot is off
      • MAC address pass through is disabled

      Any advice is welcome.

      Thx in advance!

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

        @Dominique I guess I have a few questions in regards to this

        1. Is it just this specific model or all models from this network jack?
        2. Is this a new setup with FOG or have you used it successfully before?

        From your picture I can see that you have the dhcp server setup correctly, you have secure boot off (or ipxe won’t boot), using snponly.efi will use the built-in driver that is part of the nic. You might try ipxe.efi to see if you have better luck, but snponly.efi or snp.efi is probably the best general purpose boot loader.

        The no configuration methods screen is basically saying the ipxe kernel is not getting a dhcp response. I have seen this before if you have standard spanning tree enabled on your building switch. In this case you can check to see if its spanning tree issue, but placing a dumb unmanaged / cheap-o switch (like monoprice 5 port switch for $20) between the building switch and the pxe booting computer. If that solves the problem then its spanning tree causing the issue. Enable one of the fast protocols on your building switch like portfast, fastSTP, RSTP, MSTP or whatever your switch manufacture calls it.

        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!

        D 1 Reply Last reply Reply Quote 0
        • D
          Dominique @george1421
          last edited by

          @george1421

          1. I can build other laptops on that network jack
          2. No new setup, have build hundreds of devices a day.

          On a newly installed FOG server (for testing purposes) a device off that model can PXE boot as it should.
          Already copied the snponly.efi from that FOG server, but no luck.

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

            @Dominique said in PXE boot - HP Elitebook 650 G10 - No configuration methods succeeded ...:

            I can build other laptops on that network jack
            No new setup, have build hundreds of devices a day.

            Ok just trying to establish what the problem isn’t. Ok so you updated your ipxe binaries to the latest version. So that’s good.

            Looking at the model this hardware is pretty new (Aug 2023). Are you using the nic built into the chassis of the laptop or an external nic in a dock or usbX attached dongle?

            Check to see if there is a firmware update available for this hardware. The snp.efi and snponly.efi boot loaders use the nic driver built into the UEFI firmware. On most modern uefi implementations its very robust and stable and should work right out of the box.

            I would try for testing purposes to update dhcp to send ipxe.efi boot loader instead of the snp boot loader. Does that boot loader work? The ipxe.efi boot loader is a lot like the linux kernel where it has most of the common network drivers built into the boot loader.

            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!

            1 Reply Last reply Reply Quote 0
            • RobertDR
              RobertD
              last edited by

              I just received this exact same model laptop and I’m having the same problem. I’m using the onboard NIC with the ipxe.efi loader. The onboard NIC is an Intel 1219-V

              Here is what I’ve done so far:

              • Updated the ipxe.efi manually.
              • Updated the BIOS to the latest version.

              Using ipxe.efi it gets stuck “iPXE initalising devices…”, however if I set the snp.efi it boots successfully.

              We have been using ipxe.efi for all of our devices for years so I’m afraid to change all our DHCP scopes to use this loader for this one problematic model. Any suggestions?

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

                @RobertD said in PXE boot - HP Elitebook 650 G10 - No configuration methods succeeded ...:

                We have been using ipxe.efi for all of our devices for years so I’m afraid to change all our DHCP scopes to use this loader for this one problematic model. Any suggestions?

                Its great that you have a path to boot these system via the snp driver.

                You didn’t mention if you updated iPXE to the latest release to see if the ipxe.efi boot loader works once again.

                Let me (re)clarify in this thread the differences between ipxe.efi and the snpX.efi boot loaders.

                ipxe.efi (uefi) and ipxe.kpxe (bios) contain all of the known drivers built into the boot loader, this makes the iPXE boot loader much larger in file size (in 1990 terms of file size) because it has to carry all known drivers onboard the boot loader. For older systems > 6 years those were the preferred boot loaders for iPXE

                snp.efi, snponly.efi (uefi) and undionly.kpxe (bios) use the network adapters built in driver through the generic snp or undi interface. This boot loaders are much smaller than the ipxe.* versions since they only need to have one driver onboard (snp or undi). The undi driver (bios) has been around for 30 years and is the preferred and very stable network interface for bios computers and should always be the #1 choice. The uefi firmware has only been around for 12 years or so. The early version were very buggy so the snp driver did not work well. This is the reason why the fog developers recommended the ipxe.efi boot loader for uefi systems. In the last 6 years or so the snp and uefi firmware has matured to a level where the fog developers are recommending snp.efi or snponly.efi for all modern hardware. For bleeding edge hardware you have a better chance to get the snpX.efi bootloaders to work before the ipxe.efi bootloader, because the iPXE kernel developers will need to add the driver to the bootloader. Its just a timing issue.

                Now you might ask what is the difference between the snp.efi and snponly.efi drivers. snponly.efi will only initialize a network interface from where it was loaded from. For example lets say you pxe booting a compute with 4 nics, and you pxe bootin from nic2. The iPXE boot loader would only init nic2 using the snponly.efi bootloader. In contract snp.efi would try to init all nic intefaces starting with 1, 2, 3, and then 4. The issue becomes if nic1 takes the boot loader someplace else other than to the FOG server, since the fog server is on nic2.

                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!

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

                151

                Online

                12.0k

                Users

                17.3k

                Topics

                155.2k

                Posts
                Copyright © 2012-2024 FOG Project