In all other cases we have the older variant before the newer. And since we
generate some documentation tables from the header, this order is also visible
for users. Let's restore the order. This commit does
4565246911 in a slightly different fashion.
00db9a114e ("docs: generate table from header using a script") got the
descriptions for the partition types mixed up. After that change, the
spec claimed, for example, that the /usr partition should contain
"dm-verity integrity hash data for the matching root partition", and
that the /usr verity partition should be of type "Any native, optionally
in LUKS". This made the spec an extremely confusing read before I
figured out what must have happened!
I've gone through the table as it existed prior to 00db9a114e, and moved
the descriptions around in the script that generates the table until
they matched up with what they used to be. Then I regenerated the
table from the fixed script.
This adds a helper script:
$ python3 tools/list-discoverable-partitions.py <src/shared/gpt.h
<!-- generated with tools/list-discoverable-partitions.py -->
| Partition Type UUID | Name | Allowed File Systems | Explanation |
|---------------------|------|----------------------|-------------|
| _Root Partition (Alpha)_ | `6523f8ae-3eb1-4e2a-a05a-18b695ae656f` | [Root Partition] | [Root Partition more] |
| _Root Partition (ARC)_ | `d27f46ed-2919-4cb8-bd25-9531f3c16534` | ditto | ditto |
...
The output can be pasted into the markdown file. I think this works better than
trying to match the two lists by hand.
The discovery partitions spec so far suggested we should define
arch-specific partition type uuids only for archs that have EFI. Let's
change that and invite people to define them for any arch. Why? Even if
GPT is defined as part of the UEFI spec it's quite useful independently
of it, too. Specifically, our image dissection logic makes use of it,
i.e. systemd-nspawn, systemd-gpt-auto-generator, systemd-repart,
RootImage=, portable services, and so on. None of these tools are
related to UEFI in any way.
Hence, let's open this up.
I have no idea if this is going to cause rendering problems, and it is fairly
hard to check. So let's just merge this, and if it github markdown processor
doesn't like it, revert.
The verity partition types are per-architecture already, and they contain the
hash data independently of whether we are on a given architecture. (Or in other
words, we would make *use* this partition on some architecture, but the
contents always *exists*.)
If the auto-discovered swap partition is LUKS encrypted, decrypt it
automatically.
This aligns with the Discoverable Partitions Specification, though I've
also updated it to explicitly mention that LUKS is now supported here.
Since systemd retries any key already in the kernel keyring, if the swap
partition has the same passphrase as the root partition, the user won't
be prompted a second time for a second passphrase.
See https://github.com/systemd/systemd/issues/20019
This updates the docs about using fdisk/gdisk to make partitions with the right
partition type UUID as defined in the discoverable partitions spec.
Improve wording/grammar/formatting, and reflect that gdisk supports this as
well nowadays; see https://www.rodsbooks.com/gdisk/revisions.html
This specification is useful independently of UEFI, so avoid making assertions
about UEFI. Also reword the intro to say what this is about in the very first
sentence. Closes#16570.
