ipxe
Uefi boot (patch from Aaron Young)
Original comment from Aaron Young:
This patch series adds support to boot a locally attached UEFI disk. The disk must installed with a EFI System Partition and filesystem.
This improves upon the current solution to boot a local UEFI disk from iPXE - which requires one to exit out of iPXE to fallback into the EFI boot manager. This solution allows iPXE to boot a UEFI disk directly and stay in control if the boot fails.
Example syntax to boot a local UEFI disk:
sanboot --no-describe --drive 0 --filename \EFI\redhat\grubx64.efi
This syntax is very similar and consistent with the syntax currently used to boot a local legacy HDD, i.e.:
sanboot --no-describe --drive 0x80
The extra --filename argument is required for UEFI as the UEFI spec allows the bootloader to be located in non-standard locations on the disk. The --filename is optional and if omitted, the standard spec defined default filepath will be used, e.g. \EFI\BOOT\BOOTX64.efi on x86_64.
This patch series also includes a new efimap command which displays a map of all locally attached UEFI filesystems. Example output of the efimap command is as follows:
iPXE> efimap Drive# [Volume Label] Path
0 [ORACLE LINUX] PciRoot(0x0)/Pci(0x3,0x0)/HD(2,MBR,0x2E0E0369,0xBBC,0x3708) 1 [DATA DISK3] PciRoot(0x0)/Pci(0x5,0x0)/HD(1,GPT,F82F29A0-...,0x800,0x64000) 2 [NO VOLUME LABEL] PciRoot(0x0)/Pci(0x6,0x0)/HD(1,GPT,F82F29A0-...,0x64000)
Note that in the event that the UEFI EFI_DEVICE_PATH_TO_TEXT protocol is not implemented on a system, the output of the efimap will contain a hex string dump of the device path, like so:
iPXE> efimap Drive# [Volume Label] Path
0 [ORACLE LINUX] 02010c00d041030a0000000001010600000304012a0002... 1 [DATA DISK3] 02010c00d041030a0000000001010600000404012a000100... 2 [NO VOLUME LABEL] 02010c00d041030a0000000001010600000504012a0...
The drive# from the efimap command can be passed as an argument to the sanboot command --drive option to specify which disk/filesystem to boot.
Note that the mappings are sorted by device path which gives a PCI BDF ordering as the device paths typically begin with PciRoot()/Pci() nodes. This sorting will help to give a consistent mapping between boots.
Testing: This patchset was testing in a virtual/cloud environment with QEMU attached PV disks and also on a baremetal system.
v2 Changes: - Removed 1st (strcmp/strncmp fix) patch from original series since it was pulled. - Improved efimap output to include the Volume Label (if present) to aid in identifying boot drives/filesystems.
Sorry for pinging @mcb30 is there any work to do before this patch can be merged. It would be great to fall back to local Disks from an UEFI IPXE Menu
We are also very interested by this feature, this would allow smoother UEFI boots on disk 😊
I would also be very interested. It would help me with 150 clients which I could then also boot with iPXE.
Also want to add my interest for this feature. Can also confirm that this patch works.
Hi Aaron Young,
I think that you are the @ajyoung-oracle. I did just see https://github.com/ipxe/ipxe/pull/136#event-7113216025
Which git repository (and which branch of it) has the commit that this merge request is based on?
Regards Geert Stappers
Silence is hard to parse.
Hi. I don't believe that I ever pushed the patchset to my public github repo. I only submitted the patches to the ipxe-devel email list for review/comment. I never pursued it further than that.
FWIW
- https://lists.ipxe.org/pipermail/ipxe-devel/2019-February/thread.html
- https://lists.ipxe.org/pipermail/ipxe-devel/2019-April/006644.html
This would be really nice to have merged in. having to manually patch it in isn't ideal.
Tried it and it works great. Thanks for the extra efimap command as well. You didn't need to put that in but it made things much easier.
Would love for this to be included in the main branch if possible.
This patch could not have been merged as-is: beyond the extra efimap command, it duplicates a substantial amount of logic from efi_block.c but with some modifications, which would create extra maintenance work in future. There is simply no capacity to accommodate any change such as this which adds technical debt.
The equivalent functionality is now present upstream as of commit https://github.com/ipxe/ipxe/commit/b1c13cc43
This patch could not have been merged as-is: beyond the extra
efimapcommand, it duplicates a substantial amount of logic fromefi_block.cbut with some modifications, which would create extra maintenance work in future. There is simply no capacity to accommodate any change such as this which adds technical debt.The equivalent functionality is now present upstream as of commit b1c13cc43
Totally appreciate this. I imagine the maintenance overhead for something like this is already pretty wild. I will be deploying this across a university as soon as I get back @mcb30.
Thank you once again.
Totally appreciate this. I imagine the maintenance overhead for something like this is already pretty wild. I will be deploying this across a university as soon as I get back @mcb30.
Please let me know how it works out for you!
I'll also be adding a couple of extra small sanboot features soon to allow the boot partition to be selected by UUID, volume label, or existent filename (which might potentially be useful in your use case).
Totally appreciate this. I imagine the maintenance overhead for something like this is already pretty wild. I will be deploying this across a university as soon as I get back @mcb30.
Please let me know how it works out for you!
I'll also be adding a couple of extra small
sanbootfeatures soon to allow the boot partition to be selected by UUID, volume label, or existent filename (which might potentially be useful in your use case).
You've already improved it as far as I can see. Basically if you plug a USB drive into our iPXE systems currently it will fail to boot(I'm using a custom patch built from this pull request). As the San disk numbers change. If I'm reading this right you've assigned them static values that don't change? I am under the hood just cycling through the first dozen or so number each boot until we get to one that is actually bootable. In the rare event someone boots the system with an external drive plugged in.
This package is the lynchpin in a system we use to admin hundreds of systems. Couldn't live without it. The migration to UEFI was a tough one but with the help of this package we did it @mcb30. Many thanks from the SDI at Abertay University.
This package is the lynchpin in a system we use to admin hundreds of systems. Couldn't live without it. The migration to UEFI was a tough one but with the help of this package we did it @mcb30. Many thanks from the SDI at Abertay University.
@TomKranenburg You're very welcome! I've just updated the documentation at https://ipxe.org/cmd/sanboot to include all the new features - it sounds as though using --drive 0 and some filtering options could be very useful to you.