Re: GPT attributes in dkwedge [PATCH]

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 24 Sep 2023 17:41:30 +0000
    From:        Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>
    Message-ID:  <20230924174130.481DD608D3%jupiter.mumble.net@localhost>


  | Why would bootme be usually set on the EFI system partition?
  |
  | The documentation in gpt(8) needs to be clarified -- and I'm not sure
  | there's any other canonical reference about it in any of our
  | documentation -- but it sounds to me like it is supposed to be:
  |
  | (a) where NetBSD's efiboot finds the kernel, and/or
  | (b) what root partition the kernel will use.
  |
  | It's not clear what else the bootme flag would be for,

I'd always assumed it to be where efiboot should locate boot.cfg.
Where the kernel and root filesystems are located are in boot.cfg.

Note there isn't necessarily a "the" EFI system partition, there may
be more than one of them on the same drive, and I am by no means convinced
that our current efiboot (at least) is able to parse the variables
available to that tell it exactly where it was loaded from.

  | and it seems
  | that unless boot.cfg instructs the bootloader to pass a different root
  | device to the kernel with the `root' command, the same partition that
  | was used to find the kernel is a reasonable default choice of root
  | device.

Yes, but to me at least, that's way beyond anything bootme might be
used for.

  | The bootme flag certainly not used to tell the machine firmware where
  | to find efiboot -- it's is vendor-specific, a BSDism.

bootme is from FreeBSD orig I believe, yes, but from where the firmware
finds efiboot shouldn't be vendor specific, it should be fully specified
by EFI variables - we just don't bother to do that yet, and fall back on
the vendor code magically locating our efiboot code (which is why we're
forced to call it by that magic blessed name.)

  | It's not obviously where efiboot finds boot.cfg, since that's in
  | esp:/EFI/NetBSD/boot.cfg or,

And we correctly interpret that, always?   For me at least, nowhere I
put boot.cfg seems to work, all I ever get is the efiboot compiled in
default (the one that has the ascii-art flag, which your typical boot.cfg
file doesn't have - certainly none of mine do, and I have boot.cfg files
sprinkled all over the filesystem, each with its own unique banner, so if
one if ever used, I'll know which).

  | if not there, whatever parsebootconf
  | resolves unqualified `boot.cfg' into -- which may be the
  | bootme-flagged partition but it's not clear to me in a cursory search
  | that it has even looked for a bootme-flagged partition at the point it
  | needs to resolve boot.cfg.

That's entirely possible - in which case it probably needs to be fixed.

  | Whatever the purpose is, we need to have it documented clearly;

Agreed.

  | right now I can't share kre's certainty about what it is _not_ to be used
  | for.

That comes from there being other mechanisms to specify where root is,
and where the kernel is to come from - we don't need alternate far less
powerful mechanisms for that, which would only serve to confuse things.
Even if there's no boot.cfg file, efiboot has its built in defaults, which
are more useful than a single bit somewhere.

Then there's also the question of non EFI boots of a GPT partitioned drive.

kre