HDD Boot from ipxe.efi loaded via network

[simon]

So, we have more and more machines running EFI now, and on some of them we need to dualboot a local OS. With PCBIOS this was dead simple, as sanboot worked flawlessly on 99% of machines, and for that 1% where it didn't, we chained to syslinux6 with chain.c32.

With EFI, things aren't that great. As far as I can tell, you should be able to just set the boot order to Netboot first, HDD second, and if you want to HDD boot from ipxe, you exit 1 to signal that the boot method failed and the EFI firmware should continue with the next item in the boot order.
Our sample size of system models where we use EFI is only 6, but sadly, only one of them works with the method described above. Others just freeze, show "no operating system found" or do other silly things. I picked up somewhere that exit 0 instead might do the trick, but to no avail; funnily enough, on an HP Elitedesk 800 G5, exit 1 shows a "Startup Menu" with a bunch of options, while exit 0 either re-starts network boot immediately, or shows a "Boot Menu" where I see exactly the boot order I configured in the EFI setup and can choose from them.

[Update: the HP Elitedesk 800 G5 works with "exit 1", but only if we use snponly.efi instead of ipxe.efi]

Did anyone figure out a sane solution to this, or are there at least concepts of how to improve the situation? Can anything be done on iPXE's side? Can we load another bootloader via network that can access the ESP and load the default entry?

[mcb30]

I do have some notes somewhere on expanding sanboot to handle local boot under UEFI. I think someone may even have put together a trial implementation, but I'd have to search for it.

Other options currently available include using

Code:

chain file://......

to directly boot the on-disk bootloader, but that would require knowing the volume label of the local disk.

Michael

[simon]

Ah, thanks for the hint. According to other threads on EFI, it sounded like there is no way at all to access the local disk if ipxe is loaded via network, instread of the HDD.

I tried playing with the file:// approach. It looks like, at least on that weird HP device, the volume label is empty, but then it fails to open it.

Code:

ipxe: iPXE> imgload file://test/foo
ipxe: LOCAL 0xa133f9e8 found PciRoot(0x0)/Pci(0x1B,0x0)/Pci(0x0,0x0)/NVMe(0x1,85-EA-AE-00-04-0D-08-00)/HD(1,GPT,5B4A66B9-4F1B-4B1A-B3
ipxe: 99-CF3CE18399F8,0x800,0x100000) with label ""
ipxe: LOCAL 0xa133f9e8 found no matching handle
ipxe: Download of "foo" failed: No such file or directory (http://ipxe.org/2d4de08e)
ipxe: Could not start download: No such file or directory (http://ipxe.org/2d4de08e)
ipxe: iPXE> imgload file:///EFI/debian/grubx64.efi
ipxe: LOCAL 0xa133fc68 could not open filesystem on UNKNOWN<0xae788818>: Error 0x7f4de082 (http://ipxe.org/7f4de082)
ipxe: LOCAL 0xa133fc68 found no matching handle
ipxe: Download of "grubx64.efi" failed: No such file or directory (http://ipxe.org/2d4de08e)
ipxe: Could not start download: No such file or directory (http://ipxe.org/2d4de08e)

I'll try giving the ESP a GPT label, in case it's the one referred to here (maybe empty string just breaks things), and also test on other machines. If this works, maybe supporting file://*/... to mean "use whatever" would be sufficient, and should be trivial to implement.

[simon]

Progress.

If you don't have a FAT32 formatted ESP, it looks like this:

Code:

ipxe: iPXE> imgload file://dsfg/sdfg
ipxe: LOCAL 0x9698bd48 could not enumerate handles: Error 0x7f4de08e (http://ipxe.org/7f4de08e)
ipxe: Download of "sdfg" failed: Error 0x7f4de08e (http://ipxe.org/7f4de08e)
ipxe: Could not start download: Error 0x7f4de08e (http://ipxe.org/7f4de08e)

Setting the GPT label for the ESP is wrong. You need to set the FAT label, i.e. mkfs.vfat -n MYLABEL /dev/sda1 or fatlabel /dev/sda1 MYLABEL, which finally lead to success on the above mentioned HP, and an Intel NUC NUC5i5RYB:

Code:

ipxe: iPXE> imgload file://FATLABEL/EFI/debian/grubx64.efi
ipxe: LOCAL 0x9a938ce8 found PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)/HD(1,GPT,86502F95-E8D0-4BFC-B4BC-76D6123D2D77,0x800,0x80
ipxe: 000) with label "FATLABEL"
ipxe: LOCAL 0x9a938ce8 using PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)/HD(1,GPT,86502F95-E8D0-4BFC-B4BC-76D6123D2D77,0x800,0x80
ipxe: 000) with label "FATLABEL"
ipxe: LOCAL 0x9a938ce8 base path ""
ipxe: LOCAL 0x9a938ce8 using "\EFI\debian\grubx64.efi"
ipxe: file://FATLABEL/EFI/debian/grubx64.efi...Downloaded "grubx64.efi"
ipxe:  ok
ipxe: iPXE> boot
ipxe: Executing "grubx64.efi"
[..grub prompt here..]
ipxe: Execution of "grubx64.efi" completed
ipxe: iPXE>

If you have an ESP with an empty label, like in my previous post, it doesn't work, i.e. file:///EFI/debian/grubx64.efi does not work, even though the output looks different from passing an invalid label.

So far this looks promising, I'll continue experimenting next week.