Bug 269564 - efibootmgr does not work when using gptlabels
Summary: efibootmgr does not work when using gptlabels
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 13.1-STABLE
Hardware: Any Any
: --- Affects Many People
Assignee: Warner Losh
URL: https://reviews.freebsd.org/D38610
Keywords:
Depends on:
Blocks:
 
Reported: 2023-02-15 08:27 UTC by Corvin Köhne
Modified: 2023-05-08 08:09 UTC (History)
2 users (show)

See Also:
asomers: mfc-stable13?
asomers: mfc-stable12?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Corvin Köhne freebsd_committer freebsd_triage 2023-02-15 08:27:53 UTC
FreeBSD 13.2 uses /dev/gpt/efiboot0 instead of /dev/ada0p1 to mount the efi partition. For that reason, efibootmgr -E does not work correctly:
```
root@ ~# mount
zroot/ROOT/default on / (zfs, local, noatime, nfsv4acls)
devfs on /dev (devfs)
/dev/gpt/efiboot0 on /boot/efi (msdosfs, local)
zroot/tmp on /tmp (zfs, local, noatime, nosuid, nfsv4acls)
zroot/var/log on /var/log (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot on /zroot (zfs, local, noatime, nfsv4acls)
zroot/var/mail on /var/mail (zfs, local, nfsv4acls)
zroot/usr/ports on /usr/ports (zfs, local, noatime, nosuid, nfsv4acls)
zroot/var/tmp on /var/tmp (zfs, local, noatime, nosuid, nfsv4acls)
zroot/usr/src on /usr/src (zfs, local, noatime, nfsv4acls)
zroot/usr/home on /usr/home (zfs, local, noatime, nfsv4acls)
zroot/var/crash on /var/crash (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/var/audit on /var/audit (zfs, local, noatime, noexec, nosuid, nfsv4acls)
root@ ~# efibootmgr -E -p
efibootmgr: Can't find where ada0p1:/EFI/BOOT/BOOTX64.EFI is mounted
```
Comment 1 Corvin Köhne freebsd_committer freebsd_triage 2023-02-15 11:16:57 UTC
The creation of new boot entries is broken too when using gptlabels.
```
root@ ~ [1]# efibootmgr -c -l /boot/efi/efi/boot/bootx64.efi -L "TEST"
efibootmgr: Cannot translate unix loader path '\boot\efi\efi\boot\bootx64.efi' to UEFI: No such file or directory
```
Comment 2 Warner Losh freebsd_committer freebsd_triage 2023-02-15 16:46:41 UTC
So, the problem here is that we have to walk through the geom tables to find the device the drive is on and then use that to get the meida id we need to create the UEFI path.

tl;dr: The code knows about gpart, but not glabel. It can't do it generically in geom because what do you say for gmirror / gstripe and other one to many and many to one mappings of multiple devices (the many to one in glabel at least is fine in that there's no ambiguity).

All that code is in libefivar/efivar-dp-xlate.c:find_geom_efi_on_root has the code that I ran out of time debugging to try to make this work. So all the walking is effectively commented out. There's also find_geom_efimedia which handles the well-formed cases in gpart.

I'm unsure when I'll get back to this, so I'm just commenting to maybe save people some time and to offer to review if somebody gets to this before I can scratch this itch.
Comment 3 Alan Somers freebsd_committer freebsd_triage 2023-02-15 18:42:16 UTC
I created a patch that fixes this specific problem.  However, my testing is limited.  I only tested on 13.1-RELEASE, and not 14.0-CURRENT.  And I did not test on any system that mounts the efi partition by its da number; only by its gpt label.

This patch also fixes the "efivar -Op <VAR>" command.  The "efidp -u" command is probably affected too, but I can't figure out how to exercise it.
Comment 4 Warner Losh freebsd_committer freebsd_triage 2023-02-15 22:18:24 UTC
efidp appears to be badly broken for converting host names to uefi paths, and vice versa... I'll worry about that since it's mostly used to test out new parsing and formatting code when we upgrade EDK2...

https://reviews.freebsd.org/D38619 is a different fix that I think will work better when there's multiple labels for a partition. They labels are suppressed in /dev, but the geom nodes still exist inside of geom when one of them is mounted.