RFC: Handling of multiple EFI System Partitions
The Asahi installer, which is what most people use to get their Apple Silicon Mac into a state where it is possible to install another OS on the machine, offers the posibility to create multiple OS installs. For each of these it creates a separate APFS partition (which holds among other things, some essential system firmware) and separate EFI System Partitions. This has a few benefits:
* It allows control over which version of the system firmware is used by the OS. This is especially important for things like the GPU and DCP (display controller) firmware, where the firmware interface isn't exactly what we'd call "stable". This way system firmware is paired with the OS install (similar to what macOS does for itself) which prevents breaking other OS installs on the same disk.
* It allows us to store a 2nd stage bootloader (m1n1+u-boot+dtb) on the EFI System Partition (ESP) such that it can be easily upgraded from within Linux without affecting other OS installs on the same disk.
* It allows the use of the "native" boot picker to switch between OSes.
The approach the Asahi team has taken is to pair the APFS partition with the ESP by adding a proprty that contains the partition UUID to the device tree. The installer ships u-boot with a patched distro boot script that looks at this device tree property, figures out what the right ESP is and loads the EFI bootloader (efi/boot/bootaarch64.efi) from that partition.
This approach has some drawbacks:
1. U-Boot will still consider the first ESP as *the* ESP, which means that the ubootefi.var file is still read from and written from the first ESP.
2. The distro boot script modifications don't work if U-Boot's built-in efibootmgr is used. This probably also affects Simon's bootstd stuff.
So my idea is to have U-Boot recognize the device tree property and use it when it determines what partition is *the* ESP. A proof of concept diff is attached below. This probably needs a bit of massaging as reading the device tree property in generic EFI code like this is probably not acceptable. A better approach might be to have a function that can be called from board-specific code that sets the UUID.
Thoughts? Would such a feature be useful on other hardware platforms?
commit 088f5626d4347cef76ad5a54477944886efb005a Author: Mark Kettenis kettenis@openbsd.org Date: Sun Sep 25 01:57:24 2022 +0200
HACK: Use designated ESP
Signed-off-by: Mark Kettenis kettenis@openbsd.org
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c index 7ea0334083..86b867d319 100644 --- a/lib/efi_loader/efi_disk.c +++ b/lib/efi_loader/efi_disk.c @@ -523,6 +523,27 @@ static efi_status_t efi_disk_add_dev( desc->devnum, part); } } + + ofnode chosen_node; + const char *uuid = NULL; + chosen_node = ofnode_path("/chosen"); + if (ofnode_valid(chosen_node)) { + uuid = ofnode_read_string(chosen_node, + "asahi,efi-system-partition"); + } + + /* Store designated EFI system partition */ + if (part && uuid && strcmp(uuid, part_info->uuid) == 0) { + if (part_info->bootable & PART_EFI_SYSTEM_PARTITION) { + efi_system_partition.uclass_id = desc->uclass_id; + efi_system_partition.devnum = desc->devnum; + efi_system_partition.part = part; + EFI_PRINT("EFI system partition: %s %x:%x\n", + blk_get_uclass_name(desc->uclass_id), + desc->devnum, part); + } + } + return EFI_SUCCESS; error: efi_delete_handle(&diskobj->header);
Am 18. Dezember 2022 15:21:06 MEZ schrieb Mark Kettenis mark.kettenis@xs4all.nl:
The Asahi installer, which is what most people use to get their Apple Silicon Mac into a state where it is possible to install another OS on the machine, offers the posibility to create multiple OS installs. For each of these it creates a separate APFS partition (which holds among other things, some essential system firmware) and separate EFI System Partitions. This has a few benefits:
- It allows control over which version of the system firmware is used
by the OS. This is especially important for things like the GPU and DCP (display controller) firmware, where the firmware interface isn't exactly what we'd call "stable". This way system firmware is paired with the OS install (similar to what macOS does for itself) which prevents breaking other OS installs on the same disk.
- It allows us to store a 2nd stage bootloader (m1n1+u-boot+dtb) on
the EFI System Partition (ESP) such that it can be easily upgraded from within Linux without affecting other OS installs on the same disk.
- It allows the use of the "native" boot picker to switch between
OSes.
The approach the Asahi team has taken is to pair the APFS partition with the ESP by adding a proprty that contains the partition UUID to the device tree. The installer ships u-boot with a patched distro boot script that looks at this device tree property, figures out what the right ESP is and loads the EFI bootloader (efi/boot/bootaarch64.efi) from that partition.
This approach has some drawbacks:
- U-Boot will still consider the first ESP as *the* ESP, which means
that the ubootefi.var file is still read from and written from the first ESP.
- The distro boot script modifications don't work if U-Boot's
built-in efibootmgr is used. This probably also affects Simon's bootstd stuff.
So my idea is to have U-Boot recognize the device tree property and use it when it determines what partition is *the* ESP. A proof of concept diff is attached below. This probably needs a bit of massaging as reading the device tree property in generic EFI code like this is probably not acceptable. A better approach might be to have a function that can be called from board-specific code that sets the UUID.
Thoughts? Would such a feature be useful on other hardware platforms?
efi/boot/bootaarch64.efi is only a fallback if load options are not set up. Once the operating system has generated a load option it is not used anymore.
The MacBooks only have one drive. Why would you want two ESPs on one drive?
Why can't the Asahi team use the current UEFI bootflow? We should avoid unneeded deviations. Can the current deviations be removed in Asahi Linux?
Best regards
Heinrich
commit 088f5626d4347cef76ad5a54477944886efb005a Author: Mark Kettenis kettenis@openbsd.org Date: Sun Sep 25 01:57:24 2022 +0200
HACK: Use designated ESP
Signed-off-by: Mark Kettenis kettenis@openbsd.org
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c index 7ea0334083..86b867d319 100644 --- a/lib/efi_loader/efi_disk.c +++ b/lib/efi_loader/efi_disk.c @@ -523,6 +523,27 @@ static efi_status_t efi_disk_add_dev( desc->devnum, part); } }
- ofnode chosen_node;
- const char *uuid = NULL;
- chosen_node = ofnode_path("/chosen");
- if (ofnode_valid(chosen_node)) {
uuid = ofnode_read_string(chosen_node,"asahi,efi-system-partition");- }
- /* Store designated EFI system partition */
- if (part && uuid && strcmp(uuid, part_info->uuid) == 0) {
if (part_info->bootable & PART_EFI_SYSTEM_PARTITION) {efi_system_partition.uclass_id = desc->uclass_id;efi_system_partition.devnum = desc->devnum;efi_system_partition.part = part;EFI_PRINT("EFI system partition: %s %x:%x\n",blk_get_uclass_name(desc->uclass_id),desc->devnum, part);}- }
- return EFI_SUCCESS;
error: efi_delete_handle(&diskobj->header);
On 2022-12-18 20:40:20 +0100, Heinrich Schuchardt wrote:
Am 18. Dezember 2022 15:21:06 MEZ schrieb Mark Kettenis mark.kettenis@xs4all.nl:
The Asahi installer, which is what most people use to get their Apple Silicon Mac into a state where it is possible to install another OS on the machine, offers the posibility to create multiple OS installs. For each of these it creates a separate APFS partition (which holds among other things, some essential system firmware) and separate EFI System Partitions. This has a few benefits:
- It allows control over which version of the system firmware is used
by the OS. This is especially important for things like the GPU and DCP (display controller) firmware, where the firmware interface isn't exactly what we'd call "stable". This way system firmware is paired with the OS install (similar to what macOS does for itself) which prevents breaking other OS installs on the same disk.
- It allows us to store a 2nd stage bootloader (m1n1+u-boot+dtb) on
the EFI System Partition (ESP) such that it can be easily upgraded from within Linux without affecting other OS installs on the same disk.
- It allows the use of the "native" boot picker to switch between
OSes.
The approach the Asahi team has taken is to pair the APFS partition with the ESP by adding a proprty that contains the partition UUID to the device tree. The installer ships u-boot with a patched distro boot script that looks at this device tree property, figures out what the right ESP is and loads the EFI bootloader (efi/boot/bootaarch64.efi) from that partition.
This approach has some drawbacks:
- U-Boot will still consider the first ESP as *the* ESP, which means
that the ubootefi.var file is still read from and written from the first ESP.
- The distro boot script modifications don't work if U-Boot's
built-in efibootmgr is used. This probably also affects Simon's bootstd stuff.
So my idea is to have U-Boot recognize the device tree property and use it when it determines what partition is *the* ESP. A proof of concept diff is attached below. This probably needs a bit of massaging as reading the device tree property in generic EFI code like this is probably not acceptable. A better approach might be to have a function that can be called from board-specific code that sets the UUID.
Thoughts? Would such a feature be useful on other hardware platforms?
efi/boot/bootaarch64.efi is only a fallback if load options are not set up. Once the operating system has generated a load option it is not used anymore.
Setting load options from operation systems is currently not implemented. The only readily available method to store variables is a file in the ESP. This obviously can not be supported as UEFI runtime service while the operation system is using the same disk. It might be possible to use NOR flash as UEFI variable store. This could cause issues with the primary boot loader iboot which we can not avoid or with macOS in dual boot configurations.
The MacBooks only have one drive. Why would you want two ESPs on one drive?
The lack of support for setting boot variable form the operating system makes it hard to support multiple OS with a single ESP. The systems comes with an accessible graphical boot picker which should be preferred over an u-boot based boot manager. Accessibility and the ability to boot macOS are the most important advantages.
At the current stage an u-boot based boot manager is not a viable option since the devicetree can not be guaranteed to be backwards compatible. The most recent breaking change was the addition of a phy phandle reference for USB controller nodes for USB3 support. Older kernel will obviously miss a driver for the phy and at least on Linux the USB controller will not be initialized. This breaks USB completely.
The devicetree is transformed by the loader before u-boot in a non-trivial way. If u-boot were to use kernel version specific DTB templates from the ESP it would require a non-trivial amount of code to update the template by the information added by the loader.
Why can't the Asahi team use the current UEFI bootflow? We should avoid unneeded deviations. Can the current deviations be removed in Asahi Linux?
See above, the main reason is the lack of support for setting UEFI variables at runtime from operating systems. Even if that those were supported it's impossible to upgrade all installed operating systems when the devicetree changes in a non backward compatible way due to additional hardware support.
At the current stage it is not possible to support UEFI bootflow.
Best regards
Janne
Hi Janne,
[...]
function that can be called from board-specific code that sets the UUID.
Thoughts? Would such a feature be useful on other hardware platforms?
efi/boot/bootaarch64.efi is only a fallback if load options are not set up. Once the operating system has generated a load option it is not used anymore.
Setting load options from operation systems is currently not implemented. The only readily available method to store variables is a file in the ESP. This obviously can not be supported as UEFI runtime service while the operation system is using the same disk.
Yes, but I'd skip the 'currently not implemented' part. If you store your EFI variables in a file on the ESP, we will *never* be able to (sanely) support SetVariable at runtime.
It might be possible to use NOR flash as UEFI variable store. This could cause issues with the primary boot loader iboot which we can not avoid or with macOS in dual boot configurations.
It is possible. In fact we already have code in U-Boot that stores the EFI variables in an RPMB partition of the eMMC. We also have (unfortunately not yet upstreamed) code that stores the in an i2c eeprom in the secure world.
This is again situational though and none of these applies to MBPs. SetVariable at runtime in an RPMB comes with it's own set of problems. You basically need to replace the runtime services with OS provided ones... The I2C one works fine.
But letting the implementation details aside, what we need to keep in mind, is that being able to support SetVariable-RT primarily depends on the *hardware* and there's gonna be hardware we'll never be able to support this.
The MacBooks only have one drive. Why would you want two ESPs on one drive?
The lack of support for setting boot variable form the operating system makes it hard to support multiple OS with a single ESP. The systems comes with an accessible graphical boot picker which should be preferred over an u-boot based boot manager. Accessibility and the ability to boot macOS are the most important advantages.
At the current stage an u-boot based boot manager is not a viable option since the devicetree can not be guaranteed to be backwards compatible. The most recent breaking change was the addition of a phy phandle reference for USB controller nodes for USB3 support. Older kernel will obviously miss a driver for the phy and at least on Linux the USB controller will not be initialized. This breaks USB completely.
The devicetree is transformed by the loader before u-boot in a non-trivial way. If u-boot were to use kernel version specific DTB templates from the ESP it would require a non-trivial amount of code to update the template by the information added by the loader.
Why can't the Asahi team use the current UEFI bootflow? We should avoid unneeded deviations. Can the current deviations be removed in Asahi Linux?
See above, the main reason is the lack of support for setting UEFI variables at runtime from operating systems. Even if that those were supported it's impossible to upgrade all installed operating systems when the devicetree changes in a non backward compatible way due to additional hardware support.
Ok fair enough, I'll talk to Heinrich and see if The current idea from Mark can be wired up without causing too much of a mess.
At the current stage it is not possible to support UEFI bootflow.
Best regards
Janne
Cheers /Ilias
On 19/12/2022 19.52, Ilias Apalodimas wrote:
Hi Janne,
[...]
function that can be called from board-specific code that sets the UUID.
Thoughts? Would such a feature be useful on other hardware platforms?
efi/boot/bootaarch64.efi is only a fallback if load options are not set up. Once the operating system has generated a load option it is not used anymore.
Setting load options from operation systems is currently not implemented. The only readily available method to store variables is a file in the ESP. This obviously can not be supported as UEFI runtime service while the operation system is using the same disk.
Yes, but I'd skip the 'currently not implemented' part. If you store your EFI variables in a file on the ESP, we will *never* be able to (sanely) support SetVariable at runtime.
It might be possible to use NOR flash as UEFI variable store. This could cause issues with the primary boot loader iboot which we can not avoid or with macOS in dual boot configurations.
It is possible. In fact we already have code in U-Boot that stores the EFI variables in an RPMB partition of the eMMC. We also have (unfortunately not yet upstreamed) code that stores the in an i2c eeprom in the secure world.
This is again situational though and none of these applies to MBPs. SetVariable at runtime in an RPMB comes with it's own set of problems. You basically need to replace the runtime services with OS provided ones... The I2C one works fine.
But letting the implementation details aside, what we need to keep in mind, is that being able to support SetVariable-RT primarily depends on the *hardware* and there's gonna be hardware we'll never be able to support this.
As far as I'm concerned, the NOR is an implementation detail under Apple's control and I would NAK any attempt at shoehorning EFI variables in there. This is global storage and Apple already have their own NVRAM format for boot settings (based on CHRP). Trying to abuse it for our own purposes is asking for trouble, since we can't coordinate anything like that with Apple. Plus there's a good chance they'll ditch the NOR and go NVMe-only in the future (they already do it like that on iOS devices). And if anything goes wrong we make user systems unbootable. Plus we still have the problem that there is a logical OS environment split before EFI, which means we'd still need multiple ESPs and an independent EFI variable store for each. And then if the EFI services owns the NOR, we *still* need to provide an Apple NVRAM interface to the OS, since we do want to be able to mutate that for things like configuring boot settings (boot chime, next boot OS, etc.) at the Apple/iBoot layer.
In my opinion, the only sane way to get EFI variables to work here is to use ubootefi.var and teach OSes how to manipulate it directly, in lieu of runtime services being available (or perhaps with some kind of callback layer so the OS can provide ESP file R/W services back to the runtime services). I'm not sure it's worth actually doing this, but I can't think of any other viable option if we decide we really want it.
- Hector
On Mon, Dec 19, 2022 at 08:18:43PM +0900, Hector Martin wrote:
On 19/12/2022 19.52, Ilias Apalodimas wrote:
Hi Janne,
[...]
function that can be called from board-specific code that sets the UUID.
Thoughts? Would such a feature be useful on other hardware platforms?
efi/boot/bootaarch64.efi is only a fallback if load options are not set up. Once the operating system has generated a load option it is not used anymore.
Setting load options from operation systems is currently not implemented. The only readily available method to store variables is a file in the ESP. This obviously can not be supported as UEFI runtime service while the operation system is using the same disk.
Yes, but I'd skip the 'currently not implemented' part. If you store your EFI variables in a file on the ESP, we will *never* be able to (sanely) support SetVariable at runtime.
It might be possible to use NOR flash as UEFI variable store. This could cause issues with the primary boot loader iboot which we can not avoid or with macOS in dual boot configurations.
It is possible. In fact we already have code in U-Boot that stores the EFI variables in an RPMB partition of the eMMC. We also have (unfortunately not yet upstreamed) code that stores the in an i2c eeprom in the secure world.
This is again situational though and none of these applies to MBPs. SetVariable at runtime in an RPMB comes with it's own set of problems. You basically need to replace the runtime services with OS provided ones... The I2C one works fine.
But letting the implementation details aside, what we need to keep in mind, is that being able to support SetVariable-RT primarily depends on the *hardware* and there's gonna be hardware we'll never be able to support this.
As far as I'm concerned, the NOR is an implementation detail under Apple's control and I would NAK any attempt at shoehorning EFI variables in there. This is global storage and Apple already have their own NVRAM format for boot settings (based on CHRP). Trying to abuse it for our own purposes is asking for trouble, since we can't coordinate anything like that with Apple. Plus there's a good chance they'll ditch the NOR and go NVMe-only in the future (they already do it like that on iOS devices). And if anything goes wrong we make user systems unbootable. Plus we still have the problem that there is a logical OS environment split before EFI, which means we'd still need multiple ESPs and an independent EFI variable store for each. And then if the EFI services owns the NOR, we *still* need to provide an Apple NVRAM interface to the OS, since we do want to be able to mutate that for things like configuring boot settings (boot chime, next boot OS, etc.) at the Apple/iBoot layer.
Yep we agree here
In my opinion, the only sane way to get EFI variables to work here is to use ubootefi.var and teach OSes how to manipulate it directly, in lieu of runtime services being available (or perhaps with some kind of callback layer so the OS can provide ESP file R/W services back to the runtime services). I'm not sure it's worth actually doing this, but I can't think of any other viable option if we decide we really want it.
We agree here as well. In fact we are doing exactly the same thing for variables that are stored in the RPMB (teach the OS how to do that) and we'll send an RFC shortly.
Unfortunately this is not optimal, since we will violate the EFI spec, but tbh there's nothing better we can do. The spec basically dictates your hardware configuration and if you don't have a dedicated storage for the variables, it offers no sane alternatives.
Cheers /Ilias
- Hector
On 19/12/2022 04.40, Heinrich Schuchardt wrote:
The MacBooks only have one drive. Why would you want two ESPs on one drive?
The boot model of these machines is fundamentally different from EFI.
There is top-level, built-in multiboot support. The boot stages are:
=== global === 1. iBoot1 (global bootloader + global firmware) === per OS / security context === 2. iBoot2 (OS loader + runtime firmware) 3. Whatever we want
Global firmware has ABI compatibility guarantees, but runtime firmware does not. That means that runtime firmware must be, to some extent, paired to the OS that is running under it. macOS implements this by always upgrading firmware in tandem with the OS. We implement this by having our OS support a subset of "blessed" firmwares, and automatically selecting the correct firmware for a to-be-installed OS at installation time.
We do *not* control the firmware load process and we *cannot* replace already running firmware with our own.
We extend this system by provisioning an EFI environment as step 3. This allows downstream OSes to use a more familiar boot environment. But since this EFI environment is *necessarily* tied to what the prior boot stages consider to be *one* OS with *one* set of firmware, running multiple OSes under the same EFI environment is a problem. There are also likely to be further issues in the future once we start integrating more with the platform's secure boot and SEP (think TPM) support, since from its point of view one top-level OS is one OS, not several.
Hence, multiple ESPs, one per top-level OS, with users expected to only install one persistent OS to each ESP (but retaining the ability to e.g. boot from USB for recovery, under the understanding that live-booted OSes would have to support the firmware in question and aren't going to try to do system management tasks that are the responsibility of the owner OS).
Additionally, this setup lets us define device trees and update the m1n1 second-stage loader with each OS, which is particularly important until all DT schemas are stabilized, since we can't guarantee backwards compatibility between DTs and OSes (although we try, we do have to break it sometimes). The DT, m1n1 (which populates runtime DT options), u-boot (DT consumer), and the OS (DT consumer) are all involved in this process, and need to be compatible to varying degrees. If the installed OS owns the ESP, it can take responsibility for updating the DT/m1n1/u-boot together with itself, which solves the compatibility issue (and makes the whole thing way more seamless for users).
I know "multiple ESPs" sounds weird in the context of traditional EFI systems, but it's the best we could come up with to shoehorn EFI into this very-much-not-EFI platform.
Further reading: https://github.com/AsahiLinux/docs/wiki/Open-OS-Ecosystem-on-Apple-Silicon-M...
Why can't the Asahi team use the current UEFI bootflow? We should avoid unneeded deviations. Can the current deviations be removed in Asahi Linux?
If you can come up with a better idea that actually works on these platforms and solves all the issues I mentioned above, I'm all ears.
- Hector
Date: Sun, 18 Dec 2022 20:40:20 +0100 From: Heinrich Schuchardt xypron.glpk@gmx.de
Hi Heinrich,
Hector already provided a more elaborate explanation of why we need multiple ESPs. But here is my repsonse to your comment about the fallback path that he didn't address.
Am 18. Dezember 2022 15:21:06 MEZ schrieb Mark Kettenis mark.kettenis@xs4all.nl:
The Asahi installer, which is what most people use to get their Apple Silicon Mac into a state where it is possible to install another OS on the machine, offers the posibility to create multiple OS installs. For each of these it creates a separate APFS partition (which holds among other things, some essential system firmware) and separate EFI System Partitions. This has a few benefits:
- It allows control over which version of the system firmware is used
by the OS. This is especially important for things like the GPU and DCP (display controller) firmware, where the firmware interface isn't exactly what we'd call "stable". This way system firmware is paired with the OS install (similar to what macOS does for itself) which prevents breaking other OS installs on the same disk.
- It allows us to store a 2nd stage bootloader (m1n1+u-boot+dtb) on
the EFI System Partition (ESP) such that it can be easily upgraded from within Linux without affecting other OS installs on the same disk.
- It allows the use of the "native" boot picker to switch between
OSes.
The approach the Asahi team has taken is to pair the APFS partition with the ESP by adding a proprty that contains the partition UUID to the device tree. The installer ships u-boot with a patched distro boot script that looks at this device tree property, figures out what the right ESP is and loads the EFI bootloader (efi/boot/bootaarch64.efi) from that partition.
This approach has some drawbacks:
- U-Boot will still consider the first ESP as *the* ESP, which means
that the ubootefi.var file is still read from and written from the first ESP.
- The distro boot script modifications don't work if U-Boot's
built-in efibootmgr is used. This probably also affects Simon's bootstd stuff.
So my idea is to have U-Boot recognize the device tree property and use it when it determines what partition is *the* ESP. A proof of concept diff is attached below. This probably needs a bit of massaging as reading the device tree property in generic EFI code like this is probably not acceptable. A better approach might be to have a function that can be called from board-specific code that sets the UUID.
Thoughts? Would such a feature be useful on other hardware platforms?
efi/boot/bootaarch64.efi is only a fallback if load options are not set up. Once the operating system has generated a load option it is not used anymore.
In theory yes. But like 99% of the machines supported by U-Boot, there is no runtime EFI variables support on the Apple machines. So the OS can't generate a load option and you'll end up always booting from the efi/boot/bootarch64.efi fallback.
The MacBooks only have one drive. Why would you want two ESPs on one drive?
Why can't the Asahi team use the current UEFI bootflow? We should avoid unneeded deviations. Can the current deviations be removed in Asahi Linux?
Best regards
Heinrich
commit 088f5626d4347cef76ad5a54477944886efb005a Author: Mark Kettenis kettenis@openbsd.org Date: Sun Sep 25 01:57:24 2022 +0200
HACK: Use designated ESP
Signed-off-by: Mark Kettenis kettenis@openbsd.org
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c index 7ea0334083..86b867d319 100644 --- a/lib/efi_loader/efi_disk.c +++ b/lib/efi_loader/efi_disk.c @@ -523,6 +523,27 @@ static efi_status_t efi_disk_add_dev( desc->devnum, part); } }
- ofnode chosen_node;
- const char *uuid = NULL;
- chosen_node = ofnode_path("/chosen");
- if (ofnode_valid(chosen_node)) {
uuid = ofnode_read_string(chosen_node,"asahi,efi-system-partition");- }
- /* Store designated EFI system partition */
- if (part && uuid && strcmp(uuid, part_info->uuid) == 0) {
if (part_info->bootable & PART_EFI_SYSTEM_PARTITION) {efi_system_partition.uclass_id = desc->uclass_id;efi_system_partition.devnum = desc->devnum;efi_system_partition.part = part;EFI_PRINT("EFI system partition: %s %x:%x\n",blk_get_uclass_name(desc->uclass_id),desc->devnum, part);}- }
- return EFI_SUCCESS;
error: efi_delete_handle(&diskobj->header);
participants (5)
-
Hector Martin -
Heinrich Schuchardt -
Ilias Apalodimas -
Janne Grunau -
Mark Kettenis