Bug 229191 - efibootmgr(8) fails to create boot var when ESP is mounted using a gpt label
Summary: efibootmgr(8) fails to create boot var when ESP is mounted using a gpt label
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: Warner Losh
URL:
Keywords: needs-patch, uefi
Depends on:
Blocks:
 
Reported: 2018-06-20 21:45 UTC by Andre Lupa
Modified: 2024-11-28 03:23 UTC (History)
10 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Andre Lupa 2018-06-20 21:45:53 UTC 
Consider, for example, the following sequence:

# mount_msdosfs /dev/gpt/efisys /mnt
# mkdir -p /mnt/efi/freebsd
# cp /boot/loader.efi /mnt/efi/freebsd/loader.efi
# efibootmgr -c -l /mnt/efi/freebsd/loader.efi -L FreeBSD
efibootmgr: Cannot translate unix loader path '\mnt\efi\freebsd\loader.efi' to UEFI: No error: 0

If the ESP is mounted using a normal device path (e.g., /dev/ada0p1) then everything works fine.
Comment 1 O. Hartmann 2018-12-27 14:38:17 UTC 
Today,  I faced the very same problem on 13-CURRENT, 13.0-CURRENT #43 r342551: Thu Dec 27 14:51:56 CET 2018 amd64.

Mounting ESP via /dev/ada0p1 worked, while mounting via /dev/gpt/efiboot0 does not and did produce the error shown by the initiator of this PR.
Comment 2 Dave Cottlehuber freebsd_committer freebsd_triage 2020-11-21 21:00:43 UTC 
ditto, on 12.2R and 13.0-CURRENT still obviously.

It's worth noting that the boot var can be created successfully if the underlying msdosfs partition is provided in non-GPT mode:

root@akai /# efibootmgr -c -l nda0p1:/efi/ipxe/netboot.xyz.efi -L iPXE
BootCurrent: 0000
Timeout    : 0 seconds
BootOrder  : 0001, 0000
 Boot0001  iPXE
+Boot0000* efiBoot
root@akai /# mount -t msdosfs -p
/dev/gpt/efiboot	/efi			msdosfs	rw		0 0

root@akai /# efibootmgr -v
BootCurrent: 0000
Timeout    : 0 seconds
BootOrder  : 0001, 0000
 Boot0001  iPXE HD(1,GPT,d16765b3-317d-11e7-ab92-00249b24614a,0x28,0x12c000)/File(\efi\ipxe\netboot.xyz.efi)
                   nda0p1:/efi/ipxe/netboot.xyz.efi (null)
+Boot0000* efiBoot PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,d7-ed-0f-00-03-0d-08-00)/HD(1,GPT,d16765b3-317d-11e7-ab92-00249b24614a,0x28,0x12c000)/File(\efi\boot\bootx64.efi)
                      nda0p1:/efi/boot/bootx64.efi (null)
Comment 3 Rebecca Cran freebsd_committer freebsd_triage 2020-11-21 21:15:47 UTC 
I'm sorry I've not had a chance to work on this. I'm getting back to UEFI work on FreeBSD though, so hope to fix it in the next few weeks.
Comment 4 Warner Losh freebsd_committer freebsd_triage 2020-11-22 02:01:11 UTC 
The problem here is translating the upper layer GEOM constricts (which is what the GPT label stuff is) to the lower-layer providers. It should be possible to fix that matching code, but I lost patience trying to chase things down w/o hard coding too many things.
Comment 5 igor.polovykh 2022-01-04 20:54:44 UTC 
FreeBSD 13.0 x64
I have the same issue. Spent very much time. Thank you for workaround.
Comment 6 Graham Perrin 2023-09-24 12:27:04 UTC 
(In reply to Warner Losh from 2020 comment #4)

Fixed?
Comment 7 Warner Losh freebsd_committer freebsd_triage 2023-09-24 13:09:40 UTC 
I think it's still a bug.