Could not boot: No such device

[abos_systemax]

I am chaining ipxe.efi, which in turn loads default.ipxe (this functions)
Then, boot.php detects the right MAC (it tries to boot to FOG).
It loads bzImage, init.xz (both OK)
then: Could not boot: No such device (2x)

I also tried to chain bzImage32 and init32.xz manually, but they fail with an exec error.

I do not get into the FOG client.

[abos_systemax]

@george1421
oh… that is intresting; the ipxe7156.efi appears to function.

what do those numbers mean?

[george1421]

@abos_systemax The iPXE kernel changed something (I don’t have the technical information what actually changed) a while back and the developers discovered that an older configuration of the iPXE kernel still worked. So they released both the new and older configurations. The ipxe7156.efi is the older configuration that works with some broken firmware (including the Surface Pros).

[abos_systemax]

@george1421 I.C… is there a way I can determine beforehand which ipxe.efi goes to what device? or can I use 7156 for all other devices as well?

[george1421]

@abos_systemax The older version should work for all. Understand I’m saying this without first hand experience since we only have Dells and use the ipxe.efi kernel. But the older configuration should work, it may not support the latest firmware network drivers.

What are you using to issue the boot file information to your devices MS DHCP, dnsmasq, or ISC DHCP? If its the two latter ones you can do thing based on the mac address or uuid of the device to send the specific files based on the hardware type.

[abos_systemax]

@george1421 We are using ISC.

Other Question; can you chain another efi file after the first one is loaded? (Will test but right now the image is creating :))

[george1421]

@abos_systemax Chaining is possible.

ISC gives you options. What you will need is a tcpdump capture of the target computer’s dhcp request. You can capture with tcpdump or wireshark as long as the target computer and the capture device are on the same subnet. You can use the filter port 67 or port 68 to capture the necessary discussion.

It would be interesting to know the mac address, the values of dhcp option 60, 93, and what ever UUID is. Or just post the dhcp packet capture here and I can look at it.

[abos_systemax]

0170  50 58 45 43 6c 69 65 6e 74 3a 41 72 63 68 3a 30   PXEClient:Arch:0
0180  30 30 30 37 3a 55 4e 44 49 3a 30 30 33 30 30 30   0007:UNDI:003000
0190  ff         

this appears to work (Excerpt from dhcp config)

    filename "ipxe.efi";
       
    class "Legacy" {
    	### This is a BIOS client; do not sent en EFI file, that is silly!
    	match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";
    	filename "undionly.kpxe";
    }
    
    class "Crappy_UEFI_Firmware" {
    	### This device uses crappy UEFI firmware, send the older ipxe7156.efi that apparently does work.
    	match if substring(option vendor-class-identifier,0,20) = "PXEClient:Arch:00007";
        filename "ipxe7156.efi";
    }

[george1421]

@abos_systemax FWIW, what you created was the detection between legacy (bios) mode and uefi BC mode. This will work, if you want you should be able to refine it a bit more if you look at dhcp option 97. The left part should be the machine hardware identifier. Not all hardware vendors use this field, but if they do then you can uniquely identify the hardware.

[abos_systemax]

@george1421 I take that you mean the ‘UNDI:003000’ part?

[george1421]

@abos_systemax No that is option 60 (off the top of my head). If you look at your pcap of a dhcp boot in wireshark. The first dhcp discover from the client, contains dhcp option 97 .

<edit> dang, I just found a pcap graphic on my system that will help explain. The one we are interested in is the UUID dhcp option 97. It would be interesting to know what your system has here.

[abos_systemax]

@george1421 That is ‘just’ the UUID of the device itself, not of the vendor/all other devices of this type?
I could indeed use the UUID to push a certain ipxe.efi to this device; but the method I use now pushes that efi file to all devices with arch:0007, which also isn’t the real solution, but a working one for now. (the ‘rest’) will receive the normal ipxe.efi

[george1421]

@abos_systemax That is correct that uuid field is / should be unique to the device (assuming the vendor uses it. its use is optional and up to the vendor to fix the formatting of that field). If what you have works, then no need to go deeper. Just remember this is an option.

Also be aware there are other uefi systems you need to take into account. Arch 7 is EFI BC there is also, Arch 6 EFI x32 and Arch 9 EFI x64 (recited from a very old brain so your YMMV). But there are more archs you need to take into account or they will not boot with the bios firmware.

[abos_systemax]

@george1421 Thnx! I was waiting to crash on a x32 device to check what that arch would be, this helps

[george1421]

@abos_systemax Top table https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

[abos_systemax]

@george1421 Bookmarked!