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.
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
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.
CC imp@
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.
functionality not missing. Just say -l ada0s1:/path/to/loader
(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.
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.
s/decide/device/ pre-coffee spelling
(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..
https://en.wikipedia.org/wiki/Principle_of_least_astonishment
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) #
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) #
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.
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
the latest current will activate 0. I specifically fixed that bug several weeks ago. Are you saying that has gotten broken recently?
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?)
I believe this is OBE since this works in 12.x and newer.