Could not boot: No such device
-
The issue also occurs with wimboot
:WIMBOOT || goto ERROR kernel wimboot || goto ERROR initrd SubMenu/wimboot/Boot/${bootarch}/Images/BCD BCD || goto ERROR initrd SubMenu/wimboot/Boot/boot.sdi Boot.SDI || goto ERROR initrd -n boot.wim SubMenu/wimboot/Boot/${bootarch}/Images/${wim}.wim boot.wim || goto ERRORthis appears to be an issue with the device?
p.s. I just upgraded FOG toRunning Version: 1.3.4-RC-2
didn’t resolve the issue -
It seems that I am chaining a wrong file or something;
DHCP provides my machines with ipxe.efi, which in turn boots to default.ipxe. However, UEFI enabled devices can’t boot anything; not init.xz, not wimbootI literally tried using all the efi files from the /tftpboot folder; but to no avail… I must be missing something obvious here
-
Is this a uefi for bios (legacy) system?
If uefi did secure boot get disabled?
Its not clear if the FOG iPXE menu is loading. The error might indicate that iPXE is loading, but it doesn’t have the driver for the usb nic adapter.
From your iPXE kernel command you posted, it appears you are trying to capture an image with the fog server. Were you able to register the client successfully from the iPXE menu?
-
This is a UEFI system
SecureBoot is disabled
FOG iPXE menu loads; but all the options are not working
I manually added the host to FOG because I was unable to boot the device to Quick Registration (everything ends up with an exec error) -
@abos_systemax said in Could not boot: No such device:
FOG iPXE menu loads; but all the options are not working
What iPXE kernel as you sending to the target computer (dhcp option 67)?
Just to be clear, the iPXE menu is detecting an IP address and the part that is failing to get an IP address/detect the MAC address is the FOS Engine (the customized linux OS that captures and deploys images on the target)?
Have you tested the ipxe7156.efi ipxe kernel to see if you have better success with that boot image.
We have see similar issues with lenovos with faulty uefi firmware. It will load bzImage and the init.xz but fail to launch the bzImage kernel. This was traced to fault firmware. You might want to check to see if you have the latest firmware on this asus.
Sorry about being all over the place on this, but its not clear why its failing yet. A clear image taken with a mobile may give better clues too.
-
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.
-
@george1421
oh… that is intresting; the ipxe7156.efi appears to function.what do those numbers mean?
-
@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).
-
@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?
-
@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.
-
@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 :))
-
@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 68to 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.
-
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 ffthis 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"; } -
@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.
-
@george1421 I take that you mean the ‘UNDI:003000’ part?
-
@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.
-
@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 -
@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.
-
@george1421 Thnx! I was waiting to crash on a x32 device to check what that arch would be, this helps
-
