[Bug 1051006] New: BUG: efibootmgr-14 fails @ `efibootmgr: unrecognized option '--part-uuid'`
http://bugzilla.suse.com/show_bug.cgi?id=1051006 Bug ID: 1051006 Summary: BUG: efibootmgr-14 fails @ `efibootmgr: unrecognized option '--part-uuid'` Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Basesystem Assignee: rw@suse.com Reporter: pgnet.dev@gmail.com QA Contact: qa-bugs@suse.de Found By: Community User Blocker: --- I've an Opensuse Leap 42.2 server, booting to EFI sfdisk -l /dev/sde Disk /dev/sde: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 5CC3D887-CDC5-4FA2-2DDB-011FECA11D35 Device Start End Sectors Size Type /dev/sde1 2048 4095 2048 1M BIOS boot /dev/sde2 4096 618495 614400 300M EFI System /dev/sde3 618496 2715646 2097151 1024M Linux RAID /dev/sde4 2715648 1953525134 1950809487 930.2G Linux RAID after upgrade to Leap 42.3, preparing for 1st post-upgrade reboot checking as usual my EFI part findmnt --target /boot/efi --notruncate --output SOURCE --noheadings | grep "/dev/" /dev/sde2 blkid /dev/sde2 -s UUID -o value 921F-31CA blkid /dev/sde2 -s PARTUUID -o value 7124dec5-4c19-53e4-4654-1e42652c3d01 after mkinitrd -v grub2-mkconfig -o /boot/grub2/grub.cfg there's NO bootorder set, unlike previously efibootmgr BootCurrent: 0002 Timeout: 1 seconds No BootOrder is set; firmware will attempt recovery attempting to WRITE a boot order, as always, efibootmgr --create \ --gpt \ --write-signature \ --part-uuid 7124dec5-4c19-53e4-4654-1e42652c3d01 \ --loader '\EFI\opensuse\grubx64.efi' \ --label "SVR01" FAILs at efibootmgr: unrecognized option '--part-uuid' efibootmgr version 14 ... but clearly efibootmgr --help | grep part-uuid -P | --part-uuid UUID select all variables for given partition UUID currently, here rpm -q --whatprovides efibootmgr efibootmgr-14-1.3.x86_64 fyi, worked OK on leap 42.2's efibootmgr ... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1051006
pgnd _
http://bugzilla.suse.com/show_bug.cgi?id=1051006
pgnd _
http://bugzilla.suse.com/show_bug.cgi?id=1051006
http://bugzilla.suse.com/show_bug.cgi?id=1051006#c1
pgnd _
http://bugzilla.suse.com/show_bug.cgi?id=1051006
pgnd _
http://bugzilla.suse.com/show_bug.cgi?id=1051006
http://bugzilla.suse.com/show_bug.cgi?id=1051006#c2
--- Comment #2 from Raymund Will
there's NO bootorder set, unlike previously
efibootmgr BootCurrent: 0002 Timeout: 1 seconds No BootOrder is set; firmware will attempt recovery
This is *very* strange! But that's more often a firmware issue that a problem with 'efibootmgr' itself. Did you keep the log files from your upgrade?
attempting to WRITE a boot order, as always,
efibootmgr --create \ --gpt \ --write-signature \ --part-uuid 7124dec5-4c19-53e4-4654-1e42652c3d01 \ --loader '\EFI\opensuse\grubx64.efi' \ --label "SVR01"
This command is, well. quite creative -- and, AFAICT, has *never* worked! First a) no need to use '--gpt', unless your PMBR is broken. Is yours? then b) no need to use '--write-signature', as that's for pseudo-ESP on legacy/MS-DOS partition tables, where the boot sector is used to store a somewhat unique ID. *Useless* on GPT. but most importantly c) this '--part-uuid' option is only supported for '--delete' (ATM). You'll have to use '--disk' with '--part', as always.
FAILs at
efibootmgr: unrecognized option '--part-uuid'
Granted, this error message could use a "for --create" appendix. [...]
efibootmgr --help | grep part-uuid
Well, efibootmgr -h | grep -i UUID --delete delete entry by bootnum (-b), by UUID (-P) -P | --part-uuid UUID select all variables for given partition UUID will provide (a little) more context. (Especially that "select all variables" sub-phrase!) [...]
fyi, worked OK on leap 42.2's efibootmgr ...
No -- definitely not! Not your command -- that's IMHO impossible. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1051006
http://bugzilla.suse.com/show_bug.cgi?id=1051006#c3
Raymund Will
(In reply to pgnd _ from comment #0) [...]
fyi, worked OK on leap 42.2's efibootmgr ...
No -- definitely not! Not your command -- that's IMHO impossible.
Actually it *may* produce the expected result with efibootmgr-0.6.0, but only out of sheer *luck*! That "luck" is caused by a) no "parameter error" reported for misuse of '--part-uuid' -- it's simply ignored! b) your boot partition residing on '/dev/sda' with number '1', which matches the compiled-in default of 'efibootmgr'. The only issue worth tracking is the lost 'BootOrder', but that may well be a firmware issue. Or would it be possible, that you deleted the last boot entry on your system? Where are all these FW-provided ones? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1051006
http://bugzilla.suse.com/show_bug.cgi?id=1051006#c4
pgnd _
[Note to self: verify all parts of your claim *before* posting!]
snark is helpful how?
No -- definitely not! Not your command -- that's IMHO impossible.
It's worked for well over a year. That it's, in your terminology, 'luck' doesn't change that fact. And doesn't excuse the lack of either error or documentation.
a) no "parameter error" reported for misuse of '--part-uuid' -- it's simply ignored!
there's no indication in "--help" that it's not valid. efibootmgr --help ... -c | --create create new variable bootnum and add to bootorder ... -P | --part-uuid UUID select all variables for given partition UUID ... certainly reads as 'create for/using the selected variables' as viable, or at the very least NOT proscribed. an error message, then, would be nice. as would a manpage rpm -qa | grep -i efibootmgr efibootmgr-14-1.3.x86_64 rpm -ql efibootmgr /usr/sbin/efibootdump /usr/sbin/efibootmgr /usr/share/doc/packages/efibootmgr /usr/share/doc/packages/efibootmgr/COPYING /usr/share/doc/packages/efibootmgr/README /usr/share/man/man8/efibootdump.8.gz /usr/share/man/man8/efibootmgr.8.gz man efibootmgr No manual entry for efibootmgr ls -al /usr/share/man/man8/efiboot* ls: cannot access '/usr/share/man/man8/efiboot*': No such file or directory ls /usr/local/efibootmgr/share/man/man8/efiboot* /usr/local/efibootmgr/share/man/man8/efibootdump.8 /usr/local/efibootmgr/share/man/man8/efibootmgr.8
b) your boot partition residing on '/dev/sda' with number '1', which matches the compiled-in default of 'efibootmgr'.
no. "/boot" resides on RAID /dev/md0, on part 3 mount | grep "/boot " /dev/md0 on /boot type ext4 (rw,noatime,journal_checksum,data=ordered) cat /proc/mdstat | grep md0 md0 : active raid1 sde3[0] sdf3[1]
The only issue worth tracking is the lost 'BootOrder', but that may well be a firmware issue. Or would it be possible, that you deleted the last boot entry on your system? Where are all these FW-provided ones?
Unclear. I used to clear the boot order ages ago, as grub2/Xen/UEFI/efibootmgr on Opensuse had been creating a downright mess. That's since cleaned up, and I simply write, not clear. With kernel 4.[11-12], appeared as usual. Atm, with 4.13x, not. That's being invesitgated separately. In any case, the primary point is the writing of the BootOrder with my intent, rather than a depending on FW (most FWs are robust; some are clearly horked) "--disk ... --part ..." works fine. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1051006
http://bugzilla.suse.com/show_bug.cgi?id=1051006#c5
--- Comment #5 from Raymund Will
[Note to self: verify all parts of your claim *before* posting!]
Which "self" do you think this remark referred to? (IMHO) Obviously to me, as I wrongly claimed that impossibility.
snark is helpful how?
Well, if you want to misunderstand me, you definitely will (anyhow, I'm no native speaker and do make mistakes (see above)).
No -- definitely not! Not your command -- that's IMHO impossible.
It's worked for well over a year.
No, it did not! You could have used efibootmgr -c without any argument to achieve a comparable result. You specifically have *never* selected an EFI System Partition (ESP) with '--part-uuid'.
That it's, in your terminology, 'luck' doesn't change that fact.
Really? Try placing an ESP on 'sdb', rearrange disks or add another host controller, which happens to shuffle "drive letters"...
And doesn't excuse the lack of either error or documentation.
Hmm, that 0.6.0 didn't error out is indisputably unfortunate, but not retroactively fixable.
a) no "parameter error" reported for misuse of '--part-uuid' -- it's simply ignored!
there's no indication in "--help" that it's not valid.
You could take the solitary reference in '--delete' as a hint! [...]
certainly reads as 'create for/using the selected variables' as viable, or at the very least NOT proscribed.
Well, that's your opinion. As I never use '-b' to select the number for a boot entry to create, I wrongly assumed, that everybody only ever would want to "select" an entry for deletion.
an error message, then, would be nice.
Granted, but the error message in 14 is apparently also "not good enough".
as would a manpage
Sorry, but again "no". The command you're looking for is rpm -V efibootmgr which would show, that the manpages have been removed/omitted from your installation. Does it? [...]
man efibootmgr No manual entry for efibootmgr
Not here on my system, but it wouldn't have helped either, as that SUSE-specific extension hasn't been documented in the manpage (yet). It was simply *not* intended for public consumption (but for installer use, namely to avoid stale boot entries). [...]
b) your boot partition residing on '/dev/sda' with number '1', which matches the compiled-in default of 'efibootmgr'.
no. "/boot" resides on RAID /dev/md0, on part 3
Aargh -- sorry -- I meant to refer to "ESP". 'efibootmgr' is never concerned with a '/boot'-partition. Unly the partition hosting '/boot/efi' is relevant to that program (specified with '-d -p'). [...]
Unclear.
I used to clear the boot order ages ago, as grub2/Xen/UEFI/efibootmgr on Opensuse had been creating a downright mess. That's since cleaned up, and I simply write, not clear.
Unclear as well -- I simply do not understand this and the next statement.
With kernel 4.[11-12], appeared as usual. Atm, with 4.13x, not. That's being invesitgated separately.
In any case, the primary point is the writing of the BootOrder with my intent, rather than a depending on FW (most FWs are robust; some are clearly horked)
Every time you successfully create a boot entry with 'efibootmgr -c', it should recreate 'BootOrder', with that new entry being the first. If it can't there should be an error message. If you intentionally remove 'BootOrder' (with 'efibootmgr -O'), it would (IMHO) be useful to edit out the error message regarding that variable from a submission (to avoid unnecessary diversions).
"--disk ... --part ..." works fine.
Good. And this is the only way forward. But I'll take your challenges into account, while upstreaming this '--delete' extension (together with a proper manpage-part), which is work-in-progress. BTW, it would be helpful, if you could close that issue #75, as upstream can not (yet) be of any assistance in this topic. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1051006
http://bugzilla.suse.com/show_bug.cgi?id=1051006#c6
Raymund Will
participants (1)
-
bugzilla_noreply＠novell.com