Structure of a larch live system

The vast majority of the code that runs in a live system is exactly the same as in a normal system running from hard disk. The main differences arise through the live system being based on a read-only root file-system, so various adjustments are necessary to make the areas that must be writeable appear to be so. I say 'appear to be' because the bulk of the underlying system is generally (as is the case in a larch system) stored in a squashfs archive, which is not writeable. This is overcome to some extent by using aufs to add a writeable overlay.

squashfs and aufs

In larch, as in many other live systems, the ability to (apparently) write to a read-only file-system is provided by aufs (originally derived from unionfs). The file-system is also compressed, using squashfs, so as to fit more data onto the storage device. A custom Arch Linux installation (you can choose which packages are installed) is compressed into a squashfs file-system in the file system.sqf, which is placed in the '/larch' directory of the boot device.

For use in a live system a few changes must be made to some files in the installation. In larch this is usually not done directly, the installed system is left in a 'clean' state. Instead of that, an additional aufs layer is created containing all the modified files (in a writeable system also changes made by the user will be placed in this layer). You can include (pretty well) any customisations you like in this overlay, giving you a great deal of freedom in designing your live system.

When the live system boots an aufs file-system is set up with the base system as its lowest layer (branch). The modification layer - either the 'mods.sqf' file or the medium itself (if writeable) - is placed above this. If the modification layer is not writeable (either inherently or because of a boot option) a further, writeable, layer in tmpfs (a memory based file-system) is added above this. The aufs file-system is then used as the root file-system for the live system (compare with a normal linux system where the root file-system would be a hard-disk partition).

'Bundles'

An additional possibility inherent in aufs is that of including additional code or data 'packages' - which I here call 'bundles', to distinguish them from the normal packages managed by pacman - by adding them as further layers (branches). This is also supported in larch. It is a completely optional feature, supported in the initramfs code, by the 'larch' hook (see the man-pages or the Arch wiki for more details on mkinitcpio and Arch initramfs support). Bundles are simply overlays over the root file system (like software packages) which should be compressed into squashfs archives with names ending in '.sqb'. They should be placed in the medium's '/larch/bundles' directory and during the boot process they will be added to the aufs file-system in alphabetical order directly above the base system layer.

initramfs and mkinitcpio

It is, in general, not possible to boot directly into a live system. Some form of 'initrd' or 'initramfs' is required, in order to find the boot device and prepare the root file-system for running. Many modern GNU/Linux systems use initrd/initramfs (the former being now deprecated) as a matter of course, for loading the necessary kernel modules, and Arch Linux is no exception, a modular initramfs system (mkinitcpio) being the standard way to boot Arch Linux, and larch also takes advantage of it, although some additions need to be made to boot live systems.

larch adds its own 'hook' (code plug-in) to the Arch Linux mkinitcpio system (the 'larch' hook is supplied in the 'larch-live' package). It performs several steps, the first of which is to find the live medium.

Note that the live medium is not necessarily the same as the boot device (which could be a boot-cd required for booting from another device unsupported by the machine's BIOS). The medium can be detected / selected on the basis of a UUID, a partition label, or a partition device node ('/dev/sdb1', etc.). Alternatively, all available devices can be searched for the file '/larch/larchboot'. Once the device has been found a simple validity check is made by testing for the existence of '/larch/system.sqf'.

An aufs file-system is set up and the squashfs archive 'system.sqf' is added as the base layer. If there are 'bundles' in the '/larch/bundles' directory these are layered on top of the base (as aufs branches).

Then the modifications overlay is added (as a further aufs branch), and if the overlay is read-only then another layer is added on top of it, a writeable in-memory file-system (tmpfs).

A few more tweaks are made to prepare the file-system for the boot proper (see the code of the larch hook in '/lib/initcpio/hooks/larch' for the details) and this aufs file-system is then used as the root file-system for the further boot process, after leaving the initramfs.

In order to generate the special initramfs a customised '/etc/mkinitcpio.conf' - '/etc/mkinitcpio.conf.larch' - is used, also supplied in the 'larch-live' package (though it can be replaced by a customised version in the profile's overlay directory - the gui has a button for this).

There is also a customized mkinitcpio preset, '/etc/mkinitcpio.d/larch.preset', which is used to replace the standard preset belonging to the kernel, so that subsequent kernel updates (etc.) will regenerate a correct initramfs for the larch system. If you want to revert to the normal Arch Linux mkinitcpio behaviour (for example, if you are installing the system) you will need to replace the preset by the original, which gets saved with '.larchsave' appended.

/etc/rc.sysinit and /etc/rc.shutdown

The initial boot script and the shutdown script must be customized for use in a larch live environment. This is achieved by using hooks in the standard /etc/rc.sysinit and /etc/rc.shutdown scripts. The file 'etc/rc.d/functions.d/larch-hooks', in the 'larch-live' package, defines these. During startup the main tweaks are to the content of /etc/mtab and /etc/fstab. During shutdown we probably want to disable writing to the hardware clock, and if running from CD/DVD we will want to eject the device just before shutting down.

/etc/fstab

If the file '/etc/fstab.larch' exists this will be used as a persistent '/etc/fstab', being copied there during the boot process (in the 'larch' hook in the initramfs system). Otherwise a very minimal '/etc/fstab' will be generated at each boot. It includes entries for any existing swap partitions, but these are commented out unless the 'swap' boot parameter is specified (the default larch behaviour is to mount nothing automatically).

The 'x10d_fstab' script in the 'larch-live' package allows the very basic /etc/fstab generated by the initramfs system ('larch' hook) to be extended automatically, but '/etc/fstab' will only be changed if '/etc/fstab.larch' doesn't exist. This script adds entries for the partitions it detects, and also mount points in '/mnt' for them. The entries are such that the partitions are not mounted automatically.

Top