The test for the variable is added in test-systemctl-enable because there we
can do it almost for free, and the variable is most likely to be used with
'systemctl enable --root' anyway.
This new file is supposed to address conflicts with Fedora/Grub's
frankenbootloaderspec implementation, that squatted the /loader/entries/
dir, but place incompatible files in them (that do variable expansion?).
A simple text file /loader/entries.srel shall indicate which spec is
implemented. If it contains the string "type1\n" then the
/loader/entries/ directory implements our standard spec, otherwise
something else.
This allows snippet generators to explicitly order entries: any string
can be set as an entry's "sort key". If set, sd-boot will use it to sort
entries on display.
New logic is hence (ignore the boot counting logic)
sort-key is set → primary sort key: sort-key (lexicographically increasing order)
→ secondary sort key: machine-id (also increasing order)
→ tertiary sort key: version (lexicographically decreasing order!)
sort-key is not set → primary sort key: entry filename (aka id), lexicographically increasing order)
With this scheme we can order OSes by their names from A-Z but then put
within the same OS still the newest version first. This should clean up
the order to match expectations more.
Based on discussions here:
https://github.com/systemd/systemd/pull/22391#issuecomment-1040092633
/dev/urandom is seeded with RDRAND. Calling genuine_random_bytes(...,
..., 0) will use /dev/urandom as a last resort. Hence, we gain nothing
here by having our own RDRAND wrapper, because /dev/urandom already is
based on RDRAND output, even before /dev/urandom has fully initialized.
Furthermore, RDRAND is not actually fast! And on each successive
generation of new x86 CPUs, from both AMD and Intel, it just gets
slower.
This commit simplifies things by just using /dev/urandom in cases where
we before might use RDRAND, since /dev/urandom will always have RDRAND
mixed in as part of it.
And above where I say "/dev/urandom", what I actually mean is
GRND_INSECURE, which is the same thing but won't generate warnings in
dmesg.
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.
