Creating the Install Scripts

The diskettes and CD-ROM created so far, do not contain any installation scripts. They are usable as-is if you only need to install your freshly created Linux from Scratch distribution, but for a distribution that must be installed by unexperienced people, installation scripts are essential.

Example Installation Scripts

This section gives an overview of a set of example installation scripts. Their functionality is inspired by the Debian installer. These scripts are really simplified and should not be considered suitable for production use. The use of dialog and moderately complex shell programming are central to these installation scripts. All scripts are located in the /usr/scripts directory in the RAM disk and all must have execute permission.

Each invocation of the dialog command represents a visible screen that is presented to the user. Depending on the command type (e.g. -msgbox or -menu a different type of screen is shown. The output of most commands (the actual selection) is printed on the standard error device stderr. The redirect 2>$TEMPNAME causes this data to be stored in a temporary file. Using a cat command with back quotes we can put the contents of that temporary file in a variable. Note that many dialog commands are extended across multiple lines and the backslash must be the very last character on a line.

The top level script install_top sets a few variables that will be used throughout the installation. Next it starts with an introduction screen and it continues with the menu, which is repeated indefinitely. After each menu selection, a command is invoked, whose name is the concatenation of install_ and the selection. Therefore we can call eight scripts from the top level script: install_keyboard, install_partition, install_swap,
install_filesys, install_modules, install_install,
install_configure and install_reboot.

#!/bin/sh
# Example top level install script.
export TEMPNAME=/tmp/choice
export SCRIPTDIR=/usr/scripts
export SOURCEDIR=/mnt
export TARGETDIR=/target

dialog --clear --msgbox  \
  "Welcome to the Linux Installation Disk\n
Press ENTER to start installation.\n
Press ALT-F2, ALT-F3 or ALT-F4 for a shell prompt.\n
\n
Please make sure that all your disks are backed up\n
before you start installation" 18 60

while true
do
dialog --clear --menu "Linux Installation Disk Main Menu" \
        18 60 8 \
        keyboard "Select keyboard layout" \
        partition "Partition a disk with cfdisk" \
        swap "Select a swap partition" \
        filesys "Create a file system" \
        modules "Load kernel modules" \
        install "Install Linux " \
        configure "Configure Linux " \
        reboot "Reboot the system " 2>$TEMPNAME
SELECTION=`cat $TEMPNAME`
$SCRIPTDIR/install_$SELECTION
done

The script install_keyboard selects one of a few keyboard layouts. The interesting thing is that it also stores the name of the selected map file into the file /tmp/keyfile. Form there, the configuration script can adjust the keyboard layout selection in the target system, so when the target system is rebooted, it will have the correct keyboard layout enabled as well.

#!/bin/sh
#Keyboard configuration script.

KEYDIR=/usr/share/kbd/keymaps/i386

dialog --clear  --menu "Select Keyboard Layout" 18 60 5\
    US "Standard US layout (common in the Netherlands)" \
    UK "UK layout" \
    DE "German layout (QWERTZ)" \
    FR "French layout (AZERTY)" \
    BE "Belgian layout (AZERTY)"  2>$TEMPNAME

SELECTION=`cat $TEMPNAME`

case $SELECTION
in
US ) KEYFILE=$KEYDIR/qwerty/us.map.gz ;;
UK ) KEYFILE=$KEYDIR/qwerty/uk.map.gz ;;
DE ) KEYFILE=$KEYDIR/qwertz/de.map.gz ;;
FR ) KEYFILE=$KEYDIR/azerty/fr.map.gz ;;
BE ) KEYFILE=$KEYDIR/azerty/be-latin1.map.gz ;;
esac
# Save name of keyboard file for later.
echo -n $KEYFILE /tmp/keyfile
loadkeys $KEYFILE

The script install_partition lets the user select a hard disk and invokes cfdisk.

#!/bin/sh
#Partition a hard disk.

dialog --clear --menu "Select a hard disk to partition"\
     18 60  6 \
     hda "Primary IDE master" \
     hdb "Primary IDE slave" \
     hdc "Secondary IDE master" \
     hdd "Secondary IDE slave" \
     sda "First SCSI" \
     sdb "Second SCSI" 2>$TEMPNAME
SELECTION=`cat $TEMPNAME`
cfdisk /dev/$SELECTION

The script install_swap lets the user select a swap partition. It initializes the input field with the string /dev/. Next it asks for confirmation, as mkswap does a really destructive job to the selected partition. It records the partition name in the temporary file /tmp/swappart. The use of an input box to select a partition is not the most user-friendly way to do this job. Ideally the script would read the partition table and put those partitions with type 0x82 in a menu list to select from, but this is more complex.

#!/bin/sh
# Select and install a swap partition

dialog --inputbox "Enter the name of your swap partition"\
        5 60 /dev/ 2>$TEMPNAME
SELECTION=`cat $TEMPNAME`

dialog --yesno \
   "Any data on $SELECTION will be erased forever!\n
Are you really sure you want to continue?" 18 60 

if [ $? = 0 ]
then
   echo -n $SELECTION >/tmp/swappart
   mkswap $SELECTION
   swapon $SELCTION
fi

The script install_filesys is almost a copy of the install_swap script. Apart from the user-friendliness issue, this script should really be extended to allow multiple file system partitions, each on its own mount point.

#!/bin/sh
# Select and install a root partition

dialog --inputbox "Enter the name of your root partition"\
        5 60 /dev/ 2>$TEMPNAME
SELECTION=`cat $TEMPNAME`

dialog --yesno \
   "Any data on $SELECTION will be erased forever!\n
Are you really sure you want to continue?" 18 60 

if [ $? = 0 ]
then
   echo -n $SELECTION >/tmp/rootfs
   mke2fs $SELECTION
fi

The script install_modules is not implemented yet. It should offer a way to access the modules.tar.gz file, it should offer a selection of all available modules and next it should selectively extract the selected modules from the tar file. Finally it should ask the user for module parameters and run insmod on the specified module. This is left as an exercise to the reader. Likewise there should be an install_network script to configure the network.

The script install_install lets the user select a CD-ROM drive to install from. In the real world there should be a way to install from other sources as well, such as the network (nfs, wget) or an existing hard disk partition. Next it mounts the CD-ROM on the source directory. Next it asks for the name of the root partition. The script tries to be smart and already suggests the saved partition name in /tmp/rootfs if it exists. It mounts the partition on /target and proceeds to extract the giant tarball distro.tar.gz that contains everything from the distribution.

#!/bin/sh
# This installs the Linux system onto the hard disk.

dialog --menu "Select CD-ROM to install from" 18 60 6 \
     hda "Primary IDE master" \
     hdb "Primary IDE slave" \
     hdc "Secondary IDE master" \
     hdd "Secondary IDE slave" \
     sr0 "First SCSI" \
     sr1 "Second SCSI" 2>$TEMPNAME
SELECTION=`cat $TEMPNAME`
mount -r -t iso9660 /dev/$SELECTION $SOURCEDIR
if [ $? != 0 ]
then
   dialog --msgbox "Mount failed!" 18 60
   exit 1
fi
if [ -f /tmp/rootfs ]
then
   ROOTFS=`cat /tmp/rootfs`
else
   ROOTFS=/dev/
fi
dialog --inputbox "Select root partition" 18 60\
       $ROOTFS 2>$TEMPNAME
ROOTFS=`cat $TEMPNAME`
echo -n $ROOTFS >/tmp/rootfs
mount -t ext2 $ROOTFS $TARGETDIR
if [ $? != 0 ]
then
   dialog --msgbox "Mount failed!" 18 60
   umount $SOURCEDIR
   exit 1
fi
cd $TARGETDIR
tar zxvf $SOURCEDIR/data/distro.tar.gz

The install_reboot script could not be simpler. At least it asks for confirmation.

#!/bin/sh
# Reboot script

dialog --yesno "Ready to reboot?" 18 60 
if [ $? = 0 ]
then
  reboot
fi

Configuring Linux

What remains is the install_configure script. What it does is really dependent on the actual distribution that you installed. As a minimum it should do the following things:

• Set the default keyboard mapping depending on what you specified in the install_keyboard script.
• Create an /etc/fstab file containing the selected root and swap partitions.
• Make the system bootable. This is described in the next subsection.

Other things the configuration script could do:

• Set a root password.
• Set the time zone.
• Perform configuration of the network or to transfer the install-time configuration to the target system.
• Configure the kernel modules or to transfer the install-time module configuration to the target system.

After extracting the base system (the big tarball), you have the following options to proceed:

• Complete the installation using only programs that are on the RAM disk. There are only a few things that you absolutely have to de before you can reboot.
• Remain running from the RAM disk but also use programs and scripts that are on the freshly created hard disk partition. Binaries should be specially linked against uClibc.
• Perform a chroot into the root file system on the hard disk and run the second part of the install script from there. Once you have chroot-ed into the hard disk, you can normally use all shared libraries. The user need not be aware of the transition.
• Achieve the same result as before by using pivot_root. With pivot_root we can jump out of the initial RAM disk into the real root file system. We need to arrange that the post-install configuration script is run from init, but only the first time the system is run (the script removes itself from the init scripts). This has the advantage that the RAM of the RAM disk can be reclaimed.

In the latter two cases you are no longer limited by the programs and libraries available in the RAM disk. Without an intervening reboot you can continue to install and configure X, all your network services or just about anything. It is even possible to continue to use the system for production without a single reboot. This is not wise, because you want to test that the system is capable of rebooting.

Making the System Bootable

After the tarball distro.tar.gz is extracted, the root file system contains all files that make up the Linux distribution, including the kernel. A few files (such as /etc/fstab depend on your local situation and should be adjusted by the configuration script. Even then the system is not yet bootable². Making the system bootable is an essential step that the configuration script must perform.

Assume that the kernel on the hard disk contains all drivers necessary to mount the root file system from the hard disk (all necessary SCSI drivers). If you go for a minimal kernel, you will probably need to create a custom initial RAM disk, one that loads the necessary modules. Some distributions contain the mkinitrd script.

Making the target system bootable consists of the following steps:

• Creating LILO/GRUB config file. The name of the root file system is already contained in the /tmp/rootfs file, so this can readily be substituted into the configuration file. For GRUB we will need to translate it to a GRUB partition name as well, which may be a bit tricky in the shell environment available on the boot disk,
• Running the LILO/GRUB installer. The normal LILO or GRUB binary cannot be run from the install system as it is linked against the wrong libraries. For now assume that we use a version of the GRUB installer that is linked against uClibc. This needs not be included in the RAM disk, it can be on the hard disk in a special directory, which may be removed later.

The GRUB that came on the diskette or CD-ROM that you started the installation with, is also capable of making the system on the hard disk bootable, but this is not something to expect from an end user.

In a real-world system the configuration script should accommodate at least three situations:

• Linux is alone on the system.
• Linux must co-exist and be dual-bootable with an existing Windows installation.
• The system already has a boot manager of some sort (another GRUB, Windows NT boot manager) and the user will configure the boot manager to boot Linux as well.

In the former two cases, LILO or GRUB should be installed in the MBR of the hard disk, in the latter case, LILO or GRUB should be installed in the boot sector of a partition.

An alternative to making the system bootable from the hard disk is to create a custom boot diskette. In this case the configuration script only has to dd a pre-existing GRUB image to a formatted diskette and to write a custom menu.lst file to it. This saves the trouble of having to compile a custom uClibc version of GRUB and to keep existing boot managers intact. The problem is that in the near future, most new PCs won't have floppy drives, so this approach cannot be used.

Debugging Installation Scripts

There are at least three ways to debug the installation scripts:

• If the host system has the dialog utility, you can run the scripts on the host system. It is not wise to reformat random partitions though. Instead of doing a real mke2fs you could include an echo statement followed by sleep 5. This can at least be used to get most of the logic of your scripts right. Especially you can check that menus and other screens are displayed correctly.
• One step further is to chroot into the rootfs directory and to run the scripts from there. This way we can make sure that the shell, the dialog utility and the available shell commands are the same as on the target system.
• The next step is to create the RAM disk image that includes the scripts from the /usr/scripts directory and to copy it to a floppy or even a CD-ROM. Next we can boot on a real machine or a virtual PC product such as VMWARE or bochs. Preferably this is an old machine with a scratch hard disk that you can reformat as you like (or a hard disk image contained in a scratch file of a virtual PC product).

  You do not need to recreate the RAM disk image and reboot in order to fix every bug. Instead you can run a shell in a parallel virtual terminal. You can edit the scripts using the vi included in Busybox. You can kill the top level install script to make it start all over. Mount a diskette and (regularly) copy the edited and debugged shell scripts to it. Warning: if you switch off the computer without saving the debugged shell scripts, you lose them of course. Later the debugged scripts can be copied from the diskette back to the $MYBOOT/rootfs/usr/scripts directory on the host system and the boot diskettes or CD-ROM can be rebuilt.