Previous Next Table of Contents

8. /etc/lilo.conf and /hda4 - 10 M below 1024 cylinders

This is some more information in booting using a 10 MB partition. You might have to do this from the BOOT+ROOT diskette pair.

Calculate the top cylinder completely below 1024. Subtract 10 MB. Everything below that above 10 MB is available for DOS.

Make a 10 MB partition for boot files, on either of the first two disk (or every drive if you plan to relocate disks).

This holds all the kernel images, and the files that lilo needs to boot. It has to be below 1024 cylinders on either of the first 2 disks, so that BIOS can find them during BOOT time.

Alternatively, you could copy kernels to a DOS directory. Just don't defrag the disk without a boot disk available, so that you can run LILO to look for the files with the new disk sector layout. Having a boot disk around is a good idea anyway. (LILO remembers which sectors on the disk, where the kernel and boot files are located. If you run DEFRAG, the files move to different sectors, so you have to run lilo again - but you have to boot to do that!)

To create /hda4 you run fdisk to create the partition. fdisk allows you to allocate the 1 2 3 4 numbers as you choose. Don't blindly copy this example at it erases part of the disk (no not that part ..)

        fdisk /dev/hda # create part#4
        mke2fs /dev/hda4
        mkdir /hda4
        vi /etc/fstab # add the following line
        #
        /dev/hda4       /hda4        ext2        defaults   1   1
        #
        mount /hda4

8.1 /boot -> /hda4/boot

LILO looks for its file in /boot. These files have to be moved to /hda4 and lilo must find them there (but it still looks in the 'standard' place)

        mkdir /hda4/boot
        cp -p /boot/* /hda4/boot
        mv /boot /boot.del_soon
        ln -s /hda4/boot /boot
        ls -1 /hda4/boot

                /hda4/boot/any_b.b
                /hda4/boot/any_d.b
                /hda4/boot/boot.0300
                /hda4/boot/boot.b
                /hda4/boot/chain.b
                /hda4/boot/config
                /hda4/boot/ftape.o
                /hda4/boot/map
                /hda4/boot/os2_d.b
To see exactly which files you needed, run lilo with lots of -v options (or strace it).

8.2 /hda4/kernels/vmlinuz

When you build a kernel, it will be called 'vmlinuz'. When you are happy with it, edit /etc/lilo.conf and copy the file to vmlinuz-2.0.7, use 'vmlinuz' as the name of your unknown test kernel.

Twin booting systems will need names, such as 'old' and 'new', or simply make a point of using a different (newer) kernel increment, vmlinuz-2.0.8. Note that you might have old and new kernels, and also old and new root partitions. The idea is to install the new root partition, and configure it until it works, THEN you can delete the old. Note that they could all be "new", but different, eg Debian, Slackware, RedHat, FT, homw-brew ...

To build kernels direct into /hda4/kernels/vmlinuz, use the command

 #NOT#  make ... zlilo
        make INSTALL_PATH=/hda4/kernels/. zlilo 
 # or easier:
        make install

Note that you should edit /etc/lilo.conf, to register each kernel version, so that you will get the option of booting the one that works! As well as vmlinuz.

8.3 /sbin/installkernel

If you want make install to do something special, such as install itself into /hda4/kernels, create a script called /sbin/installkernel, and it will get called by /usr/src/linux/arch/i386/boot/Makefile with the right parameters, when you do a make install

# Arguments:
#   $1 - 2.0.7                          - kernel version
#   $2 - /usr/src/linux/arch/i386/boot/zImage - kernel image file
#   $3 - /usr/src/linux/System.map      - kernel map file
#   $4 - /hda4/kernels                  - kernel install path (blank)
You could then build into /hda4/kernels/vmlinux-2.0.7. And always know what version 'vmlinuz' was (ext2 fs only, not FAT or minix). The script might look like:

        #!/bin/sh
        # /sbin/installkernel

        DIR1=${4:-/hda4/kernels}

        [ -f $DIR1/vmlinuz    ] && mv $DIR1/vmlinuz    $DIR1/vmlinuz.old
        [ -f $DIR1/System.map ] && mv $DIR1/System.map $DIR1/System.old

        cat $2 > $DIR1/vmlinuz
# OR #  cat $2 > $DIR1/vmlinuz-$1
        cp  $3   $DIR1/System.map

        lilo

8.4 /hda4/kernels/vmlinux-1.2.13

Because you keep your old kernel images available, and even test them occasionally, you can experiment with new kernels without losing access to a working system (as long as the disk doesn't get corrupted). If you have upgraded other system components, this might not work fully, as very old kernels may be incompattible with very new system components.

        /hda4/kernels/vmlinuz           # experimental
        /hda4/kernels/vmlinuz-1.2.13    # tested
        /hda4/kernels/vmlinuz
        /hda4/kernels/vmlinuz-1.3.41    
        /hda4/kernels/vmlinuz-2.0.7
Of course other support files, on the system disk also change, eg 1.3.74 uses /lib/modules much more that 1.2.1 did, and modules compiled for one shouldn't be used with the other.

8.5 /etc/lilo.conf: old-121

Each kernel will have it's own boot stanza. As will combinations and variations of the other parameters. Here is an example. Notice that the root disk is hdb2, not hda1. The read-only is standard, it means mount read-only, until fsck has had a look at it. It will then be remounted rw.

        image = /hda4/kernels/vmlinuz-121
        root = /dev/hdb2
        label = old-121
        read-only 
        append="sbpcd=0x320,LaserMate"
The append="A very long line with lots of hexadecimal", is how you pass parameters to the kernel that haven't already been passed (root=/dev/hdb2,ro).

In this case it is telling the sbpcd driver to probe 0x320, before taking ages looking at other locations. sbpcd=0 tells the driver not to probe at all. sbpcd is the Panasonic interface to my external CDROM. I now use an EIDE cdrom.

It's how you tell Linux that your NE2000 card is at 0x300, if it couldn't find it fast enough (or safe enough). Multiple lines are joined with commas. See also /etc/conf.modules for IO_PORT assignments with newer kernels.

The first /etc/lilo.conf stanza found will be the default boot image. The others are available at boot time by pressing CTRL to get the LILO: prompt, and TAB to get a list of labels. The very first stanza is about where lilo will install the boot sector code.

8.6 /etc/lilo.conf: boot = /dev/hda

This tells LILO to install it's boot sector code at the start of the first disk. This overwrites the MBR sector (Master Boot Record), instead of installing in an ext2 partition. Users of DOS-5 and WIN.311 will find this OK. Users of Win95, OS/2, SVR4 or others may need to install that OS's MBR and install LILO on /dev/hda4. DOS-6 users can setup their config.sys to provide a fancy menu that selects the boot image, and starts loadlin.exe

It may be possible to move the other OS's MBR, and call it from LILO, but that would be getting confusing (except for maybe SVR4.0 which doesn't have a boot manager, except at sys-build time). It would be nice for other manufacturers to allow their MBR blocks to be included in anybodies boot manager (ie openly distributable on CDROM's). If only ...

LILO can boot DOS and WIN.311 just fine. Other OS's or versions may require their boot loader to call LILO, not the other way around. Then you would install LILO onto a partition containing an ext2 file system. Ie a partition or extended partition. This is documented in /usr/lib/lilo/doc.

        boot = /dev/hda
        delay = 50      # half second to press CTRL key
        vga = normal    # force sane state
        ramdisk = 0     # paranoia setting

If you have just clobbered your DOS boot sector - you can restore it using the dos command fdisk /mbr c:

You should be able to boot DOS via LILO. If not, then boot using your dos boot system disk. The one that CAN access the compressed SCSI disk. Then you will have to figure out how to make your boot loader, load the LILO loader on the Active tagged partition (/dev/hda4 or /dev/hda1). It may be possible to load a mini-dos partition (using your system boot manager) and run loadlin.exe from there. Loadlin allows simpler/multi-line append= lines, but these are now being replaced by modules.

8.7 /etc/lilo.conf: where to put it

If you have several bootable root partitions, you might get several /etc/lilo.conf files. Not a good idea. It makes sense to put /etc/lilo.conf on the same disk as the kernels, so that you can find it.

Do this for both the old and the new system. They share the same config file.

        ls -l /etc/*lilo*
        mount /hda4

        mv /etc/lilo.conf /hda4/lilo.conf
        ln -s /hda4/lilo.conf  /etc/lilo.conf

        vi /etc/lilo.conf       # -> /hda4/lilo.conf
I don't normally put files on the root directory of a partition, but creating /hda4/lilo.conf as a sym-link to /hda4/./etc/lilo.conf would probably confuse you, and might make the file harder to see (hts).

8.8 /etc/lilo.conf

        # /etc/lilo.conf
        # LILO configuration file
        # generated by 'liloconfig'

        # overwrite /MBR (entire boot responsibility)

                boot = /dev/hda

        # general options

                delay = 50      # from LILO prompt to default
                vga = normal    # force sane state
                ramdisk = 0     # paranoia setting

        # /hda1 is the new raven system (elf), soon to be renamed old! ...

        # current experimantal kernel
        # make INSTALL_PATH=/hda4/kernels zlilo

                image = /hda4/kernels/vmlinuz
                root  = /dev/hda1
                label = raven
                read-only 
                append="ide1=serialize,hdd=cdrom"

                image = /hda4/kernels/vmlinuz-1.3.41
                root  = /dev/hda1
                label = raven41
                read-only 
                append="sbpcd=0,ide1=serialize,hdd=cdrom"

                image = /hda4/kernels/vmlinuz-1.3.74
                root  = /dev/hda1
                label = raven74
                read-only 
                append="sbpcd=0,ide1=serialize,hdd=cdrom"

        # hdb2 is the _old system, about to be deleted and replaced

                image = /hda4/kernels/vmlinuz
                root = /dev/hdb2
                label = old
                read-only 

                image = /hda4/kernels/vmlinuz-1.3.74
                root = /dev/hdb2
                label = old74
                read-only 

                image = /hda4/kernels/vmlinuz-121
                root = /dev/hdb2
                label = old-121
                read-only 

        # /hdb3 - DOS on second disk requires any_d.b (apparently?)

                other = /dev/hdb3
                label = dos
                table = /dev/hdb
                loader = /boot/any_d.b


        # NOTES:
        # lilo -C /hda4/lilo.conf
        # boot=/dev/hda indicates MBR installation of LILO (not boot sector)
        # boot=/dev/hda1 indicates boot sector installation of LILO (after MBR)
        # boot=/dev/hda5 indicates boot sector installation of LILO (extended)
        #
        # hdd=cdrom NOT needed for NEC_260,MITSUMI IF driver detects name
        # read-only # Non-UMSDOS filesystems should be mounted read-only for checking
        # /etc/conf.modules now contains many IO_ADDR settings not /etc/lilo.conf

8.9 /sbin/lilo -C /hda4/lilo.conf

Or just plain 'lilo'.

This command reads /etc/lilo.conf, and builds a table of where the sectors are on the disk, writes out a map file (/boot/map -> /hda4/boot/map).

Lilo writes over the MBR sector (or as you configured it), so that when it boots, it loads its own code and can call either the DOS loader, or the LILO loader, to load the kernel and start it.

In addiition to this, the first sector of the Linux kernel image is a floppy disk boot sector, so you can simply write the kernel to a floppy, providing the root=/dev/hda1 has been poked into the kernel defaults (along with any other options).

lilo -v is more verbose, -v -v -v -v even more so.

8.10 /etc/conf.modules

This has nothing to do with LILO, but the IO_PORT and IRQ settings that you used to put in /etc/lilo.conf may need to be put there. The reason for this is that the modules are loaded after the system has booted, and modules tend to be more conservative about probing the hardware than the old style kernel drivers. IE my ne2000 is at address 0x300. The old kernel driver used to grope for it and find it. The new driver has to be told its IO_PORT address (but it then finds the IRQ).

Similarly, people with TWO ethernet cards, used to see which card the kernel found first, than adjust their configuration to eth0 and eth1. Now you have to tell the modules which card address is which driver.

        # /etc/conf.modules
        alias eth0 ne
        options ne io=0x300


Previous Next Table of Contents