Profiles

This feature of the larch build system allows bundling all the configuration information for a particular live system 'design' into a single directory, a larch profile, and the name of the profile is the directory's name. This directory includes the list of packages to be installed, locale information and the particular tweaks and additions needed to customize the system, in particular a subdirectory containing the 'overlay' files - those files which have been changed from their initial fresh state after installation and those which have simply been added.

Note that of all the profile files and directories mentioned here only 'addedpacks' is not optional.

The overlay directory

One of the simplest features of the profile is perhaps the 'rootoverlay' subdirectory: everything in this directory is copied directly to the live system's overlay, so that the a file 'a/b/c' within this directory will appear at '/a/b/c' in the live system, regardless of whether this file previously existed. Note however that all ownerships are changed to 'root:root'. The bulk of the customizations for the live system would normally be placed in this directory.

It would be possible to make the desired alterations directly to the base system, and there are situations in which one would pretty well have to do it this way (for example if a modified or added file was to have some ownership other than 'root:root'). But another advantage (apart from the encapsulation of the customizations in the profile directory) of keeping the modifications in a separate directory is that the base installation can be kept 'clean' and thus it is easily reusable.

If you would like to have a look at a profile, look in the 'profiles' directory in the 'larch-profiles' package (if you have downloaded larch by means of the 'larch-setup' script that will be 'larch0/profiles'). Each of its subdirectories is a profile. If you want to make your own profile, it is probably easiest to start with one of the examples. Copy one of these directories to your working directory and rename it (to avoid confusion).

The cd-root directory

This directory contains files that will be (more or less) directly copied to the larch medium, partly dependent on the available bootloaders.

Bootloader independent files are provided in the 'larch' package at 'cd-root/boot0'. Individual files can be added or substituted by supplying them in the profile at cd-root/boot. It is also possible to completely replace the basic boot directory by having cd-root/boot0 in the profile - then the default version will not be used. These files are copied to the 'boot' directory of the bootable medium.

There are also directories for bootloader dependent files. These are only copied over if the live system has support for the corresponding bootloader (i.e. if the corresponding packages - 'grub' and 'syslinux' - are installed). These end up as subdirectories of the medium's 'boot' directory, 'boot/grub', 'boot/syslinux' or 'boot/isolinux', and work in a similar way to the 'boot(0)' directories. larch provides default versions of these directories in 'cd-root/grub0' and 'cd-root/isolinux0'. To extend these, or replace individual files, place your changes in the directories cd-root/grub and cd-root/isolinux in the profile directory, if you want to completely replace these directories, supply your versions in cd-root/grub0 and cd-root/isolinux0 in the profile directory.

The contents of the directory cd-root/larch/copy will appear in '/larch/copy' on the medium. During booting the larch live system will copy the contents of this directory to the tmpfs base directory ('/.livesys'). This feature is not used by the larch system itself, but it can be used in various ways by the live system - the example profiles use it to some extent, for controlling autologin and for data required for installation as a normal Arch system (information on features specific to a live system which should be stripped out if a normal installation is performed).

The contents of the directory cd-root/larch/extra will appear in 'larch/extra' on the medium but are otherwise unconnected with any larch functionality. Live system designers can use this in any way they like.

Other important files within a profile

  • addedpacks - This is the only compulsory file in the profile (it must even be present if you are not using the installation stage, but it can be empty in that case). It contains a list of packages and package groups to be installed to the 'base' system. Here you can enter all the applications you would like in your live CD/USB system (and subsequently installed to a hard disk partition, if that was your intention). Thanks to pacman you don't need to sort out dependencies, these should all be included automatically. See here for details.
  • vetopacks - Allows 'vetoing' of packages included indirectly in the installation list from 'addedpacks'. See here for details.
  • pacman.conf.repos - Set the repository part of 'pacman.conf' for the live system, and possibly also for installation of the base system (See here for further details). The default version will be adequate for many situations, but you will need to supply this file if you use the 'testing' repository, for example.
  • pacman.conf.options - Set the options part of 'pacman.conf' for the live system and for installation of the base system (See here for further details). This will generally not be needed as the default version will be adequate for most purposes.
  • bootlines - This file contains bootloader independent boot lines, so that the same file can be used for grub and isolinux/syslinux. The gui provides a button to edit this file. To get an idea of what should be in here look at the default version (in the 'larch' package, 'data' directory), or just click on the edit button.
  • rootoverlay/etc/rc.conf - As a major point of configuration in an Arch system this is important enough to get a button in the larch gui to edit it.
  • rootoverlay/etc/locale.gen - For convenience, the larch gui provides a button to edit this file, which determines which glibc locales are supported in the live system. The corresponding files are generated (to the overlay) by the 'larchify' script, which has an option (for experts only) to reuse the locale files from a previous run (in order to reduce generation time in cases where the locales are unchanged).
  • rootoverlay/etc/mkinitcpio.conf.larch0 - Again for convenience, the larch gui provides a button to edit this file, which allows you to tweak the initramfs. This is a special version of '/etc/mkinitcpio.conf' which is used to generate the initramfs for the larch live system. The default version is supplied as '/etc/mkinitcpio.conf.larch0' in the 'larch-live' package. Whatever else you change, don't change the larch hooks.
  • rootoverlay/etc/inittab.larch - If this file is present it will cause the original /etc/inittab to be saved with a '.larchsave' suffix, and this new version will be used for the live 'inittab'. This allows a special version of this file to be used just for the live system, an installer can replace it by the original during the installation process.
  • users - It is possible to add user accounts to the system during building. See below.
  • skel_* (directory) - Customized '/etc/skel' substitutes for use at build time only. See below.
  • vetodirs - Do not use this unless you really know what you are doing. Each directory listed in this file (one entry per line, comment lines start with '#') will be excluded from the live system. The directories are relative to the installation root.
  • build-tweak - Do not use this unless you really know what you are doing. It is a program (script) - so it must be executable - to customize the construction of the overlay (to a certain extent). It gets two arguments on the command line: the path to the installation being larchified, and the (full) path to the directory in which the overlay is being constructed. It is called just before 'mods.sqf' is squashed, but also before users are added.
  • nosave - The existence of this file will suppress the generation of the file 'larch/save' on a writable medium (unless overridden by an option to the medium generation script). It is also copied to 'larch/nosave' on the medium (also on non-writable media), so that this message is available later, e.g. when copying the medium.

Adding user accounts

The construction details should be provided in the 'users' file in the profile directory. It is an 'ini'-style configuration file, the sections being the user names. Here is an example: 

[DEFAULT]
pw =
expert =
skel =
maingroup =
uid =
xgroups = video,audio,optical,storage,scanner,power,camera

[u1]
uid = 999
skel =

[u2]
pw = p1
expert =
skel =
maingroup =
uid =
xgroups = video,audio,optical,storage
The 'DEFAULT' section is not necessary, but is generated automatically by the gui user-table editor. Only entries which differ from the default values need be present.

The default primary group is defined by settings in '/etc/login.defs' and '/etc/default/useradd' ('USERGROUPS_ENAB yes' in 'etc/login.defs' causes this to be a group with the same name as the user). You can override this by adding an 'expert' option, or by placing modified versions of these files in the profile's 'rootoverlay' directory.

The additional groups should be comma-separated and without spaces.

If no 'skel'-file is specified, the default ('/etc/skel') is used, including anything in the overlay. To use a custom 'skel'-file, place the directory in the profile, giving it a name starting with 'skel_', and place the rest of the name (the part after '_') in the configuration line.

A password can be set for the new user by entering this (plain text - I'm guessing this is alright in this situation ...). An empty password field will allow passwordless logins (at least on the console).

By default the UID number will be chosen automatically, but a specific number may be entered here. In Arch Linux the UIDs normally start at 1000.

Users are added by means of 'useradd', so anything placed in the 'expert' field should be a valid option to that command. If a user-name already exists in the system to be larchified, it will be ignored (it does not count as an error).

Top