serial consoles have separate systemd services (serial-getty@.service). We need to adapt
the handling and also need some different options for them than for regular gettys.
To allow sysrescue-initialize.py to differentiate between regular consoles and serial ones
they must be configured with the prefix "serial:" in the yaml, for example like this:
autoterminal:
"serial:ttyS0": "/usr/bin/bash"
Before this patch sysrescue-configuration.lua was executed twice each boot:
(1) during initramfs stage (2) in the regular system as sysrescue-configuration.service
While in theory both runs should create the same output, this isn't guaranteed and
differences could appear for example because of network issues. Finding and debugging
these is difficult because the output of sysrescue-configuration.lua created during
initramfs isn't available anymore when the final system is running.
This patch lets sysrescue-configuration.lua just run once during initramfs. The
output JSON file is then written to the new tmpfs mounted dir /run/archiso/config/.
This dir is also made the new default location for sysrescue-effective-config.json.
A symlink from /etc/sysrescue/sysrescue-effective-config.json to the new location
is created for compatibility with previous releases.
Until now sysrescue-configuration.lua always ensured the default values were
in the effective JSON config because there was no way to remove them. Now the
lua script is improved to allow full config merging, including a delete function.
This could lead to the user accidently removing a value. The scripts did not
expect this and accessed non existing keys, leading to an exception.
This is fixed with this commit.
This allows to add additional CAs as trust anchors via the root key
"ca-trust" in the YAML config files.
Why is this helpful and can't be done for example with SRMs?
After the CA files are copied, "update-ca-trust" must be called. This
updates *all* ca trust files. This means your SRM will override all
trust files with the ones used when creating the SRM.
When you then use the SRM with a newer version of SystemRescue, you will
still use the old ca trust files from when the SRM was built.
