If for any reason something goes wrong during the boot process (most likely due
to a network issue), system admins should be allowed to log in to the system to
debug the problem. However due to the login session barrier enforced by
systemd-user-sessions.service for all users, logins for root will be delayed
until a (dbus) timeout expires. Beside being confusing, it's not a nice user
experience to wait for an indefinite period of time (no message is shown) this
and also suggests that something went wrong in the background.
The reason of this delay is due to the fact that all units involved in the
creation of a user session are ordered after systemd-user-sessions.service,
which is subject to network issues. If root needs to log in at that time,
logind is requested to create a new session (via pam_systemd), which ultimately
ends up waiting for systemd-user-session.service to be activated. This has the
bad side effect to block login for root until the dbus call done by pam_systemd
times out and the PAM stack proceeds anyways.
To solve this problem, this patch orders the session scope units and the user
instances only after systemd-user-sessions.service for unprivileged users only.
DefaultSmackProcessLabel tells systemd what label to assign to its child
process in case SmackProcessLabel is not set in the service file. By
default, when DefaultSmackProcessLabel is not set child processes inherit
label from systemd.
If DefaultSmackProcessLabel is set to "/" (which is an invalid character
for a SMACK label) the DEFAULT_SMACK_PROCESS_LABEL set during compilation
is ignored and systemd act as if the option was unset.
I don't quite understand this, but '{ ! true; }' is not the same as '( ! true )'.
In interactive mode, it seems to work as expected. But in a script, it doesn't.
This means that we'll fail hard if something goes wrong, e.g. reading
of a config file. I think this is appropriate. If errors should be ignored,
the caller should do that on their end.
In practice this makes little difference, because kernel-install will
only call the plugins for 'add' or 'remove', and if we were to add a
new verb to kernel-install, we'd just change the plugins at the same
time. But our plugins serve as documentation for external plugins too,
and there it's better to silently ignore unknown verbs so that we can
add new verbs in the future.
(50-depomod.install was already like that.)
I opted to tweaking kernel-install to allow overriding config
(with $KERNEL_INSTALL_CONF_ROOT, $KERNEL_INSTALL_PLUGINS). An alternative
would be to build a test environment in test/. We can still do that,
but I think it's nice to have a simple test that is very quick and easy
to debug.
Invocation as installkernel is for #23681.
- introduce several helper functions
- do not list unit files, but remove the runtime unit directory in
tearDown().
- do not list used interfaces, but remove all interfaces previously not
exists in tearDown().
- save routes and routing policy rules before running tests, and flush
unnecessary routes and rules in each tearDown() calls.
- drop many time.sleep() calls.
- call tearDown() after each sub tests.
- shorten code.
- several coding style fixes.
- etc, etc...
Hopefully, this improves performance of the test.
In the welcome line, use NAME= as the fallback for PRETTY_NAME=.
PRETTY_NAME= doesn't have to be set, but NAME= should.
Example output:
---
Welcome to Fedora Linux 37 (Rawhide Prerelease)!
[ !! ] This OS version (Fedora Linux 37 (Rawhide Prerelease)) is past its end-of-support date (1999-01-01)
Queued start job for default target graphical.target.
[ OK ] Created slice system-getty.slice.
---
We had a description in README, and an outdated list in the man page.
I think we should keep a reference-style list in the man page. The description
in README is more free-form.
I thought it would be nice to specify the last day of support, because I
thought it'd seem more natural. But in practice this doesn't work well, because
such a truncated timestamp is usually taken to mean midnight that starts the
given date. I.e. 2011-12-13 is a shorthand for 2011-12-13 00:00:00 and not
2011-12-13 23:59:59.999999999999. Let's instead specify that the given date is
the first unsupported day, which is meaningful for humans, and let the computer
treat it as midnight, which gives consistent interpratation.
