bootspec.c, which is used by bootctl and systemctl, computes bootloaders
entry IDs independently from systemd-boot. This commit updates
the ID computation in bootspec.c to be in line with the previous few
commits altering boot.c.
Make two minor cosmetic changes to how config_entry_add_linux() extracts
OS information from the embedded /etc/os-release in EFISTUB binaries.
This increases the detail of information available to the user for
EFISTUB entries.
* entry->version, which was previously always null, is now set to the
value of VERSION, or VERSION_ID, or BUILD_ID (preferred in that order).
* entry->title, which was previously set to the value of PRETTY_NAME, can
now fall back to NAME or ID if PRETTY_NAME is not present. In that case,
NAME is preferred over ID.
Change config_entry_add_from_file() so that it does not remove the
`.conf` ending from the filename that it uses for entry->id. This is
necessary because otherwise an EFISTUB binary and a loader config entry
might end up with the same ID, as the loader config IDs previously
didn't include the config filename's .conf extension (see boot.c:1435).
Consider, for instance, an EFISTUB /EFI/Linux/linux.efi and a loader
config /loader/entries/linux.efi.conf; both would have the ID linux.efi.
In addition, update a comment that previously stated that IDs are
non-unique (which is no longer the case, as of this commit).
Change config_entry_add_linux() so that Linux EFISTUB entries' ids are
simply the binaries' filenames, as is already the case with loader
configs. This guarantees that EFISTUB binaries' IDs are mutually unique.
This makes the naming more consistent: we now have
bootctl systemd-efi-options,
$SYSTEMD_EFI_OPTIONS
and the SystemdOptions EFI variable.
(SystemdEFIOptions would be redundant, because it is only used in the context
of efivars, and users don't interact with that name directly.)
bootctl is adjusted to use 2sp indentation, similarly to systemctl and other
programs.
Remove the prefix with the old name from 'bootctl systemd-efi-options' output,
since it's redundant and we don't want the old name anyway.
Move the explanation of options three columns to the right: then almost
all options fit and we do not need to break lines so often.
When a multi-line explanation precedes a section break, i.e. there is a
half-line on the right side, do not use an empty space. This saves a line,
and actually looks visually better because the text is still clearly
separated, but we don't get the big vertical white space.
This copies the commands log-level and log-target (to query and set the current
settings) from systemd-analyze to systemctl, essentially reverting
a65615ca5d. Controllling the log level settings
of the manager is basic functionality, that should be available even if
systemd-analyze (which is more of an analysis tool) is not installed. This is
like dmesg and journalctl, which should be available even if a debugger and
more advanced tools to analyze the kernel are not available. (Note that dmesg
is used to control the log level too, not just to browse the kernel logs.)
I chose to copy&paste the methods from analyze.c to the new location. There
isn't enough code to share, because acquire_bus() in both places has a
different signature despite the same name, so the only part that is common
is the invocation of sd_bus_set_property().
This cleans up and unifies the outut of --help texts a bit:
1. Highlight the human friendly description string, not the command
line via ANSI sequences. Previously both this description string and
the brief command line summary was marked with the same ANSI
highlight sequence, but given we auto-page to less and less does not
honour multi-line highlights only the command line summary was
affectively highlighted. Rationale: for highlighting the description
instead of the command line: the command line summary is relatively
boring, and mostly the same for out tools, the description on the
other hand is pregnant, important and captions the whole thing and
hence deserves highlighting.
2. Always suffix "Options" with ":" in the help text
3. Rename "Flags" → "Options" in one case
4. Move commands to the top in a few cases
5. add coloring to many more help pages
6. Unify on COMMAND instead of {COMMAND} in the command line summary.
Some tools did it one way, others the other way. I am not sure what
precisely {} is supposed to mean, that uppercasing doesn't, hence
let's simplify and stick to the {}-less syntax
And minor other tweaks.
Our handling of the condition was inconsistent. Normally, we'd only fire when
the file was created (or removed and subsequently created again). But on restarts,
we'd do a "recheck" from path_coldplug(), and if the file existed, we'd
always trigger. Daemon restarts and reloads should not be observeable, in
the sense that they should not trigger units which were already triggered and
would not be started again under normal circumstances.
Note that the mechanism for checks is racy: we get a notification from inotify,
and by the time we check, the file could have been created and removed again,
or removed and created again. It would be better if we inotify would give as
an unambiguous signal that the file was created, but it doesn't: IN_DELETE_SELF
triggers on inode removal, not directory entry, so we need to include IN_ATTRIB,
which obviously triggers on other conditions.
Fixes#12801.
Using these IDs for message identication is one use case, but there are
others, hence let's drop the prefix, it only made sense to have while
the tool was part of journalctl.
Spencer Michaels
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Lennart Poettering
Serge
Tom Fitzhenry
Cyprien Laplace