Structure of a larch live system

The vast majority of the code that runs in a live CD/USB 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 in general any changes will be lost when the system shuts down, the actual changes being made only in a RAM-based filesystem (but see "Session saving").

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 union layer is created, in the archive mods.sqf, containing all the modified files. The user is free to include (pretty well) any customizations (s)he wants in this overlay file, which is also placed in the 'larch' directory of the boot device.

Using larch's merge-overlay feature it is possible to rebuild the 'mods.sqf' archive to incorporate subsequent changes to the system. When this is done an additional union layer (filter.sqf) will be created. For further details see the session saving page.

These system archives are combined when the live system boots. They are mounted as branches of a union (aufs) file-system with the overlay above the 'standard' system, so that files in the overlay have priority over the original ones. A further, tmpfs, layer is placed on top of these, which effectively makes the whole system writeable. When session saving is being used this top layer is initialized during the boot sequence, by copying the contents of a compressed archive (overlay.tar.lzo) into it. lzo compression is used here because of its speed ('lzop' is a dependency of the 'larch-live' package).

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, prepare the union file-system and prepare it 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 several 'hooks' (code plug-ins) to the Arch Linux mkinitcpio system (they are in the 'larch-live' package). The first, 'larch1', is concerned with finding the boot device. It can select a device on the basis of UUID, partition label, partition name ('/dev/sdb1', etc.) or else it can search all available devices for the file '/larch/larchboot'. A simple validity check is made by testing the existence of the '/larch/system.sqf' archive.

The second hook comes in two flavours - one for aufs and one for unionfs - it just sets some variables according to which unioning file-system is being used (at the moment only aufs is properly supported).

The third hook, 'larch3', performs the actual preparation of the larch root file-system, combining the system and overlay archives with a tmpfs upper layer in a union and carrying out various other initializations.

In order to generate the special initramfs a customized '/etc/mkinitcpio.conf' is used, prepared during the build process from the template '/etc/mkinitcpio.conf.larch0' and saved as '/etc/mkinitcpio.conf.larch'. If you want to customize this, you need to edit '/etc/mkinitcpio.conf.larch0' in 'rootoverlay' in the profile (the gui has a button for this).

There is also a customized mkinitcpio preset in '/etc/mkinitcpio.d', also working with a template - 'larch.preset0' is used to produce 'larch.preset' during the build operation. In addition this preset replaces 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, but the main addition is the session saving code. If booting from CD/DVD we will want to eject this 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 'larch3' 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 ('larch3' 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.

[unionfs as an alternative to aufs]

In principle, unionfs can be used instead of aufs, but as aufs is supported by current Arch Linux kernels it is obviously the first choice. Indeed the current larch code probably won't work with unionfs, as it hasn't been tested - but the framework to support it is in place.

Top