It's not well-formed to begin with. And util-linux's mount(8)
is pretty much ubiquitously employed, hence it will be rejected
elsewhere too. Just stop pretending it is valid just because
glibc parser is sloppy.
Major distributions already have libfido2 >= 1.12.0. Let's bump the
required minimum version to 1.5.0, which provides FIDO_ERR_UV_BLOCKED.
Note, libfido2 1.5.0 was released on 2020-09-01.
See also #38608.
This is what the symlinkat.2 man page uses.
The old naming with 'to' and 'from', where 'to' is the symlink name
and 'from' is the symlink target is very confusing.
Follow-up for 892838911b.
This changes the instances of lexical to lexicographic, thus making it easier
to grep for instances of lexicographic order, since there's only one variant of
the word to consider.
Lexicographic is chosen since there are slightly fewer instances of lexical and
lexicographic seems a better fit than lexical after checking a few
dictionaries.
The words lexical, lexicographic, and lexicographical are synonyms in
computing, meaning an alphabetical order. Both the Oxford dictionary and
Merriam-Webster make no distinction between lexicographic and lexicographical,
with only Wiktionary adding a more precise meaning of
Meeting lexicographical standards or requirements; worthy of being included
in a dictionary. [1]
Since, outside of computing, lexicographic(al) has the more specific meaning
pertaining to lexicography, i.e. the editing or making of dictionaries [2], and
lexical only has this as a secondary meaning after its linguistic meaning [3],
lexicographic fits the meaning of including and ordering entries better.
[1] https://en.wiktionary.org/wiki/lexicographical#English
[2] https://www.merriam-webster.com/dictionary/lexicographic
[3] https://www.oed.com/dictionary/lexical_adj
This is ultimately preparation for making systemd-creds's --with-key=
switch also accessible via Varlink, because it uses "+" inside an the
enum name. It makes sense to to allow this generally however.
This allows for more liberal usage of logging functionality as messages
will no longer always show up on screen, regardless of urgency. The log
level to use can be configured through an SMBIOS type 11 string
(`io.systemd.boot.loglevel=`) or by using the `log-level` option in
loader.conf. Valid values are debug, info, notice, warning, err, crit,
alert, and emerg. By default, info will be used.
In https://github.com/systemd/systemd/issues/38842 it is reported that
we're again having trouble accessing EFI variables:
```
[ 292.212415] H (udev-worker)[253]: Reading EFI variable /sys/firmware/efi/efivars/LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f.
...
[ 344.397961] H (udev-worker)[253]: Detected slow EFI variable read access on LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f: 52.185510s
```
We don't know what causes the slowdown, but it seems reasonable to avoid
unnecessary read() calls. We would read the 4-byte attr first, and then
the actual value later. But our code always reads the value (and
discards the attr in all cases except one, when _writing_ the variable),
so let's optimize for the case where we read the value and read the
whole contents in one read().
- Actually pass the new memory file path to parent_loaded_image->FilePath
- Restore old parent_loaded_image if Linux returns
- Pass the same kernel_file_path in load_via_boot_services path
- s/Re-use/Patch in comment explaining what we are doing
Fixes#38566
As explained in https://github.com/systemd/systemd/issues/37892, it
would be nice to define per-partition PCRs/key file to use.
The global default config will be still defined as cmdline options, and
`TPM2PCRs=` and `KeyFile=` will be overriden by them.
Major distributions already have libfido2 >= 1.12.0.
Let's bump the required minimum version to 1.5.0, which provides
FIDO_ERR_UV_BLOCKED.
Note, libfido2 1.5.0 was released on 2020-09-01.
See also #38608.
Change log_internal() to receive a log level from which a text color is
derived, rather than the text color directly, and adjust various log_*
macros to use them internally.
Implements the ability to add recovery keys to existing user accounts
via homectl update --recovery-key=yes. Previously, recovery keys could
only be configured during initial user creation, requiring users to
recreate their entire home directory to add recovery keys later.
Fixes: #23602
