Bug 230871 - efibootmgr lacks necessary functionality
Summary: efibootmgr lacks necessary functionality
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 11.2-RELEASE
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-24 21:15 UTC by Mason Loring Bliss
Modified: 2021-07-31 05:14 UTC (History)
5 users (show)

See Also:


Attachments
The missing functionality, caught in the wild. (161.96 KB, image/jpeg)
2018-08-24 21:15 UTC, Mason Loring Bliss
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mason Loring Bliss freebsd_triage 2018-08-24 21:15:51 UTC
Created attachment 196507 [details]
The missing functionality, caught in the wild.

Let it never be said that the developers lack a sense of humour.

Bug 230080 would have you think that documentation is missing. But no, in fact, functionality is missing.

See attached photo.
Comment 1 Mason Loring Bliss freebsd_triage 2018-08-24 21:41:08 UTC
FWIW, this mattered because I have an old UEFI system that doesn't use the default loader path and in fact requires an explicit path, which I couldn't set using the FreeBSD tool.

Base Board Information
        Manufacturer: ASUSTeK COMPUTER INC.
        Product Name: P8H61-M LX PLUS R2.0
Processor Information
        Socket Designation: LGA1155
        Type: Central Processor
        Family: Core 2 Duo
        Version: Intel(R) Pentium(R) CPU G860 @ 3.00GHz
Comment 2 Mason Loring Bliss freebsd_triage 2018-08-24 21:57:00 UTC
I guess since this is a reasonable place to note it, diverging from the Linux efibootmgr syntax is a really bad idea. It works, and people have finger memory now. If you're going to have a wholly new syntax, please rename the tool so it's obvious the Linux tool's syntax isn't appropriate.
Comment 3 Kyle Evans freebsd_committer freebsd_triage 2018-08-24 21:59:19 UTC
CC imp@
Comment 4 Mason Loring Bliss freebsd_triage 2018-08-24 22:05:55 UTC
So, rather than your renaming this, I'm going to have a look at the code and see if I can submit useful patches to make it compatible with the Linux implementation. If so, that'd probably be a lot more useful.
Comment 5 Warner Losh freebsd_committer freebsd_triage 2018-08-25 02:25:48 UTC
functionality not missing. Just say -l ada0s1:/path/to/loader
Comment 6 Warner Losh freebsd_committer freebsd_triage 2018-08-25 02:26:41 UTC
(In reply to Mason Loring Bliss from comment #4)
I'm not at all interested in making it Linux compatible. That turns out to be quite hard and not as useful as one would hope since device names are different.
Comment 7 Mason Loring Bliss freebsd_triage 2018-08-25 13:07:25 UTC
Ah, I'd missed that I could add a decide to the loader path. That's useful.

I would recommend renaming if this won't be finger-compatible with the Linux equivalent. It being awfully close right now and having the same name violates the principle of least surprise.

Thank you for writing this, either way. Please feel free to close this unless you want it as a reminder to consider renaming.
Comment 8 Mason Loring Bliss freebsd_triage 2018-08-25 13:08:13 UTC
s/decide/device/

pre-coffee spelling
Comment 9 op 2018-08-25 13:40:07 UTC
(In reply to Mason Loring Bliss from comment #7)

Why should we rename the efibootmgr?! There are a plenty of utilities in unix world from the same named but differently behaving tools. Starting from tar, cp, mv and a lot CLI tool..
Comment 11 Mason Loring Bliss freebsd_triage 2018-08-26 19:05:35 UTC
I can open a new bug for this if desired, but I've just observed some odd behaviour:

# efibootmgr
BootCurrent: 0003
Timeout : 0 seconds
BootOrder : 0001, 0002, 0003
Boot0003* UEFI: USB Flash Disk 5.00
Boot0002* ubuntu
Boot0001* ubuntu
# efibootmgr -v
BootCurrent: 0003
Timeout : 0 seconds
BootOrder : 0001, 0002, 0003
Boot0003* UEFI: USB Flash Disk 5.00 PciRoot(0x0)/Pci(0x1d,0x0)/USB(0x1,0x0)/USB(0x1,0x0)/HD(1,MBR,0x90909090,0x1,0x640)
                                    VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6,550053004200200046006c0061007300680020004400690073006b00200035002e00300030000000)
Boot0002* ubuntu HD(1,GPT,f1281cb5-3ae3-4988-aff1-5d504d404eb8,0x800,0x5f000)/File(EFI\Ubuntu\grubx64.efi)
^C

Which is to say, -v isn't returning on its own for some reason.

If I delete the two Ubuntu entries shows above, it starts to return on its own:

# efibootmgr -B 1
Removing boot variable 'Boot0001'
Removing 0x1 from BootOrder
BootCurrent: 0003
Timeout : 0 seconds
BootOrder : 0002, 0003
Boot0003* UEFI: USB Flash Disk 5.00
Boot0002* ubuntu
# efibootmgr -B 2
Removing boot variable 'Boot0002'
Removing 0x2 from BootOrder
BootCurrent: 0003
Timeout : 0 seconds
BootOrder : 0003
Boot0003* UEFI: USB Flash Disk 5.00
# efibootmgr -v
BootCurrent: 0003
Timeout : 0 seconds
BootOrder : 0003
Boot0003* UEFI: USB Flash Disk 5.00 PciRoot(0x0)/Pci(0x1d,0x0)/USB(0x1,0x0)/USB(0x1,0x0)/HD(1,MBR,0x90909090,0x1,0x640)
                                    VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6,550053004200200046006c0061007300680020004400690073006b00200035002e00300030000000)
#
Comment 12 Mason Loring Bliss freebsd_triage 2018-08-26 19:08:44 UTC
Confirmation, FWIW, that the -l dev:path syntax works, and that efibootmgr -v returns with multiple entries it has created:

# efibootmgr -c -L freebsd0 -l ada0p1:/efi/freebsd/boot1.efi
BootCurrent: 0003
Timeout : 0 seconds
BootOrder : 0000, 0003
Boot0000  freebsd0
Boot0003* UEFI: USB Flash Disk 5.00
# efibootmgr -c -L freebsd1 -l ada1p1:/efi/freebsd/boot1.efi
BootCurrent: 0003
Timeout : 0 seconds
BootOrder : 0001, 0000, 0003
Boot0001  freebsd1
Boot0000  freebsd0
Boot0003* UEFI: USB Flash Disk 5.00
# efibootmgr -o 1,2,3
BootCurrent: 0003
Timeout : 0 seconds
BootOrder : 0001, 0002, 0003
Boot0001  freebsd1
Boot0000  freebsd0
Boot0003* UEFI: USB Flash Disk 5.00
# efibootmgr -v
BootCurrent: 0003
Timeout : 0 seconds
BootOrder : 0001, 0002, 0003
Boot0001  freebsd1 HD(1,GPT,832690d8-a961-11e8-a32f-6805ca0f3135,0x28,0x800)/File(\efi\freebsd\boot1.efi)
                       ada1p1:/efi/freebsd/boot1.efi (null)
Boot0000  freebsd0 HD(1,GPT,8315c685-a961-11e8-a32f-6805ca0f3135,0x28,0x800)/File(\efi\freebsd\boot1.efi)
                       ada0p1:/efi/freebsd/boot1.efi (null)
Boot0003* UEFI: USB Flash Disk 5.00 PciRoot(0x0)/Pci(0x1d,0x0)/USB(0x1,0x0)/USB(0x1,0x0)/HD(1,MBR,0x90909090,0x1,0x640)
                                    VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6,550053004200200046006c0061007300680020004400690073006b00200035002e00300030000000)
#
Comment 13 Mason Loring Bliss freebsd_triage 2018-08-26 19:18:48 UTC
Well. I rebooted, and the ordering I set in my last comment didn't "take". Which is to say, the two FreeBSD entries I created were available and visible to UEFI as options, but neither was in the chain of options to try, which was empty. Once I assigned an order manually the system was happy with it.
Comment 14 Mason Loring Bliss freebsd_triage 2018-10-15 21:36:00 UTC
This doesn't seem to like to activate 0. Making a duplicate entry on 2 allowed me to activate the desired bootloader, and efibootmgr was evidently willing to delete 0, if not activate it.

# efibootmgr
BootCurrent: 0004
Timeout : 0 seconds
BootOrder : 0001, 0000, 0004
Boot0001* freebsd1
Boot0000  freebsd0
Boot0004* UEFI: USB Flash Disk 5.00
# efibootmgr -v
BootCurrent: 0004
Timeout : 0 seconds
BootOrder : 0001, 0000, 0004
Boot0001* freebsd1 HD(1,GPT,59216b88-d0c0-11e8-ba76-6805ca0f3135,0x28,0x800)/File(\efi\freebsd\boot1.efi)
                       ada1p1:/efi/freebsd/boot1.efi (null)
Boot0000  freebsd0 HD(1,GPT,590d1741-d0c0-11e8-ba76-6805ca0f3135,0x28,0x800)/File(\efi\freebsd\boot1.efi)
                       ada0p1:/efi/freebsd/boot1.efi (null)
Boot0004* UEFI: USB Flash Disk 5.00 PciRoot(0x0)/Pci(0x1a,0x0)/USB(0x1,0x0)/USB(0x2,0x0)/HD(1,MBR,0x90909090,0x1,0x640)
                                    VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6,550053004200200046006c0061007300680020004400690073006b00200035002e00300030000000)
# efibootmgr -a 0
efibootmgr:        efibootmgr [-a | -A] bootvarnum
# efibootmgr -a 0000
efibootmgr:        efibootmgr [-a | -A] bootvarnum
# efibootmgr -a 1
BootCurrent: 0004
Timeout : 0 seconds
BootOrder : 0001, 0000, 0004
Boot0001* freebsd1
Boot0000  freebsd0
Boot0004* UEFI: USB Flash Disk 5.00
# efibootmgr -a 0
efibootmgr:        efibootmgr [-a | -A] bootvarnum
# efibootmgr -c -L freebsd0 -l ada0p1:/efi/freebsd/boot1.efi
BootCurrent: 0004
Timeout : 0 seconds
BootOrder : 0002, 0001, 0000, 0004
Boot0002  freebsd0
Boot0001* freebsd1
Boot0000  freebsd0
Boot0004* UEFI: USB Flash Disk 5.00
# efibootmgr -a 2
BootCurrent: 0004
Timeout : 0 seconds
BootOrder : 0002, 0001, 0000, 0004
Boot0002* freebsd0
Boot0001* freebsd1
Boot0000  freebsd0
Boot0004* UEFI: USB Flash Disk 5.00
# efibootmgr -B 0
Removing boot variable 'Boot0000'
Removing 0x0 from BootOrder
BootCurrent: 0004
Timeout : 0 seconds
BootOrder : 0002, 0001, 0004
Boot0002* freebsd0
Boot0001* freebsd1
Boot0004* UEFI: USB Flash Disk 5.00
Comment 15 Warner Losh freebsd_committer freebsd_triage 2018-10-15 21:46:55 UTC
the latest current will activate 0. I specifically fixed that bug several weeks ago. Are you saying that has gotten broken recently?
Comment 16 Mason Loring Bliss freebsd_triage 2018-10-16 01:26:11 UTC
Ah, no, this is with the 11.2 install media.

It might be worth backporting the fix, if it hasn't been already. (If it has, I assume it'd make it into the 11.3 install media - is there a process to revise point release install media?)
Comment 17 Warner Losh freebsd_committer freebsd_triage 2021-07-31 05:14:55 UTC
I believe this is OBE since this works in 12.x and newer.