Message ID | 20201108235855.28788-1-pc@cjr.nz |
---|---|
State | Rejected, archived |
Delegated to: | Heinrich Schuchardt |
Headers | show |
Series | efi_loader: improve detection of ESP for storing UEFI variables | expand |
On 09.11.20 00:58, Paulo Alcantara wrote: > The UEFI specification does not restrict on the number and location of > ESPs in a system. They are discovered as required by looking at the > partition type, but firmware implementations are allowed to support > ESPs which do not contain a valid partition type. I guess you refer to chapter "13.3.3 Number and Location of System Partitions" of the UEFI spec saying: "Further, UEFI implementations may allow the use of conforming FAT partitions which do not use the ESP GUID." Why should U-Boot support FAT partitions that are not of type FAT 0xef and GPT partition that do not use the ESP GUID? Best regards Heinrich > > Besides checking for the partition type, for non-removable media check > if /EFI directory exists, otherwise check if /EFI/BOOT/BOOT{ARCH}.EFI > file exists as specified in UEFI 2.8 "13.3.1.3 Directory Structure". > > Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz> > --- > lib/efi_loader/efi_disk.c | 60 +++++++++++++++++++++++++-------------- > 1 file changed, 38 insertions(+), 22 deletions(-) > > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c > index 7bd1ccec4501..2940a2edf2e8 100644 > --- a/lib/efi_loader/efi_disk.c > +++ b/lib/efi_loader/efi_disk.c > @@ -335,6 +335,35 @@ static int efi_fs_exists(struct blk_desc *desc, int part) > return 1; > } > > +/** > + * efi_part_is_esp() - check if a partition is an EFI system partition > + * > + * @desc: block device descriptor > + * @part: partition number > + * Return: true if a partition is an EFI system partition > + * false otherwise > + */ > +static bool efi_part_is_esp(struct blk_desc *desc, int part) > +{ > + int ret; > + struct disk_partition info; > + > + ret = part_get_info(desc, part, &info); > + if (ret) > + return false; > + > + if (info.bootable & PART_EFI_SYSTEM_PARTITION) > + return true; > + > + if (fs_set_blk_dev_with_part(desc, part)) > + return false; > + > + if (!desc->removable) > + return !!fs_exists("/EFI"); > + > + return !!fs_exists("/EFI/BOOT/" BOOTEFI_NAME); > +} > + > /** > * efi_disk_add_dev() - create a handle for a partition or disk > * > @@ -436,21 +465,14 @@ static efi_status_t efi_disk_add_dev( > *disk = diskobj; > > /* Store first EFI system partition */ > - if (part && !efi_system_partition.if_type) { > - int r; > - struct disk_partition info; > - > - r = part_get_info(desc, part, &info); > - if (r) > - return EFI_DEVICE_ERROR; > - if (info.bootable & PART_EFI_SYSTEM_PARTITION) { > - efi_system_partition.if_type = desc->if_type; > - efi_system_partition.devnum = desc->devnum; > - efi_system_partition.part = part; > - EFI_PRINT("EFI system partition: %s %d:%d\n", > - blk_get_if_type_name(desc->if_type), > - desc->devnum, part); > - } > + if (part && !efi_system_partition.if_type && > + efi_part_is_esp(desc, part)) { > + efi_system_partition.if_type = desc->if_type; > + efi_system_partition.devnum = desc->devnum; > + efi_system_partition.part = part; > + EFI_PRINT("EFI system partition: %s %d:%d\n", > + blk_get_if_type_name(desc->if_type), > + desc->devnum, part); > } > return EFI_SUCCESS; > } > @@ -614,9 +636,7 @@ bool efi_disk_is_system_part(efi_handle_t handle) > { > struct efi_handler *handler; > struct efi_disk_obj *diskobj; > - struct disk_partition info; > efi_status_t ret; > - int r; > > /* check if this is a block device */ > ret = efi_search_protocol(handle, &efi_block_io_guid, &handler); > @@ -625,9 +645,5 @@ bool efi_disk_is_system_part(efi_handle_t handle) > > diskobj = container_of(handle, struct efi_disk_obj, header); > > - r = part_get_info(diskobj->desc, diskobj->part, &info); > - if (r) > - return false; > - > - return !!(info.bootable & PART_EFI_SYSTEM_PARTITION); > + return efi_part_is_esp(diskobj->desc, diskobj->part); > } >
Heinrich Schuchardt <xypron.glpk@gmx.de> writes: > On 09.11.20 00:58, Paulo Alcantara wrote: >> The UEFI specification does not restrict on the number and location of >> ESPs in a system. They are discovered as required by looking at the >> partition type, but firmware implementations are allowed to support >> ESPs which do not contain a valid partition type. > > I guess you refer to chapter "13.3.3 Number and Location of System > Partitions" of the UEFI spec saying: "Further, UEFI implementations > may allow the use of conforming FAT partitions which do not use the > ESP GUID." Yep, sorry. Thanks for pointing it out! > Why should U-Boot support FAT partitions that are not of type FAT 0xef > and GPT partition that do not use the ESP GUID? In most UEFI (EDK2-based) systems I used, I could boot my OSes and diagnostic tools by simply having a supported filesystem (FAT12/16/32) and /EFI/BOOT/BOOT{ARCH}.EFI file and never cared about setting the partition type at all. It took me a while for figuring out why I couldn't get my UEFI variables loaded from my FAT partition that contained /ubootefi.var and /EFI/BOOT/BOOTAA64.efi files. I am not trying to support ESPs that lack the appropriate partition type everywhere in U-Boot, but at least for the UEFI variables (ubootefi.var) feature seemed a nice thing to have. Perhaps we could make it a separate config option like "Allow searching for ESPs without partition type" and default it to N, don't know...
> From: Paulo Alcantara <pc@cjr.nz> > Date: Mon, 09 Nov 2020 10:24:08 -0300 > > Heinrich Schuchardt <xypron.glpk@gmx.de> writes: > > > On 09.11.20 00:58, Paulo Alcantara wrote: > >> The UEFI specification does not restrict on the number and location of > >> ESPs in a system. They are discovered as required by looking at the > >> partition type, but firmware implementations are allowed to support > >> ESPs which do not contain a valid partition type. > > > > I guess you refer to chapter "13.3.3 Number and Location of System > > Partitions" of the UEFI spec saying: "Further, UEFI implementations > > may allow the use of conforming FAT partitions which do not use the > > ESP GUID." > > Yep, sorry. Thanks for pointing it out! > > > Why should U-Boot support FAT partitions that are not of type FAT 0xef > > and GPT partition that do not use the ESP GUID? > > In most UEFI (EDK2-based) systems I used, I could boot my OSes and > diagnostic tools by simply having a supported filesystem (FAT12/16/32) > and /EFI/BOOT/BOOT{ARCH}.EFI file and never cared about setting the > partition type at all. It took me a while for figuring out why I > couldn't get my UEFI variables loaded from my FAT partition that > contained /ubootefi.var and /EFI/BOOT/BOOTAA64.efi files. The OpenBSD installation media for armv7 and arm64 use a FAT partition of type 0x0c because the Raspberry Pi firmware doesn't support 0xef. This allows us to have a single FAT partition with the Raspberry Pi firmware, U-Boot and /EFI/BOOT/BOOT{ARCH}.EFI. So far this works on all UEFI firmware I've tried (EDK2, U-Boot and AMI AptioV UEFI).
On 09.11.20 14:24, Paulo Alcantara wrote: > Heinrich Schuchardt <xypron.glpk@gmx.de> writes: > >> On 09.11.20 00:58, Paulo Alcantara wrote: >>> The UEFI specification does not restrict on the number and location of >>> ESPs in a system. They are discovered as required by looking at the >>> partition type, but firmware implementations are allowed to support >>> ESPs which do not contain a valid partition type. >> >> I guess you refer to chapter "13.3.3 Number and Location of System >> Partitions" of the UEFI spec saying: "Further, UEFI implementations >> may allow the use of conforming FAT partitions which do not use the >> ESP GUID." > > Yep, sorry. Thanks for pointing it out! > >> Why should U-Boot support FAT partitions that are not of type FAT 0xef >> and GPT partition that do not use the ESP GUID? > > In most UEFI (EDK2-based) systems I used, I could boot my OSes and > diagnostic tools by simply having a supported filesystem (FAT12/16/32) > and /EFI/BOOT/BOOT{ARCH}.EFI file and never cared about setting the > partition type at all. It took me a while for figuring out why I > couldn't get my UEFI variables loaded from my FAT partition that > contained /ubootefi.var and /EFI/BOOT/BOOTAA64.efi files. > > I am not trying to support ESPs that lack the appropriate partition type > everywhere in U-Boot, but at least for the UEFI variables (ubootefi.var) > feature seemed a nice thing to have. > > Perhaps we could make it a separate config option like "Allow searching > for ESPs without partition type" and default it to N, don't know... > In your last mail you wrote you are working for SUSE. Is there a bug in the SUSE installer that makes it create the wrong partition type? Best regards Heinrich
Mark Kettenis <mark.kettenis@xs4all.nl> writes: > The OpenBSD installation media for armv7 and arm64 use a FAT partition > of type 0x0c because the Raspberry Pi firmware doesn't support 0xef. > This allows us to have a single FAT partition with the Raspberry Pi > firmware, U-Boot and /EFI/BOOT/BOOT{ARCH}.EFI. Yeah, it is the same partition type that my openSUSE Tumbleweed image has and everything boots fine on rpi4. My only problem with not having the partition type of 0xef in MBR is that my UEFI variables (/ubootefi.var) could not be loaded because U-Boot did not detect an ESP to either read or store them, but the UEFI boot worked regardless.
On 09.11.20 14:51, Mark Kettenis wrote: >> From: Paulo Alcantara <pc@cjr.nz> >> Date: Mon, 09 Nov 2020 10:24:08 -0300 >> >> Heinrich Schuchardt <xypron.glpk@gmx.de> writes: >> >>> On 09.11.20 00:58, Paulo Alcantara wrote: >>>> The UEFI specification does not restrict on the number and location of >>>> ESPs in a system. They are discovered as required by looking at the >>>> partition type, but firmware implementations are allowed to support >>>> ESPs which do not contain a valid partition type. >>> >>> I guess you refer to chapter "13.3.3 Number and Location of System >>> Partitions" of the UEFI spec saying: "Further, UEFI implementations >>> may allow the use of conforming FAT partitions which do not use the >>> ESP GUID." >> >> Yep, sorry. Thanks for pointing it out! >> >>> Why should U-Boot support FAT partitions that are not of type FAT 0xef >>> and GPT partition that do not use the ESP GUID? >> >> In most UEFI (EDK2-based) systems I used, I could boot my OSes and >> diagnostic tools by simply having a supported filesystem (FAT12/16/32) >> and /EFI/BOOT/BOOT{ARCH}.EFI file and never cared about setting the >> partition type at all. It took me a while for figuring out why I >> couldn't get my UEFI variables loaded from my FAT partition that >> contained /ubootefi.var and /EFI/BOOT/BOOTAA64.efi files. > > The OpenBSD installation media for armv7 and arm64 use a FAT partition > of type 0x0c because the Raspberry Pi firmware doesn't support 0xef. > This allows us to have a single FAT partition with the Raspberry Pi > firmware, U-Boot and /EFI/BOOT/BOOT{ARCH}.EFI. > > So far this works on all UEFI firmware I've tried (EDK2, U-Boot and > AMI AptioV UEFI). > The issue Paulo was addressing is that U-Boot only persists non-volatile UEFI variables if it can find a partition indicated as ESP by the partition type. This becomes interesting if you want to have both Linux and OpenBSD on the same device and you want to use UEFI boot variables to decide which operating system to boot or if you want to use secure boot. On Debian the ESP is an 0xef partition mounted at /boot/efi. SUSE recommends the same: https://www.suse.com/support/kb/doc/?id=000017007 https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-uefi.html For a Raspberry I typically would have the following partitions: / - root file system /boot/firmware - *first* FAT partition /boot/efi - ESP, FAT formatted As /boot/firmware and /boot/efi can be separate partitions with different partition type why does OpenBSD not use this scheme? Best regards Heinrich
On 09.11.20 15:35, Paulo Alcantara wrote: > Mark Kettenis <mark.kettenis@xs4all.nl> writes: > >> The OpenBSD installation media for armv7 and arm64 use a FAT partition >> of type 0x0c because the Raspberry Pi firmware doesn't support 0xef. >> This allows us to have a single FAT partition with the Raspberry Pi >> firmware, U-Boot and /EFI/BOOT/BOOT{ARCH}.EFI. > > Yeah, it is the same partition type that my openSUSE Tumbleweed image > has and everything boots fine on rpi4. > > My only problem with not having the partition type of 0xef in MBR is > that my UEFI variables (/ubootefi.var) could not be loaded because > U-Boot did not detect an ESP to either read or store them, but the UEFI > boot worked regardless. > Hello Matthias, While SUSE generally recommends to have an ESP partition with partition type 0xef this is not so on the Raspberry images, e.g. http://download.opensuse.org/ports/aarch64/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64.raw.xz Device Boot Start End Sectors Size Id Type openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64.raw1 2048 133119 131072 64M c W95 FAT32 (LBA) openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64.raw2 133120 1157119 1024000 500M 82 Linux swap / Solaris openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64.raw3 1157120 4610014 3452895 1.6G 83 Linux Why is SUSE not using a separate ESP partition mounted as /boot/efi here? The mail thread starts here: https://lists.denx.de/pipermail/u-boot/2020-November/432223.html Best regards Heinrich
> From: Heinrich Schuchardt <xypron.glpk@gmx.de> > Date: Mon, 9 Nov 2020 15:36:33 +0100 > > On 09.11.20 14:51, Mark Kettenis wrote: > >> From: Paulo Alcantara <pc@cjr.nz> > >> Date: Mon, 09 Nov 2020 10:24:08 -0300 > >> > >> Heinrich Schuchardt <xypron.glpk@gmx.de> writes: > >> > >>> On 09.11.20 00:58, Paulo Alcantara wrote: > >>>> The UEFI specification does not restrict on the number and location of > >>>> ESPs in a system. They are discovered as required by looking at the > >>>> partition type, but firmware implementations are allowed to support > >>>> ESPs which do not contain a valid partition type. > >>> > >>> I guess you refer to chapter "13.3.3 Number and Location of System > >>> Partitions" of the UEFI spec saying: "Further, UEFI implementations > >>> may allow the use of conforming FAT partitions which do not use the > >>> ESP GUID." > >> > >> Yep, sorry. Thanks for pointing it out! > >> > >>> Why should U-Boot support FAT partitions that are not of type FAT 0xef > >>> and GPT partition that do not use the ESP GUID? > >> > >> In most UEFI (EDK2-based) systems I used, I could boot my OSes and > >> diagnostic tools by simply having a supported filesystem (FAT12/16/32) > >> and /EFI/BOOT/BOOT{ARCH}.EFI file and never cared about setting the > >> partition type at all. It took me a while for figuring out why I > >> couldn't get my UEFI variables loaded from my FAT partition that > >> contained /ubootefi.var and /EFI/BOOT/BOOTAA64.efi files. > > > > The OpenBSD installation media for armv7 and arm64 use a FAT partition > > of type 0x0c because the Raspberry Pi firmware doesn't support 0xef. > > This allows us to have a single FAT partition with the Raspberry Pi > > firmware, U-Boot and /EFI/BOOT/BOOT{ARCH}.EFI. > > > > So far this works on all UEFI firmware I've tried (EDK2, U-Boot and > > AMI AptioV UEFI). > > > > The issue Paulo was addressing is that U-Boot only persists non-volatile > UEFI variables if it can find a partition indicated as ESP by the > partition type. > > This becomes interesting if you want to have both Linux and OpenBSD on > the same device and you want to use UEFI boot variables to decide which > operating system to boot or if you want to use secure boot. > > On Debian the ESP is an 0xef partition mounted at /boot/efi. > > SUSE recommends the same: > https://www.suse.com/support/kb/doc/?id=000017007 > https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-uefi.html > > For a Raspberry I typically would have the following partitions: > > / - root file system > /boot/firmware - *first* FAT partition > /boot/efi - ESP, FAT formatted > > As /boot/firmware and /boot/efi can be separate partitions with > different partition type why does OpenBSD not use this scheme? Two reasons: 1. The installer and the scripts that build the installer image only support creating a single FAT partition. 2. Adding another FAT partition would consume another slot in the disklabel[1] which doesn't have a lot of empty slots left for a default install. Cheers, Mark [1] A disklabel is the platform-independent partition table that is used by BSD systems and for example Solaris on SPARC.
On 09.11.20 18:08, Mark Kettenis wrote: >> From: Heinrich Schuchardt <xypron.glpk@gmx.de> >> Date: Mon, 9 Nov 2020 15:36:33 +0100 >> >> On 09.11.20 14:51, Mark Kettenis wrote: >>>> From: Paulo Alcantara <pc@cjr.nz> >>>> Date: Mon, 09 Nov 2020 10:24:08 -0300 >>>> >>>> Heinrich Schuchardt <xypron.glpk@gmx.de> writes: >>>> >>>>> On 09.11.20 00:58, Paulo Alcantara wrote: >>>>>> The UEFI specification does not restrict on the number and location of >>>>>> ESPs in a system. They are discovered as required by looking at the >>>>>> partition type, but firmware implementations are allowed to support >>>>>> ESPs which do not contain a valid partition type. >>>>> >>>>> I guess you refer to chapter "13.3.3 Number and Location of System >>>>> Partitions" of the UEFI spec saying: "Further, UEFI implementations >>>>> may allow the use of conforming FAT partitions which do not use the >>>>> ESP GUID." >>>> >>>> Yep, sorry. Thanks for pointing it out! >>>> >>>>> Why should U-Boot support FAT partitions that are not of type FAT 0xef >>>>> and GPT partition that do not use the ESP GUID? >>>> >>>> In most UEFI (EDK2-based) systems I used, I could boot my OSes and >>>> diagnostic tools by simply having a supported filesystem (FAT12/16/32) >>>> and /EFI/BOOT/BOOT{ARCH}.EFI file and never cared about setting the >>>> partition type at all. It took me a while for figuring out why I >>>> couldn't get my UEFI variables loaded from my FAT partition that >>>> contained /ubootefi.var and /EFI/BOOT/BOOTAA64.efi files. >>> >>> The OpenBSD installation media for armv7 and arm64 use a FAT partition >>> of type 0x0c because the Raspberry Pi firmware doesn't support 0xef. >>> This allows us to have a single FAT partition with the Raspberry Pi >>> firmware, U-Boot and /EFI/BOOT/BOOT{ARCH}.EFI. >>> >>> So far this works on all UEFI firmware I've tried (EDK2, U-Boot and >>> AMI AptioV UEFI). >>> >> >> The issue Paulo was addressing is that U-Boot only persists non-volatile >> UEFI variables if it can find a partition indicated as ESP by the >> partition type. >> >> This becomes interesting if you want to have both Linux and OpenBSD on >> the same device and you want to use UEFI boot variables to decide which >> operating system to boot or if you want to use secure boot. >> >> On Debian the ESP is an 0xef partition mounted at /boot/efi. >> >> SUSE recommends the same: >> https://www.suse.com/support/kb/doc/?id=000017007 >> https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-uefi.html >> >> For a Raspberry I typically would have the following partitions: >> >> / - root file system >> /boot/firmware - *first* FAT partition >> /boot/efi - ESP, FAT formatted >> >> As /boot/firmware and /boot/efi can be separate partitions with >> different partition type why does OpenBSD not use this scheme? > > Two reasons: > > 1. The installer and the scripts that build the installer image only > support creating a single FAT partition. > > 2. Adding another FAT partition would consume another slot in the > disklabel[1] which doesn't have a lot of empty slots left for a > default install. OpenBSD itself uses just a single partition of type 0xa6 on the SD-Card. U-Boot supports logical partitions. So you can have three primary partitions and additionally 60 logical partitions in your extended partition. So the number of available slots should be the least of your worries. Best regards Heinrich > > Cheers, > > Mark > > [1] A disklabel is the platform-independent partition table that is > used by BSD systems and for example Solaris on SPARC. >
On Sat, Nov 14, 2020 at 05:56:38AM +0100, Heinrich Schuchardt wrote: > On 09.11.20 18:08, Mark Kettenis wrote: > >> From: Heinrich Schuchardt <xypron.glpk@gmx.de> > >> Date: Mon, 9 Nov 2020 15:36:33 +0100 > >> > >> On 09.11.20 14:51, Mark Kettenis wrote: > >>>> From: Paulo Alcantara <pc@cjr.nz> > >>>> Date: Mon, 09 Nov 2020 10:24:08 -0300 > >>>> > >>>> Heinrich Schuchardt <xypron.glpk@gmx.de> writes: > >>>> > >>>>> On 09.11.20 00:58, Paulo Alcantara wrote: > >>>>>> The UEFI specification does not restrict on the number and location of > >>>>>> ESPs in a system. They are discovered as required by looking at the > >>>>>> partition type, but firmware implementations are allowed to support > >>>>>> ESPs which do not contain a valid partition type. > >>>>> > >>>>> I guess you refer to chapter "13.3.3 Number and Location of System > >>>>> Partitions" of the UEFI spec saying: "Further, UEFI implementations > >>>>> may allow the use of conforming FAT partitions which do not use the > >>>>> ESP GUID." > >>>> > >>>> Yep, sorry. Thanks for pointing it out! > >>>> > >>>>> Why should U-Boot support FAT partitions that are not of type FAT 0xef > >>>>> and GPT partition that do not use the ESP GUID? > >>>> > >>>> In most UEFI (EDK2-based) systems I used, I could boot my OSes and > >>>> diagnostic tools by simply having a supported filesystem (FAT12/16/32) > >>>> and /EFI/BOOT/BOOT{ARCH}.EFI file and never cared about setting the > >>>> partition type at all. It took me a while for figuring out why I > >>>> couldn't get my UEFI variables loaded from my FAT partition that > >>>> contained /ubootefi.var and /EFI/BOOT/BOOTAA64.efi files. > >>> > >>> The OpenBSD installation media for armv7 and arm64 use a FAT partition > >>> of type 0x0c because the Raspberry Pi firmware doesn't support 0xef. > >>> This allows us to have a single FAT partition with the Raspberry Pi > >>> firmware, U-Boot and /EFI/BOOT/BOOT{ARCH}.EFI. > >>> > >>> So far this works on all UEFI firmware I've tried (EDK2, U-Boot and > >>> AMI AptioV UEFI). > >>> > >> > >> The issue Paulo was addressing is that U-Boot only persists non-volatile > >> UEFI variables if it can find a partition indicated as ESP by the > >> partition type. > >> > >> This becomes interesting if you want to have both Linux and OpenBSD on > >> the same device and you want to use UEFI boot variables to decide which > >> operating system to boot or if you want to use secure boot. > >> > >> On Debian the ESP is an 0xef partition mounted at /boot/efi. > >> > >> SUSE recommends the same: > >> https://www.suse.com/support/kb/doc/?id=000017007 > >> https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-uefi.html > >> > >> For a Raspberry I typically would have the following partitions: > >> > >> / - root file system > >> /boot/firmware - *first* FAT partition > >> /boot/efi - ESP, FAT formatted > >> > >> As /boot/firmware and /boot/efi can be separate partitions with > >> different partition type why does OpenBSD not use this scheme? > > > > Two reasons: > > > > 1. The installer and the scripts that build the installer image only > > support creating a single FAT partition. > > > > 2. Adding another FAT partition would consume another slot in the > > disklabel[1] which doesn't have a lot of empty slots left for a > > default install. > > OpenBSD itself uses just a single partition of type 0xa6 on the SD-Card. > > U-Boot supports logical partitions. So you can have three primary > partitions and additionally 60 logical partitions in your extended > partition. So the number of available slots should be the least of your > worries. mbr, gpt, apple partion map, sgi disklabel etc are all mapped onto an OpenBSD disklabel, one is spoofed if it doesn't exist. https://man.openbsd.org/disklabel.5 "disklabel only supports up to a maximum of 15 partitions, ‘a’ through ‘p’, excluding ‘c’. The ‘c’ partition is reserved for the entire physical disk. By convention, the ‘a’ partition of the boot disk is the root partition, and the ‘b’ partition of the boot disk is the swap partition, but all other letters can be used in any order for any other partitions as desired." What looks like a single mbr partition is normally used as multiple disklabel partitions. For swap /tmp /var etc. Partitions outside the OpenBSD area like FAT start showing up at 'i'.
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c index 7bd1ccec4501..2940a2edf2e8 100644 --- a/lib/efi_loader/efi_disk.c +++ b/lib/efi_loader/efi_disk.c @@ -335,6 +335,35 @@ static int efi_fs_exists(struct blk_desc *desc, int part) return 1; } +/** + * efi_part_is_esp() - check if a partition is an EFI system partition + * + * @desc: block device descriptor + * @part: partition number + * Return: true if a partition is an EFI system partition + * false otherwise + */ +static bool efi_part_is_esp(struct blk_desc *desc, int part) +{ + int ret; + struct disk_partition info; + + ret = part_get_info(desc, part, &info); + if (ret) + return false; + + if (info.bootable & PART_EFI_SYSTEM_PARTITION) + return true; + + if (fs_set_blk_dev_with_part(desc, part)) + return false; + + if (!desc->removable) + return !!fs_exists("/EFI"); + + return !!fs_exists("/EFI/BOOT/" BOOTEFI_NAME); +} + /** * efi_disk_add_dev() - create a handle for a partition or disk * @@ -436,21 +465,14 @@ static efi_status_t efi_disk_add_dev( *disk = diskobj; /* Store first EFI system partition */ - if (part && !efi_system_partition.if_type) { - int r; - struct disk_partition info; - - r = part_get_info(desc, part, &info); - if (r) - return EFI_DEVICE_ERROR; - if (info.bootable & PART_EFI_SYSTEM_PARTITION) { - efi_system_partition.if_type = desc->if_type; - efi_system_partition.devnum = desc->devnum; - efi_system_partition.part = part; - EFI_PRINT("EFI system partition: %s %d:%d\n", - blk_get_if_type_name(desc->if_type), - desc->devnum, part); - } + if (part && !efi_system_partition.if_type && + efi_part_is_esp(desc, part)) { + efi_system_partition.if_type = desc->if_type; + efi_system_partition.devnum = desc->devnum; + efi_system_partition.part = part; + EFI_PRINT("EFI system partition: %s %d:%d\n", + blk_get_if_type_name(desc->if_type), + desc->devnum, part); } return EFI_SUCCESS; } @@ -614,9 +636,7 @@ bool efi_disk_is_system_part(efi_handle_t handle) { struct efi_handler *handler; struct efi_disk_obj *diskobj; - struct disk_partition info; efi_status_t ret; - int r; /* check if this is a block device */ ret = efi_search_protocol(handle, &efi_block_io_guid, &handler); @@ -625,9 +645,5 @@ bool efi_disk_is_system_part(efi_handle_t handle) diskobj = container_of(handle, struct efi_disk_obj, header); - r = part_get_info(diskobj->desc, diskobj->part, &info); - if (r) - return false; - - return !!(info.bootable & PART_EFI_SYSTEM_PARTITION); + return efi_part_is_esp(diskobj->desc, diskobj->part); }
The UEFI specification does not restrict on the number and location of ESPs in a system. They are discovered as required by looking at the partition type, but firmware implementations are allowed to support ESPs which do not contain a valid partition type. Besides checking for the partition type, for non-removable media check if /EFI directory exists, otherwise check if /EFI/BOOT/BOOT{ARCH}.EFI file exists as specified in UEFI 2.8 "13.3.1.3 Directory Structure". Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz> --- lib/efi_loader/efi_disk.c | 60 +++++++++++++++++++++++++-------------- 1 file changed, 38 insertions(+), 22 deletions(-)