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 GUI offers some help with profile management.

The cd-root directory

This directory contains files that are intended for more or less direct copying to the larch medium, without being incorporated in the squashed archives. This only applies to the subdirectories 'boot0', 'boot' and 'larch'.

Boot files

Everything in the 'boot0' directory is copied to the medium's 'boot' directory. If this directory doesn't exist, the default version supplied in the 'larch' package (at 'cd-root/boot0') is used.

Subsequently everything in the 'boot' directory is copied to the medium's 'boot' directory, potentially overwriting what was there before.

Files specific to the syslinux family of bootloaders are kept in the medium's 'boot/isolinux' directory. larch provides a default version (in 'cd-root/boot0/isolinux'. To extend this, or replace individual files, read the description of boot directory handling above.

Specification of boot options and choices

The file which ends up on the medium as 'boot/bootlines' is an easily parseable, bootloader independent representation of the boot menu choices for the larch system. The default version is supplied in the 'larch' package as 'cd-root/boot0/bootlines', but this can be overridden in the profile, as described above. The gui provides a button to edit this file (cd-root/boot/bootlines in the profile). To get an idea of what should be in here look at the default version, or just click on the edit button.

Special files in the cd-root/larch directory

This directory is copied as is to the medium. Only the files of interest in connection with the profile are mentioned here. Those generated during larchification and medium construction are documented in the corresponding sections.

  • delarch

    This bash script is run by the larchin installer during the tidy-up phase. It should remove/undo any profile-specific elements of the live system which should not be present in a normal installation. It receives a single argument, the path to the new installation.

  • boot-init

    Used in the 'larch' initramfs hook, this optional script allows adjustment of the overlay handling during the boot process, e.g. getting them from another path. Note that the shell environment here is that of the initramfs and thus very limited. This option is for experts only and it is assumed that the user will be able to determine what is possible and necessary by reading the corresponding code of the hook.

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.
  • 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.larch - 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.larch' in the 'larch-live' package. Whatever else you change, don't change the larch hook.
  • 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.
  • kernel - If a kernel other than the standard Arch 'kernel26' is used the name of the kernel binary in '/boot' and of the mkinitcpio preset file in '/etc/mkinitcpio.d' need to be supplied in this file, in the form 'kernel-binary preset-name' (the default value is supplied in the 'larch' package as 'data/kernel').
  • 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.

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