SystemRescue supports loading SRM Modules (System-Rescue-Modules). These are squashfs file systems which allow to add custom files to the live system. This feature was originally introduced in version 3.x on legacy versions, but it had not been implemented immediately after the project was rebased on Arch Linux in version 6.0. This feature is available again in SystemRescue version 7.
This feature is useful for adding new programs to SystemRescue as a module can contain a program, its data files and all its dependencies, but this features can also be used to add custom data files (your favourite scripts, configuration files,…) even though a backstore may be more appropriate in this case.
All SRM modules must be placed in the directory designated by the
archisobasedir boot parameter (“sysresccd” by default) on the boot disk. This
is one directory above where the
airootfs.sfs file is stored. The SRM files
names must have a
.srm extension. If multiple srm files are found, they are
all loaded in alphabetical order. SRM modules are only loaded when the
boot parameter is present, either as
loadsrm=y. You can only
enable or disable the loading of all SRM modules on the command line. It is not
possible to specify which module to load.
SRM modules are standard squashfs file system images just like
These file systems are mounted on top of the regular SystemRescue file system
using overlay file systems. If a file is present in an SRM module and also in
the stock SystemRescue, the file in the SRM will take precedence.
You can create your own module using
mksquashfs. You just have to prepare a
directory with all the files you want to put in the module. If you want to add
extra programs to SystemRescue creating a module with standalone programs (such
as static binaries) should be quite simple. If you want to add programs which
have many dependencies this will be more complicated, as they may conflict with
what the stock SystemRescue needs.
SystemRescue supports the pacman package manager and repositories of the Arch Linux base distribution to install additional software. You may want to create an SRM module to provide additional packages which can be used without internet access. Another reason to create an SRM module is to avoid incompatibilities between new packages from Arch Linux and older versions of the package dependencies included in SystemRescue. By creating an SRM module soon after a new version of SystemRescue is released you will minimize the number of packages or dependencies that must be installed or updated. And hence you can use a particular version of SystemRescue with an SRM module created for this version for some time and you won’t be affected by incompatibilities introduced by package updates in the mean time.
cowpacman2srm script is provided with SystemRescue version 7.01 and more
recent. It packs all packages you have installed during a running SystemRescue
session using the Copy-On-Write space to an SRM file. It just writes installed
pacman packages and systemd unit symlinks for them, but not other changes in the
How to use cowpacman2srm:
cow_spacesizeboot parameter to increase the size of the Copy-On-Write area which is set to 25% of the physical RAM by default. For example you can boot using
cow_spacesize=4Gif you use a computer with 8GB of RAM so it allocates half or the memory to the COW area instead of just a quarter.
pacman -Sy packagename
cowpacman2srmas described below.
/run/archiso/bootmnt). Modify the bootloader configuration to add
loadsrmto the parameters in the boot command line.
cowpacman2srm [-s subcmd] [-c compalg] [-l complevel] [targetfile.srm]
subcmdis a sub-command to execute, it can be any of: prepare, create, all. (default: all)
compalgis any of the compression algorithms supported by mksquashfs (default: zstd)
complevelis the compression level for the given algorithm (if supported with -Xcompression-level)
This script runs in two stages:
preparestage all files belonging to pacman packages manually installed are being copied to a temporary directory
createstage the SRM file (which is a squash file system) is being created with the contents stored in the temporary directory.
You can either run both stages in a single run (this is the default) or one stage at a time. If you do not specify any sub-command the script is going to run the two stages in one run. If you want to customize the contents of the SRM module you can run the “prepare” stage first, then make customizations in the temporary directory (for example to add extra files) and then you run the “create” stage to produce the SRM file.
Be aware that SystemRescue does not have a mechanism to verify if the contents
of an SRM module are compatible with the running version of SystemRescue. The
SRM is just overlaid over the base file system. If the SRM contains changes to
system libraries or core programs, this could render SystemRescue unbootable or
unstable. Also the pacman package databases of SystemRescue and an SRM created
with cowpacman2srm are merged. This can disturb the operation of pacman if you
use an SRM module created with a different version of SystemRescue than you are
running it with. This is why it is not recommended to use
anything but the SystemRescue you want to use the resulting SRM with.