This shouldn't change control flow, with one exception: we won't send
notifications for boot progress to plymouth anymore during reload, which
is something we really shouldn't.
Let's make sure the integers we parse out are not larger than USHRT_MAX.
This is a good idea as the kernel's TIOCSWINSZ ioctl for sizing
terminals can't take larger values, and we shouldn't risk an overflow.
On EFI variables that aren't whitelisted in the kernel the
FS_IMMUTABLE_FL is set, as protection against accidental
removal/modification. Since our own variables do not appear in those
whielists, and we are not changing these variables, let's unset the flag
temporarily when needed. We restore the flag after all writes, just in
case.
let's add an env var for this, as this really shouldn't be a top-level
feature, as it turning off the validity checks certainly isn't
advisable.
Fixes: #4925
This is really confusing, let's try to clean this up a bit, in
particular as there are two very similar concepts:
1. The boot loaders, i.e. the category you find systemd-boot, the
Windows and Apple boot loaders in. These may typically be listed in the
firmware's EFI variables.
2. The boot loader entries, as defined by the Boot Loader Spec. In this
category you find the various Linux kernels that are installed, i.e.
the stuff systemd-boot shows on screen. To make things confusing, the
Windows and Apple boot loaders can appear both as boot loaders and as
boot loader entries.
This tries to establish the following nomenclature: "boot loaders" and
"boot loader entries" for these two concepts.
boot_loader_read_conf(), boot_entries_find(), boot_entries_load_config()
all log their errors internally, hence no need to log a second or third
time about the same error when they return.
We do these checks only for the high-level calls as for the low-level
ones it might make sense in some exotic uses to read the host EFI data
from a container or so.
We already synchronize all files we write individually, as well as the
directories they are stored in. Let's also synchronize the ESP as a
whole after our work, just in case.
Note that this breaks compatibility with older versions, as the detach
code won't find unit files attached with older releases anymore. But
given that the portable service logic was not deemed stable so far, and
this was explicitly documented and enforced through portablectl's
installation to /usr/lib/systemd/ such a compat breakage should be fine.
Let's separate out the unit files copied from attached portable service
image files from the admin's own files. Let's introduce
/etc/systemd/system.attached/ + /run/systemd/system.attached/ for the
files of portable services, and leave /etc/systemd/system/ and
/run/systemd/system/ for the admin.