A Look At Additional InstallRoot Elements

Introduction

This document takes a look at some additional or peripheral issues relating to the install process - including different views of the install procedure, how to modify the install behaviour, and how to apply patches.

Overview

Although the install process is essentially an automatic one (when correctly configured!), it is possible to modify its behaviour to meet particular idiosyncratic or local conditions which do not need to be catered for by one of the default behaviours (one-off test or debug installations, etc).

For example, modifications to the behaviour of the install process (for COs, mainly outwith Informatics):

Also, how to install machines (both for COs and CSOs):

Coping With DHCP

The LCFG install process uses DHCP to download host and network information onto the install client, to be used at install time. A DHCP request is broadcast by the install client on the local subnet, and the information it requests:
request subnet-mask, broadcast-address, routers, domain-name,
        domain-name-servers, host-name,  time-servers, 
        user-class, ntp-servers;
is controlled by the local copy of dhclient.conf - which is part of the installroot image (and is therefore configurable - on a site-wide basis - prior to installation).

It is also possible to supply (some of) this information via removeable media (floppy or memory stick, containing the configuration file ip.cfg).

To change the behaviour of the DHCP exchange, the installroot files dhclient.conf and dhclient-lcfg-script need to be changed (the former requests information from the DHCP server - as shown above - and the latter packages that information for use by the /etc/rc_install script).

To change the information requested from the DHCP server, amend the request list in dhclient.conf (see example above, and dhclient.conf(5) for more detail). It is assumed that the corresponding options will be available via dhcpd.conf on the DHCP server (this file is controlled via LCFG, and configured by the dhcpd component).

In DICE, the DHCP servers can be identified by the presence of "#define DHCPD_INTERFACES ..." in the profile (and the presence of a /etc/dhcpd.conf file).

How To Add Extra Components

During the installroot process, a core set of components are available (usually to be run with their "install" method). These are supplied as part of the install image, created by buildinstallroot.

If an additional component is required at install time (and assuming that the component has already been submitted via the component and server defaults file RPMs) the component RPM name should be included in this list - which is currently maintained via Subversion as lcfg/core/packages/lcfg/lcfg_fc5_installroot.rpms. Once the RPM is installed, the component script will appear in /usr/lib/lcfg/components.

The configuration of the service for which the component is responsible should be handled by the Configure() method within the component script.

How To Add Packages To The Installbase

An installbase is a list of RPMs to be installed on groups of machines. These are usually release-specific - for example: "lcfg_fc5_installbase.rpms" (minimal RPM set for LCFG Fedora Core 5 install) or "lcfg_fc6_64_installbase.rpms" (minimal RPM set for LCFG Fedora Core 6 x86_64 install). These are then included in the profile.packages resource in the various release-version installbase.h files.

To add a new package (an RPM in the DICE world) to the package list, add the package name to the relevant file in the Subversion repository under core/packages/lcfg.

How To Use Install-Time Contexts

Contexts can be used to constrain the scope and applicability of resources (for instance, to set local - rather than network - resources when using a standalone laptop). It is also possible to use contexts at install time, and some are automatically set - there are, for example, two contexts used at install time: See the DICE Wiki pages for more info.

Possible uses (via profile settings) include:

Note that contexts are dealt with as part of the parsing of the profile by mkxprof (when the XML version is generated) or rdxprof (when the DBM file is generated). There are no constraints on the value of a context string, and it is up to the component or other application/utility to do something useful with it.

An Overview Of The Install Process

The install process is covered in detail in other documents, but from the CSO perspective, it involves:

What The Different Installroot Boot Options Mean

There are various options available at install time and, once the install kernel is running and the profile has been downloaded, a list of these options is presented:
    (I)nstall, (D)ebug, (S)hell, (P)atchup, (R)eboot:
These behaviours are controlled by the rc_install script, which executes local commands or calls relevant components as appropriate:

How To Write And Invoke Patches

Installroot patches are small scripts that can be downloaded from the web for execution locally, and "are usually used to repair problems which hinder a Linux machine from booting". The execution of such a script is initiated manually at install time by choosing "p" from the install options and giving the patch name. Once selected, the install component is invoked with the "patchup" method, which downloads the patch from a given URL into /tmp, and then runs it - returning to the "(I)nstall, (D)ebug, (S)hell, (P)atchup, (R)eboot" prompt when complete.

Patch scripts should be installed in a patches sub-directory of the relevant unit under /group/project, for example:

/group/project/linux-team/html/patches/grub
(At the time of writing, there are no other patch locations.)

To write a patch, simply create an executable script in the default location above. For a little more detail, and an example, see the patch page (which also contains a list of the available patches).