The "S|s|single" option is handled by systemd (starting
rescue.target). And the rescue target basically removes the need for
a special debug shell. (Also, there is "systemd.crash_shell=1" for
starting a shell if systemd crashes.)
Also, symlink kbrequest.target to rescue.target as suggested by the
systemd.special manpage. This way, you can start a sulogin rescue
shell by pressing Alt+Up.
Restarting <interface>-cfg.service may cause the interface's IP
addresses to be flushed. If the default gateway goes through that
interface, then the default gateway is deleted. So we need to
restart network-setup.target.
This allows setting the max tcp window size for the route of
the default gateway (usually the internet access).
It works only for non-DHCP configurations by now.
To be honest, it's more like "be less discriminating against USB tablets".
USB tablets usually get autodetected, device name is not necessary and defaulting to a serial touchscreen is a clear discrimination.
Unconditionally remapping buttons is generally not a good idea either.
Old defaults transformed into examples.
During a configuration switch, changed units are stopped in the old
configuration, then started in the new configuration (i.e. after
running the activation script and running "systemctl daemon-reload").
This ensures that services are stopped using the ExecStop/ExecStopPost
commands from the old configuration.
However, for some services it's undesirable to stop them; in
particular dhcpcd, which deconfigures its network interfaces when it
stops. This is dangerous when doing remote upgrades - usually things
go right (especially because the switch script ignores SIGHUP), but
not always (see 9aa69885f0). Likewise,
sshd should be kept running for as long as possible to prevent a
lock-out if the switch fails.
So the new option ‘stopIfChanged = false’ causes "systemctl restart"
to be used instead of "systemctl stop" followed by "systemctl start".
This is only proper for services that don't have stop commands. (And
it might not handle dependencies properly in some cases, but I'm not
sure.)
Running it from systemd rather than cron has several advantages:
systemd ensures that only one instance runs at a time; the GC can be
manually started/stopped; and logging goes to the journal.
We still need cron to start the service at the right time, but
hopefully soon we can get rid of cron entirely (once systemd supports
starting a unit at a specific time).
This is mainly useful for specifying mounts that depend on other
units. For example sshfs or davfs need network (and possibly
nameservices).
While systemd makes a distinction between local and remote
filesystems, this only works for in-kernel filesystems such as
nfs and cifs.
fuse-based filesystems (such as sshfs and davs) are classified as
local, so they fail without networking. By explicitly declaring these
mounts as full systemd units (as opposed to having systemd generate
them automatically from /etc/fstab), dependencies can be specified as
on every other unit.
In the future, we can probably port NixOS' filesystems handling to use
these native systemd.mount units and skip /etc/fstab altogether, but
this probably requires additional changes, such as starting systemd
even earlier during boot (stage 1).
I'm not any good at perl, and I only came up with this after many
slow attempts. Any review welcome.
But until this, memtest was broken, and extraPrepareConfig as well, in grub.
Having all services with DefaultDependencies=yes depend on
local-fs.target is annoying, because some of those services might be
necessary to mount local filesystems. For instance, Charon's
send-keys feature requires sshd to be running in order to receive LUKS
encryption keys, which in turn requires dhcpcd, and so on. So we drop
this dependency (and swap.target as well for consistency). If
services require a specific mount, they should use RequiresMountsFor
in any case.
Charon needs this to include the dynamically generated
/root/.vbox-charon-client-key. (We used
users.extraUsers.root.openssh.authorizedKeys.keyFiles for this, but
that no longer works.)
Instead of the somewhat hacky script that inserted public keys
into the users' .ssh/authorized_keys files, use the AuthorizedKeysFile
configuration directive in sshd_config and generate extra key
files for each user (placed in /etc/authorized_keys.d/).