Uefi boot (patch from Aaron Young) #612
Conversation
|
Just added this patch because of #447 |
wapolinar
changed the title
The efimap command will display a list of available EFI filesystems for use with sanboot command --drive argument to boot a local UEFI disk.
when there is no san_device defined for the given drive #. This is will allow the sanboot command to attempt to boot a local UEFI disk in the event that a drive was specified for which there is no corrensponding san_device "hooked".
map of available UEFI filesystems (i.e. "drives"). The map can be displayed via efi_boot_display_map() which is used by the new efimap command. The drives can be booted via efi_boot_local() which is called indirectly by the sanboot command (via efi_block_boot()). Note the map is ordered by device path (using strncmp()) which will typically give a PCI BDF ordering as the device paths typically begin with PciRoot()/Pci() nodes. This will help maintain consistency between boots. Also note that all PCI Bridges are "connected" so that all UEFI PCI filesystems can be discovered. This works around UEFI implementations which optimize the devices which are automatically connected to the minimal set required to boot.
|
Sorry for pinging @mcb30 is there any work to do before this patch can be merged. |
|
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 interested |
|
Also want to add my interest for this feature. Can also confirm that this patch works. |
This comment was marked as abuse.
This comment was marked as abuse.
|
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. |
This comment was marked as abuse.
This comment was marked as abuse.
|
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. |
|
+1 for writing this update. Helped me understand the EFI disk layout. |
|
Waiting for this since many years now... |
|
This patch could not have been merged as-is: beyond the extra 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. |
Please let me know how it works out for you! I'll also be adding a couple of extra small |
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. |
@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 |
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:
This syntax is very similar and consistent with the
syntax currently used to boot a local legacy HDD, i.e.:
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.