We currently have code to read and write files containing UUIDs at various
places. Unify this in id128-util.[ch], and move some other stuff there too.
The new files are located in src/libsystemd/sd-id128/ (instead of src/shared/),
because they are actually the backend of sd_id128_get_machine() and
sd_id128_get_boot().
In follow-up patches we can use this reduce the code in nspawn and
machine-id-setup by adopted the common implementation.
https://github.com/systemd/systemd/pull/3685 introduced
/run/systemd/inaccessible/{chr,blk} to map inacessible devices,
this patch allows systemd running inside a nspawn container to create
/run/systemd/inaccessible/{chr,blk}.
Previously, we'd not mount the ESP except on EFI boots, and only when the ESP
used for booting matches the ESP we found.
With this change on non-EFI boots we'll mount a discovered ESP anyway, and on
EFI boots we'll only mount it if it matches the ESP we booted from.
With this change kernel-install will now first look for an existing kernel
installation in /efi, /boot and /boot/efi. If none is found, /efi is used if it
is a mount point, otherwise /boot/efi if it is one. If nothing of that worked
/boot is used without further checking.
This means /boot should be the default unless something was installed before or
something else was explicitly mounted.
We already have tolower() calls there, hence let's unify this at one place.
Also, update the code to only use ASCII operations, so that we don't end up
being locale dependant.
This rearranges bootctl a bit, so that it uses the usual verbs parsing
routines, and automatically searches the ESP in /boot, /efi or /boot/efi, thus
increasing compatibility with mainstream distros that insist on /boot/efi.
This also adds minimal support for running bootctl in a container environment:
when run inside a container verification of the ESP via raw block device
access, trusting the container manager to mount the ESP correctly. Moreover,
EFI variables are not accessed when running in the container.
Matching the behaviour of gpt-auto-generator, if we find an ESP while
dissecting a container image, mount it to /efi or /boot if those dirs exist and
are empty.
This should enable us to run "bootctl" inside a container and do the right
thing.
Let's make the EFI generator a bit smarter: if /efi exists it is used as mount
point for the ESP, otherwise /boot is used. This should increase compatibility
with distros which use legacy boot loaders that insist on having /boot as
something that isn't the ESP.
If the ESP is not mounted with "iocharset=ascii", but with "iocharset=utf8"
(which is for example the default in Debian), the file system becomes case
sensitive. This means that a file created as "FooBarBaz" cannot be accessed as
"foobarbaz" since those are then considered different files.
Moreover, a file created as "FooBar" can then also not be accessed as "foobar",
and it also prevents such a file from being created, as both would use the same
8.3 short name "FOOBAR".
Even though the UEFI specification [0] does give the canonical spelling for
the files mentioned above, not all implementations completely conform to that,
so it's possible that those files would already exist, but with a different
spelling, causing subtle bugs when scanning or modifying the ESP.
While the proper fix would of course be that everybody conformed to the
standard, we can work around this problem by just referencing the files by
their 8.3 short names, i.e. using upper case.
Fixes: #3740
[0] <http://www.uefi.org/specifications>, version 2.6, section 3.5.1.1
Normally we make all of /proc/sys read-only in a container, but if we do have
netns enabled we can make /proc/sys/net writable, as things are virtualized
then.
When a container scope is allocated via machined it gets 16K set already since
cf7d1a30e4. Make sure when a container is run as
system service it gets the same values.
We don't actually need any functionality from cgroup.h in execute.h, hence
don't include that. However, we do need the Unit structure from unit.h, hence
include that, and move it as late as possible, since it needs the definitions
from execute.h.
All other functions in execute.c that need the unit id take a Unit* parameter
as first argument. Let's change connect_logger_as() to follow a similar logic.
This way systemd is informed that we consider everything inside the scope as
"left-over", and systemd can log about killing it.
With this change systemd will log about all processes killed due to the session
clean-up on KillUserProcesses=yes.
Let's lot at LOG_NOTICE about any processes that we are going to
SIGKILL/SIGABRT because clean termination of them didn't work.
This turns the various boolean flag parameters to cg_kill(), cg_migrate() and
related calls into a single binary flags parameter, simply because the function
now gained even more parameters and the parameter listed shouldn't get too
long.
Logging for killing processes is done either when the kill signal is SIGABRT or
SIGKILL, or on explicit request if KILL_TERMINATE_AND_LOG instead of LOG_TERMINATE
is passed. This isn't used yet in this patch, but is made use of in a later
patch.
The rfkill service waits for rfkill device initialization as reported by
udev_device_is_initialized(), and if that is never reported it might dead-lock.
However, udev never reports completed initialization for devices that have no
properties or tags set. For some rfkill devices this might be the case, in
particular those which are connected to exotic busses, where path_id returns
nothing.
This patch simply sets the SYSTEM_RFKILL property on all rfkill devices, to
ensure that udev_device_is_initialized() always reports something useful and we
don't dead-lock.
Fixes: #2745
Lennart Poettering
Martin Pitt
Alessandro Puccetti
Alessio Igor Bogani
Peter Hutterer
Thomas H. P. Andersen
Zbigniew Jędrzejewski-Szmek
Alexander Kurtz
Topi Miettinen
Daniele Medri