Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: boot.cfg dev command not working



    Date:        Sun, 23 Mar 2025 06:12:53 +0100
    From:        Michael van Elst <mlelstv%serpens.de@localhost>
    Message-ID:  <Z9-YVRjX6g8pB_t5%serpens.de@localhost>

  | UEFI doesn't even know the "bootme" attribue, so that must be something
  | else.

It is even worse than that, despite what our gpt(8) might allow one to
believe, it is impossible to set "bootme" on an ESP.   "bootme" is one
of the flag bits in the upper 16 bits of the GPT partition flags word,
and those have a meaning defined by the partition type, they're not global.

As far as I have been able to determine, ESP partitions have no defined bits
in that range (that partition type is defined in the UEFI standard, and it
doesn't define any upper bit meanings, for any partition types).

So while bit 1<<59 might be set there, it isn't "bootme" (despite what
gpt(8) pretends).

That said, I have always had the impression that my system's firmware doesn't
treat an ESP partition as bootable unless it has bit 63 set -- that's one
which has a defined meaning for Windows partition types I think - and as ESP's
are (a kind of) FAT (not technically, as microsoft can alter the definition of
FAT partitions, though they're unlikely to, but not of an ESP, which has a
fixed format) it is kind of understandable that firmware manufacturers might
assume it applies, or at least can be interpreted as if it does.

It is perhaps the case that Paul's firmware is similar, or perhaps it simply
insists that something be set in the upper 16 bits for it to treat an ESP as
bootable.

But it certainly cannot be BOOTME as such, as that only exists (or should only
exist) for {Free,Net}BSD partition types (and perhaps even there, not all of
them, it is hard to imagine a meaning for BOOTME on a swap or cgd partition).

  | N.B. it might know the "biosboot" attribute.

It might, that is a globally defined bit (though why it exists that way
perplexes me) - it applies to all partition types.   What firmware might do
with it if set on an ESP is anyone's guess I think.

kre

ps: we really should work out a way in gpt(8) to allow the upper 16
flags/attribute bits to be set and reset in a way that uses the partition
type to associate names with the available bits.   The current situation
where those bits have kind of de-facto been split into a number of groups
(microsoft/linux/solaris/bsd) is untenable, there aren't enough of them.


Home | Main Index | Thread Index | Old Index