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.