This also drop the support of /run/systemd/netif/persistent-storage-ready,
as the file is anyway removed when networkd is stopped.
Let's use $SYSTEMD_NETWORK_PERSISTENT_STORAGE_READY=1 instead on testing.
Useful information to have in the logs.
Mar 14 16:45:27 H systemd-portabled[510]: Successfully attached ephemeral '/usr/share/minimal_0.raw' and its extension(s) '/usr/share/app0.raw' using profile 'default'
Previously, if an [Address] section is configured with a null address,
e.g. Address=0.0.0.0/24, then we acquired a free address in
link_request_address().
With this commit, we queue a request with the null address as is, and
acquire a free address later in address_process_request(). Similary,
now IPv4ACD daemon is configured in address_process_request().
With this change, we can make the address acquisition depend on other
conditions, e.g. if the persistent storage is ready or not.
This introduces $SYSTEMD_KEYMAP_DIRECTORIES environment variable to
override the hardcoded keymap directories.
I think it is not necessary to provide the first class configuration
option for controlling the keymap directories, but it is not good to
hardcode the paths. So, let's introduce an environment variable to
override that.
Prompted by #31759.
Closes#31759.
Previously, it is assumed that the paths in KBD_KEYMAP_DIRS are ended
with a slash. But, in the next commit, paths will become controllable by
users, and each path may not be ended with a slash.
This should not change any effective behaviors.
Just refactoring and preparation.
Otherwise, even if the persistent storage is not ready, the DHCP server
may be started e.g. by unplugging and plugging cable.
Follow-up for 5582b36c38.
The specified vendor UUID is not actually a UUID. This changes it to an actual UUID.
The new value matches the ones from the systemd-boot man page and [The Boot Loader Interface](https://systemd.io/BOOT_LOADER_INTERFACE/).
This mirrors the existing CONTAINER_INTERFACE.md document, but describes
extension points of systemd running in a VM with a machine manager
supervising it.
From the outside it's difficult to determine whether (and when) the PID1
inside a container supports systemd's more complete set of UNIX process
signals or not. Let's make this easier, and simply send a notification
message when we are ready.
This new passive target is supposed to be pulled in by SSH
implementations and should be reached when remote SSH access is
possible. The idea is that this target can be used as indicator for
other components to determine if and when SSH access is possible.
One specific usecase for this is the new sd_notify() logic in PID 1 that
sends its own supervisor notifications whenever target units are
reached. This can be used to precisely schedule SSH connections from
host to VM/container, or just to identify systems where SSH is even
available.
Let's inform the the supervisor about various happenings of our service
manager, specifically the boot milestones we reach.
We so far have only a singular READY=1 message, to inform about bootup
completion. But sometimes it is interesting to have something for
finegrained, in particular something that indicates optional components
that have been activated.
Usecase for this: in a later PR I intend to introduce a generic
"ssh.target" that is supposed to be activated when SSH becomes available
on a host. A supervisor (i.e. a VMM/hypervisor/container mgr/…) can
watch for that, and know two things:
1. that SSH is generally available in the system
2. when it is available
In order to not flood the supervisor with events I only send these out
for target units. We could open this up later, in theory, but I think it
makes sense to tell people instead to define clear milestone target
units if they want a supervisor to be able to track system state.
