Comment # 5 on bug 1051006 from Raymund Will

(In reply to pgnd _ from comment #4)
> > [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.