The KeepassXC documentation takes up 5 MB of final iso image size.
This is quite excessive.
Removing the documentation doesn't impair program usage. The documentation
can easily be accessed online from the KeepassXC website, it is directly
linked in the help menu.
Activating md raid or lvm means that the kernel changes the metadata like
timestamps and mount counts of the devices and writes them to disk.
Also reconstructing degraded md raid devices is automatically activated.
There are cases when writing to disks is absolutely not wanted. For example
when restoring data from broken disks or when doing forensics.
The nomdlvm boot commandline option prevents any activation and thus
not wanted writes. If the user wants to use md or lvm with the option
set, all md or lvm devices have to be manually found and activated.
nomdlvm is only implemented as boot commandline option and does not use
the YAML config file. The reason is that the udev rules are evaluated
before sysrescue-configuration.lua is run, so the YAML config is not
ready yet. Moving nomdlvm after sysrescue-configuration.lua would be
an invasive operation and modify the activation order of all md and lvm
devices for all cases, increasing the probability of regressions.
Also udev rules offer a direct access to boot commandline options, making
implementation straightforward and robust.
Initializing the pacman key database during boot can take considerable time
and there is no locking during this time against concurrent file access.
This can lead to problems when installing packages soon after reboot.
This also speeds up the boot process.
Additional disk space requirement is about 1 MByte.
Fixes#290
Firefox doesn't use the system CA database but has it's own. Use the
policies.json file to let Firefox trust the entries from the
sysconfig.ca-trust of the YAML config too.
There is no dependency on NetworkManager being actually online when
sysrescue-initialize.py calls load-srm to honor the late_load_srm config
option. So without this patch this can fail when the network takes a
few seconds until the link is actually up.
Fixes#288
When the lua script parses the YAML config, it converts a `1` to `1.0` because in
lua all numbers are floats. So it writes out `1.0`, which is then loaded by the
python scripts later. Make the type conversion for booleans aware of this.
This allows to write something like `ar_disable: 1` in the YAML and have it
acted upon as expected.
The recently implemented type casting code doesn't work intuitively for
booleans: for example it treats a string "0" as False and doesn't show
an error message for it. So the user might be unaware of this.
So add a dedicated conversion function for booleans.
Also add checks for conversions from dicts and lists, forbid to cast them
to strings because that is most probably not what the user wants.
With the new config file merging the user could accidently overwrite the
config values with wrong types, for example a boolean with a dict or list.
This could lead to the script aborting with an exception.
Use explicit type casting and default values to ensure correct operation
in this case. This is the same as recently implemented for autorun.
Implement a dedicated conversion function for booleans to for example
treat a string "0" as False, python by default would interpret it as True.
implement autoterminal: automatically started scripts that take over a virtual terminal for user interaction
See merge request systemrescue/systemrescue-sources!196
As described in #279, systemd does not re-evaluate the dependencies of changed units and
targets when daemon-reload is executed. It just continues it's transaction as it was
configured when starting the transaction.
So a late-loaded SRM can't autostart a service.
To work around this, add an extra call to "systemctl --no-block start multi-user.target"
after the daemon-reload. This will create a new transaction after the current one and
allow new services to be added to multi-user.target in a late-loaded SRM.
This means of course that this workaround only works for multi-user.target, not other
services or targets.
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.
It loops through all available block devices in the system and tries to mount them.
They are mounted to /mnt/<devicename>.
If they have "dev", "proc" or "sys" dirs in them, then the respective dirs of the
running SystemRescue are bind-mounted into it. This allows running some commands
like grub-install when chrooting into the dir.
When you set a "sysrescuecfg" option on the boot command line before this change,
only the files given on the boot command line were read, not the files in the
sysrescue.d dir. But previous versions of sysrescue-configuration.lua had a set of
built-in default values, these were still used.
Current sysrescue-configuration.lua does not include default values anymore, they
are now all in 100-defaults.yaml. So it is better to always read the default values
from the sysrescue.d dir and just merge files given with the sysrescuecfg option
additionally, with a higher priority.
The sysrescuecfg now also allows absolute paths for local files. When using relative
paths, the common sysrescue.d dirs are prefixed. In this case the file will usually
be loaded again, but at a higher priority.
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.
Previously when loading a YAML config, it overrode single values on the second hierarchy level.
But on all deeper levels new values were completely overwritten. This was inconsistent and poses
a problem for config entries that use these levels, like the ca-trust or the in-development autoterminal.
This change implements full merging of dictionaries on all levels to solve this. Values in files later
in precedence overwrite previous values. If the the old and the new config values are both dictionaries,
then the hierarchy levels are merged down recursively.
You can remove a previously existing dict entry again in a later file by assigning it an empty value.
Also fix handling of invalid YAMLs: ignore them instead of aborting execution
When the correct keyboard map is not set yet, it might be difficult for the user
to type in the command. This way they just have to press the arrow up key to reach it.
Fixes#273
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.
