Dokumentacja

Microsoft's Coupon Dayz
ConsortiumInfo: "Microsoft today announced that it had entered into a trademark cross license agreement with leading cereal vendor Kellogg's, granting the grocery giant the right to continue to use the name 'Froot Loops...'" Humor

Wish I Could Do That In Linux
Aardvarchaeology: "For a few weeks, I've been slowly, slowly learning my way around the Open Source operating system Ubuntu Linux. Lots of things work just fine..."

Novell: 'Of Course Linux is Safe! (Sort Of!!)'
InfoWorld: "Come on, Justin. I've tried so hard to be nice, but comments like these just beg commentary. I guess Australia relaxed the tongue a wee bit too much..."

Ubuntu and Sun vs. Red Hat and JBoss?
Linux-Watch: "In the release of Ubuntu 7.04, with its optional Sun Java application server stack, the actively attacked piece is Red Hat Enterprise Linux, but JBoss is the real target..."

The Hard Truth About Installing Linux
iTWire: "Having had a go at a few more Linux installations than the average newbie, I can say that Ubuntu is probably about as easy an install as it's going to get..."

next: conclusion up: making linux installation disks previous: creating a cd-rom contents

subsections

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.

next: conclusion up: making linux installation disks previous: creating a cd-rom contents

lennart benschop 2003-07-16

Linux FAQ's & Manuals

creating the install scripts

example installation scripts

configuring linux

making the system bootable

debugging installation scripts