Updated hint

[linux_from_scratch_hints.git] / boot_any_hd.txt

AUTHOR: Bill Maltby <lfsbill@wlmcs.com>
DATE: 2003-09-08
LICENSE: GPL
SYNOPSIS: Boot any OS from any hard drive.
DESCRIPTION:
Many users have platforms capable of booting from any hard drive. This
hint is intended to make it easier for users to take advantage of this
capability with Lilo and LFS.
PREREQUISITES: Lilo version with "disk=" sections and "bios=" clause.
HINT:

As is usual for me, I began explaining everything in the world while
writing this. But I came to my senses and wrote a (hopefully) more
palatable version (i.e. shorter) that I hope meets the needs of a wide
range of users of different levels of experience. Constructive
suggestions are welcome.

Also welcome are contributions regarding things strange to me, like devfs,
and any improvements in the text and scripts.

I have checked, and this hint *is* shorter than the Lilo README, appearance
to the contrary notwithstanding. :)

CONTENTS
   I. OBJECTIVES
  II. STRATEGY
 III. BACKGROUND
  IV. BENEFITS
   V. CAVEATS
  VI. THANKS
 VII. PREREQUISITES
VIII. MY CONFIGURATION
  IX. IMPLEMENTATION
      A) General.
      B) Minimal fall-back, hda (W98 drive) default boot.
      C) Better fall-back, hda boot, hdb Linux root.
      D) Better fall-back, hdb default boot, bios= changes.
      E) Examples summary.
   X. TESTING AND GOTCHAS
  XI. A PARTIALLY GENERALIZED BOOTBLOCK INSTALL
 XII. FOLLOW ONS
XIII. SOME MORE READING
 XIV. SUPPORT

I. OBJECTIVES
    My three primary goals for this process are:
    a) faster reboot/recovery via enhanced "fall-back" capability;
    b) reduced upgrade risk of "downtime";
    c) more convenience by being able to boot from any hard drive in a
       node to any OS installed on any drive in that node.
    
II. STRATEGY
    Objective a) is supported by configuring a secondary drive that is boot
    ready and has a root file system containing everything needed to cont-
    inue service in "fall-back" mode if the primary drive is not available
    due to corruption or hardware problems. It is kept up-to-date via cron-
    invoked drive-to-drive copies of selected portions of my primary drive.

    Objective b) is supported by designating a drive/partition as my "sand-
    box" and using it for making bootable images that can be tested "end-to-
    end" with no hardware changes. For testing, I can boot it by just
    changing my BIOS boot sequence specification. If I trash that drive, a
    BIOS setup change gets me booting my primary drive again.

    Objective c) is supported by having every drive bootable as the "pri-
    mary" drive (from BIOS point of view) and configuring the boot loader to
    boot any of the valid OSs on any drive that will support this.

    This is implemented by making use of the ability of BIOS to boot any hard
    drive and making use of the ability of system loaders, like Lilo, to sup-
    port that capability in an OS-independent fashion.

III. BACKGROUND
    Recent BIOSs (ca. mid-1990s and later) have the ability to boot from any
    hard disk in the node. Use of secondary drives as a root file system is
    common practice, but I have not seen this enhanced boot ability exploited
    frequently for the benefits it can provide.

    Because cost per giga-byte of storage is now commonly below $1.00 (US),
    it is feasible to consider secondary hard drives as reasonable alterna-
    tives in recovery scenarios. When compared to the costs (in time, money
    and lost availability) of traditional recovery activities, a bootable
    secondary drive alternative may be quite attractive. It is even more
    attractive when you consider that the drive can also be used in daily
    operations, with some safeguards preventing loss of recovery utility.

    Common practice, when upgrading a node or building hard drive images that
    are destined for other nodes, has required either hardware reconfiguration
    (jumper changes, removal of the primary drive or its cabling) in order to
    adequately test "end-to-end". This increases risk of something going
    wrong and slows progress.

    In my past life (before BIOS had the capabilities) I provided similar
    capabilities with a simple home-made switch attached to the case that
    would swap drive assignments by changing the jumpering of the drives.
    Since this was in the days when drives were much less reliable than now,
    there were several occasions when I looked like a hero when full service
    was restored by simply flipping a switch. Now you can buy those switches
    ready-made. Better (maybe) is the fact that you can accomplish almost the
    same function through the combination of BIOS, boot loader and adequate
    planning and implementation.
    
IV. BENEFITS
    Here is where I cut a lot of verbiage. Apply your knowledge of your
    situation to see how you benefit. I'll just give some "one-liners" here.
    
    Workstation users who run different OSs on separate drives, can have
    quicker recovery when the primary boot drive/partition fails or gets
    corrupted. Boot floppy usage may become a "last resort" scenario.

    Administrators responsible for high-availability systems on-the-cheap
    can recover much more quickly than with typical alternative processes
    and might continue to provide service, at possibly reduced levels, even
    when the primary drive has failed. This "buys time" while awaiting the
    hardware repair.

    Developers/experimenters that must engage in constant upgrade and test
    of their OS, as many (B)LFSers do, can reduce risk of catastrophe by
    having the primary boot stuff be "sacrosanct" and untouched by the
    development activities. If you trash your development drive to the point
    it is not bootable or recoverable, change the BIOS setting and reboot.
    You are back in business (hope you backed up your development stuff).

    When compiling for another node onto a drive that will be inserted on
    the target node, you can configure the boot process to boot in that node
    as any of the BIOS-bootable drives. You may not need to even change
    jumpers and should not need to remove any existing drive if a "slot" is
    available on one of the IDE cables.

    Lastly, all benefit because you have the full set of tools available to
    recover the failed stuff. No more working in the restricted boot-diskette
    environment (unless you get *really* inattentative).

V. CAVEATS
    As with any reasonably complex procedure, there are many opportunities
    for mistakes and unexpected circumstances to foil your best efforts
    against disaster. It is very important that you plan for and test any
    recovery procedures that might be needed to restore service as quickly
    as possible. A multi-tier plan that covers from minor damage to a comp-
    lete disaster should be in place and tested. Be sure that your recovery
    media is reliable and available.

    If you use devfs(d), you will need to make the necessary adjustments on
    your own (for now) - I use a static /dev directory as provided by (B)LFS.
    Contributions from devfs users are appreciated.

    As I've seen posted somewhere, "If you break it, you get to keep the
    pieces". I have *no* responsibility whatsoever for your results.

VI. THANKS
    John McGinn - who posted to LFS development when he first discovered and
    used the "bios=" Lilo parameter while creating a boot drive that was
    destined for another box. That post may have saved me a lot of research
    and additional experimentation.

    The LFS and BLFS projects, and all those who constructively participate,
    for the on-going education provided to me.

VII. PREREQUISITES
    a) Determine the capabilities of the BIOS for any nodes involved in the
       process you will undertake. Be sure that they will support your inten-
       tions. As example, one BIOS I have will allow selection of a non-
       primary drive for boot, but then will not allow another HD to boot if
       that drive fails to boot. Another BIOS may allow "fail-over" to other
       drives to be specified. This may be important if you are planning to
       use this hint's techniques to provide automatic "fail-over". You may
       need to temporarily add drives to a node to make this determination,
       as a BIOS may not allow selection unless it detects a drive.
    b) Educate yourself. If you are somewhat new to these processes, a review
       and understanding of some of the documents in the references at the
       end of this hint will make your efforts more likely successful.
    c) Have a recovery plan, in place and tested, that is appropriate to your
       situation, as mentioned above.
    d) A working GNU/Linux host node (preferably a (B)LFS one).
    e) A hardware and drive partition configuration that will support your
       goals (placement of user data, mounting of various directories and so
       on).

VIII. MY CONFIGURATION
    A small private network with nodes having various CPUs (486 DX2/66, AMD
    5x86, Cyrix 6x86, AMD K6-III and others), various memory configurations,
    some BIOS that support secondary-drive boot and some that may not (don't
    know yet), various OSs (recent CVS (B)LFS, RH 6.2, RH 6.0, W95, W98). All
    nodes have multiple HDs.

    I use Lilo. You may be able to use Grub, or another loader. I have not
    tried any others, because of a lack of interest. As I figured, the
    expected benefits to the list of the switch to Grub haven't (apparently,
    based on list traffic) materialized. It seems the "weaknesses" in Lilo
    traveled with the users and also affects Grub.

    The platform upon which this procedure was developed is a workstation
    configuration as follows.

    PC CHIPS M-571 mainboard (updated BIOS), AMD K6-III 380MHz, 256MB SDRAM,
    4GB primary drive W98 (seldom used) /dev/hda, 20GB 10K RPM drive "pure"
    LFS pre-cvs (my normal boot drive) /dev/hdb, CD-RW as /dev/hdc, 40GB
    7800 RPM utility drive (my "fall-back") /dev/hdd. The OS is a Pure LFS
    installation based on Ryan Oliver's 2.2.8 scripts, slightly modified.
    Tested with lilo versions 22.2 and 22.5 (which needs nasm installed).
    I've not tested the nerw master boot or other new parameters available
    with 22.5. But the setup I used for 22.2 worked unchanged with 22.5.

    My normal boot is /dev/hdb, first fall-back is /dev/hdd, second is
    /dev/hda (W98) and last is my boot diskette. You need to adjust the
    examples to account for the normal boot drive (primary drive from BIOS
    point of view).

    My mount configuration (edited out non-significant things) is:

        /dev/hdb7 on / type ext2 (rw)              # Normal root
        /dev/hdb1 on /boot type ext2 (rw)          # Normal boot
        /dev/hda1 on /mnt/hda1 type vfat (rw)      # Fallback boot 2
        /dev/hdd7 on /mnt/hdd7 type ext2 (rw)      # Fallback root 1
        /dev/hdd1 on /mnt/hdd7/boot type ext2 (rw) # Fallback boot 1
    
    Although I have separate /boot partitions, this is not mandatory. But it
    does allow additional security because I can leave it unmounted (or
    mounted read-only) so it is less likely to be damaged. The aggravation comes
    when you run Lilo and forget to (re)mount it read-write. *sigh*

    Of note above is the /mnt/hda1 listing. It is a 4GB drive dedicated to
    W98. So there is no room for a separate boot/root LFS partition. That is
    handled by configuring the Linux kernel to support vfat and creating a
    directory in W98 of /liloboot with a copy of the needed parts of my
    normal boot directory (actually, it has everything because I haven't
    taken the time yet to clean it up). The important things are those
    needed when installing the Lilo boot blocks (kernel image, boot.b,
    etc.) and the things needed at boot time. See the Lilo man pages and
    README for a list of them.

    WARNING! The normal /boot/boot.b is a symlink to boot-menu.b or some
    equivalent. The Win* OSs I've used don't support symlinks. So you must
    copy the target of the symlink to liloboot and name it boot.b. Like so:

    cp -avL /boot/boot.b /mnt/hda1/liloboot # Derefs, copies target, renames

    You must adjust these examples to fit your configuration and intentions.
    I use each drive as backup to the other, as needed. That is, if /dev/hdb
    fails, I use /dev/hdd as my primary drive and /dev/hdb will become the
    "fail-over" drive until I have reason to switch them again.

    I run Lilo boot installs to all three of my hard drives. This way, even
    if two of my drives fail, I can still boot *something* from the
    remaining drive. I even have a minimal RH 6.0 that I can boot for
    recovery purposes. I also keep a recovery diskette (see the BLFS book,
    chapter 3) as a "last resort" tool. But I doubt I will need it again (I
    had to use it while testing these procedures - more on that later).

IX. IMPLEMENTATION
    A) General. I have structured my /etc/lilo components to reduce acci-
       dental running of the wrong configuration. For this reason, I have no
       file named "/etc/lilo.conf" and I have a directory structure like this.

       /etc/LiloBootInst
           LiloBootInst/a-boot - for setting up hda as default boot drive
           LiloBootInst/b-boot -  "     "    "  hdb "     "     "     "
           LiloBootInst/d-boot -  "     "    "  hdd "     "     "     "

       In each of those sub-directories are files named similar to this.

           ?-boot.PR0?-test     - shell to install Lilo boot blocks on hd?
           ?-boot.PR0?-test.out - output from shell a-boot.PR01-test
           ?-boot.PR01          - conf for W98/LFS hdb boot
           ?-boot.PR02          - conf for W98/LFS hdb/LFS hdd/LFS boot

       Contents of shell a-boot.PR01-test is

           lilo -v3 -C /etc/LiloBootInst/a-boot/a-boot.PR01 \
               -t &> a-boot.PR01-test.out

       Until you remove the "-t" on the second line, no update will be done
       by Lilo. But you will get an output that shows what Lilo sees and
       what decisions Lilo makes. When you are satisfied with that, remove
       the "-t".

       All the ?-boot.PR0? scripts are the same but for the changing of "1"
       to "2" and "a-" to "b-" or "d-", depending on what drive is being
       set up. To run the script(s) as root, (after assuring execute permis-
       sion is set):
    
           cd /etc/LiloBootInst/?-boot    # ?=a or b or d
           ./?-boot.PR0n-test             # ?=a or b or d, n=1 or 2

       It is important to keep in mind the difference between the "boot" and
       "root" terms. Boot means the components used by the BIOS to get
       needed parts to find loaders and begin getting the operating system
       going. Root is the Linux file system that will be mounted when the
       kernel has been loaded. It may be on the same or a different
       partition from the "boot" components. Don't get confused.

       In all the below examples, the "bios=" in the "disk=" sections refer
       to the BIOS devices assignments *at_boot_time*, not what they are
       now. Don't get confused by thinking of what the devices assignments
       (0x80, 0x81,...) are now, in your current boot environment. For
       example, if booted off hdb, its assignment is 0x80, hda is 0x81. But
       if I boot from hda, those assignments are reversed. The important
       thing to remember is the assignments at boot-time.

    B) Minimal fall-back, hda (W98 drive) default boot.
       The contents of a-boot.PR01 (edited to remove unimportant things and
       annotated) are as follows. Don't forget to add in any additional
       things you need, like linear or lba32, append="pci=biosirq" or
       "prompt", "delay=100", "timeout=100" and other things you need/want.

       # In the "disk=" sections, "bios=" reflects what the BIOS device
       # assignment (0x80, 0x81, ...) *will* be when BIOS IDE0 (hda, "C:"
       # for you MSers) is default boot. Though not needed here, they are
       # shown for later comparison. Why do I show the geometry here? Be-
       # cause I want Lilo to do its matches on the *real* device geometry,
       # *not* the (possibly) phony geometry contained in the partition
       # tables of the master boot block.

       disk=/dev/hda
           sectors=63
           heads=16
           cylinders=6296
           bios=0x80

       disk=/dev/hdb
           sectors=63
           heads=16
           cylinders=39560
           bios=0x81

       # To reduce error by "loose nut behind the wheel", add a custom menu
       # that shows the boot drive and menu being used. Also, note the cus-
       # tom "map=" parameter. This allows me to back up all boot related
       # information from any drive without stepping on the "map" file from
       # other bootable disk setups. Note that all components are gotten from
       # the liloboot directory. That way, if hdb has failed due to just
       # loss of the /boot directory, I can recover that directory from the
       # W98 directory. Also, Lilo will reference *at boot-time* the needed
       # components in the liloboot directory. So if hdb is not bootable, I
       # can still boot anything else in the system that is still good.
       # IMPORTANT! If you do *anything* that may change physical locations
       # on the drive, RERUN LILO. Lilo is OS independent. It works on phys-
       # ical locations. If you defrag, replace a kernel image or copy some
       # files in/out of the directory, locations may change (usually do).
       # RERUN LILO so it can update the hda1map with the new information.

       menu-title="A Drive Boot Menu PR01"
       boot=/dev/hda

       map=/mnt/hda1/liloboot/hda1map

       install=/mnt/hda1/liloboot/boot.b

       # Default is W98 because it is first in the file and no "-D" on the
       # command line or "default=" in the configuration file was given.
       # Note that the loader is required for W98 because it is not a Linux
       # system. Also, we get it from the liloboot drive, as we do for the
       # Linux stuff.
       other=/dev/hda1
           lable=W98
           loader=/mnt/hda1/liloboot/chain.b

       image=/mnt/hda1/liloboot/K6-20030530
           label=B7-K6-20030530
           root=/dev/hdb7
           read-only

    C) Better fall-back, hda boot, hdb Linux root.
       Contents of a-boot.PR02 (edited to remove some things) are here.
       Since we just add another drive here, and change the default OS we
       run, I've not annotated it. Just take note that we've added parameter
       "default=" and the menu name is changed. As before, don't forget to
       add in any additional things you need.

       disk=/dev/hda
           sectors=63
           heads=16
           cylinders=6296
           bios=0x80

       disk=/dev/hdb
           sectors=63
           heads=16
           cylinders=39560
           bios=0x81

       disk=/dev/hdd
           sectors=63
           heads=15
           cylinders=82714
           bios=0x82

       menu-title="A Drive Boot Menu PR02"

       boot=/dev/hda
       map=/mnt/hda1/liloboot/hda1map
       install=/mnt/hda1/liloboot/boot.b

       default=D7-K6-20030530

       other=/dev/hda1
           label=W98
           loader=/mnt/hda1/liloboot/chain.b

       image=/mnt/hda1/liloboot/K6-20030530
           label=B7-K6-20030530
           root=/dev/hdb7
           read-only

       image=/mnt/hda1/liloboot/K6-20030530
           label=D7-K6-20030530
           root=/dev/hdd7
           read-only

    D) Better fall-back, hdb default boot, bios= changes.
       As before, unrelated stuff is removed. The below is from b-boot.PR02,
       the equivalent of the a-boot.PR02. The significant changes are in the
       "bios=" in the "disk=" sections and new statements in the "other="
       section. As before, a changed boot menu title is used and a "default="
       parameter is used. Annotations have been inserted.

       # Since the BIOS setup has been changed to default-boot IDE1 (hdb),
       # the device assignments (0x80, 0x81, ...) are different than they
       # were when booting from IDE0. It's a "shuffle down" process. So if
       # boot is IDE2, it becomes device 0x80, hda becomes 0x81 and hdb be-
       # comes 0x82. Here we are using IDE1 as default boot, so only the hda
       # and hdb "bios=" parameters are affected. Hdd is still 0x82.

       disk=/dev/hda
           sectors=63
           heads=16
           cylinders=6296
           bios=0x81

       disk=/dev/hdb
           sectors=63
           heads=16
           cylinders=39560
           bios=0x80

       disk=/dev/hdd
           sectors=63
           heads=15
           cylinders=82714
           bios=0x82

       # Now we get all components from hdb because that is considered the
       # "reliable" drive. We could still get things from hda, but we are
       # booting hdb and hda may have failed. If hdb is good, all its
       # components should be considered more reliable than a potentially
       # failed drive (we don't know if drives are good yet, but BIOS may
       # "fail over" under certain failure conditions).

       menu-title="B Drive Boot Menu PR02"
       boot=/dev/hdb
       map=/boot/hdb1map
       install=/boot/boot.b
       default=B7-K6-20030530

       # Look at the "map-drive=" parameters. Since at boot time hdb is now
       # device 0x80 and hda is 0x81, we need to switch them if we want to
       # run W98. These statements reassign hdb to 0x81 and hda to 0x80
       # before loading the W98 stuff, so it will still work. But we still
       # get chain.b from the (currently) known good drive, hdb. If you have
       # shown more than two drives, don't try to "map-drive" more than two
       # in this section. It will make the results unbootable. You can (ap-
       # parently) re-map only two devices. If you have DOS partitions scat-
       # tered among your drives, this may have nasty implications when you
       # boot from other than your normal drive - I don't know.

       other=/dev/hda1
           label=W98
           loader=/boot/chain.b
           map-drive=0x80
               to=0x81
           map-drive=0x81
               to=0x80

       image=/boot/K6-20030530
           label=B7-K6-20030530
           root=/dev/hdb7
           read-only

       image=/boot/K6-20030530
           label=D7-K6-20030530
           root=/dev/hdd7
           read-only

    E) Examples summary.
       I also have hdd boot examples, but they are just extensions of what
       you've seen already. Things to keep in mind are listed here.

       1) Use the "menu-title=" parameter to help protect against
          inadvertently booting the wrong drive. Of course, you must look at
          the menu title for it to do any good.

       2) The "bios=" always refers to the BIOS device assignments
          *at_boot_time*, not what the assignments are now.

       3) The "bios=" parameters change as you change the BIOS boot drive
          sequence(s) in BIOS setup. They "shuffle down". If you have four
          drives and you set BIOS boot to IDE3 (normally 0x83), your dev-
          ice assignments will become like these.

              hdd = 0x80, hda = 0x81, hdb = 0x82, hdc = 0x83

       4) Things which are not bootable are not included in the device
          assignments series 0x80, 0x81, ... So if you have a CD as master
          on the second IDE channel (hdc), it will not affect the device
          assignments with which we are concerned now. You will have 0x80
          and 0x81, but 0x82 will be assigned to hdd, not 0x83.

          NOTE! I haven't yet tested with a bootable CD installed in the CD
          drive. I do know that "El Torito" spec bootable CDs get defined as
          the floppy drive. I have not investigated other boot formats yet.

       5) Store all needed components, and references to them at boot time,
          on the drive the BIOS will successfully boot. That way if the OS
          or partition you are targeting is bad, you can still reference
          other OSs and partitions from the drive that is still good. If your
          normal boot drive fails, or its components get corrupted, you can
          change the BIOS boot device and boot from the other good drives.

X. TESTING and GOTCHAS
    Make sure that all BIOS boot-time needed components occur where your
    BIOS can find them (below cyl 1024 for some old BIOSs). Lilo uses BIOS
    to read several of the early components (see "SOME MORE READING" below).

    The most important testing tools are various type of backups and
    recovery tools that allow recovery from disasters. Have them available
    and well-tested.

    The next most important testing tool is Lilo itself. The -v and -t para-
    meters get information about what Lilo will do and the decisions it
    makes. Examine the output from a Lilo run with the -t parameter (and -v)
    before doing anything that will actually update your boot blocks. Be
    especially alert that you have specified the correct drive(s) and the
    correct locations of components needed at boot time. It is very easy to
    copy configurations and forget to change drive specifications, a "bios="
    parameter or other parameters.

    Copy *at least* the boot blocks of any drive you *might* affect,
    intentionally or accidentally. I usually just get the first track like
    this. Change the ? to the drive specifier and the 63 to whatever.

        dd if=/dev/hd? bs=512 count=63 of=/hd?_1st_track.

    Then if the worst happens, I can recover the original by

        dd of=/dev/hd? if=/hd?_1st_track.

    Watch out for the LFS book bootscripts. They are brain-damaged wrt
    handling detected file system error conditions. For example, when run-
    ning from hdb and with hdd7 mount required by your normal boot, if you
    test by wiping the partition information on hdd, you will no longer be
    able to access hdd and you can't boot into the root on hdb because the
    missing hdd partitions will cause the LFS bootscripts to shutdown your
    machine. Wip out the old recovery diskette (it better be very good).
    Don't ask how I know. Someday I'll submit a fix and see what happens.

    That problem can be circumvented by adding "noauto" to all the fstab
    entries that reference the drive to be "crash tested". If you forget and
    get burned by that "gotcha", you can still copy back the saved first
    blocks (you *did* copy them as shown above, didn't you) and not lose
    anything if you have a bootable recovery floppy.

    Rerun Lilo anytime you change anything in a /boot directory (Linux) or
    defrag a W* partition containing boot components or copy new components
    into/out of the directory containing the boot components. Remember that
    Lilo, being OS independent, is physical-location dependent at boot time.
    These locations are resolved at Lilo boot-block install time (this is
    *not* the same as installing the Lilo package time) and any changes in
    physical location *after* the boot blocks are installed will cause a
    boot failure of some kind (depends on what has been relocated).

    Note that there is no boot flag (partition activation) on my non-M$
    drives. If Lilo is installed into the master boot block, activating a
    partition may provide all sorts of confusion and opportunities for some
    fun. It won't always cause problems, but I have seen certain situations
    where it did. It works fine on my W98 drive (which does have Lilo in the
    master boot record). IIRC, the problem was with two partitions active at
    the same time (an older version of Lilo, or LVM related? - I don't
    recall). BIOS expects the master boot record to take care of situations
    when no partition is "active".

    Don't forget to modify the /etc/fstab on the non-primary drive to boot
    so that it will correctly access things when it is booted/rooted. For
    example, on my hdd root, I change the hdb7 (root file system) entry to
    /mnt/hdb7 and change the hdd7 (/mnt/hdd7) entry to be /. Per a post to
    LFS sometime back (search if you need to know who - I'm too lazy to look
    it up, but I thank them anyway), /rootfs can be used to eliminate one of
    the alterations. I haven't tested this yet.

    Depending on your configuration of root/boot stuff, it may be safer to
    run Lilo in a chroot environment. Use the -r parameter (man Lilo) for
    this. This is most useful when you've installed a whole new LFS into a
    mount partition(s) and want all components to be referenced relative to
    the mounted components. Remember, at boot time the pathnames do not come
    into play. Lilo has resolved them to physical locations. If you change
    the contents of the (relative) /boot in any way, it is safest to RERUN
    LILO.

XI. A PARTIALLY GENERALIZED BOOTBLOCK INSTALL

    This was been tested using lilo 22.{2,5} on a "pure" (B)LFS system,
    *before* it was integrated into this hint and text was changed
    accordingly. So please test carefully and let me know about any
    discrepancies in these instructions that may have crept in during this
    process.

    In the download section of the LFS hints, there is a tarball named
    boot_any_hd.tar.bz2 that contains some supporting prototype scripts
    that you can modify and use to ease maintenance of your multi-boot
    configuration. Its contents will make a directory called boot_any_hd
    that will contain:

        LiloBootInst          : Directory to be moved to /etc/LiloBootInst
            a) lilo.conf-proto: Prototype file used by LBI.sh
            b) LBI.conf       : File for *some* local customization
            c) LBI.sh         : Script to help you install boot blocks

    After making any changes to the files in this directory, copy the whole
    directory to /etc and chown ownership and group to root:root on
    everything, including the directory.

    a) File lilo.conf-proto is a "ptototype" file that is used by LBI.sh
    to automatically "do the right thing" when installing lilo boot blocks
    for a multi-drive boot configuration.  Adjust everything to fit your
    configuration. It is important that the "bios=" values "match" the
    "disk=/dev/hd..." declarations. So "disk=/dev/hda" needs "bios=$HDA"
    and "disk=/dev/hdb" needs "bios=$HDB" and so on. Also, be sure to
    adjust the "sectors", "heads" and "cylinders" parameters to match your
    drive geometries. These three should really be added into the LBI.conf
    file and LBI.sh should have supporting code added. Maybe in a future
    version. Adjust the "prompt", "delay", "timeout" and "lba32" if
    desired.

    In the images sections, adjust the image names (leave the $TBBOOT
    there) and the "label=" values to suit yourself. Remove or change, your
    choice the "default=" parameter.

    The lines beginning with "###### lfs20030504" are markers that the
    shell script uses to tag start/end of code in the generated files. This
    is so that when you run again, it removes lines inside those tags from
    the generated file before adding the new versions in again. The "BEG"
    and "END" lines must match.

    There are other adjustments you will want to make. Use your common
    sense and the "man lilo.conf" pages for additional guidance.

    b) File LBI.conf is a local configuration file. Adjust it for your
    configuration. This really needs more added to it also, along with
    supporting code in LBI.sh. Probably the only changes will be to the
    "DISKS=", and the "HDPFX" and "CONSOLE=" parameters if you use devfs.

    c) Script LBI.sh helps get things right during the grind of daily
    operations. It depends on being able to find the prototype file,
    discused in a) above, and the configuration file mentioned in b).

    To run it, cd to /etc/LiloBootInst and run this command, with the
    substitutions noted in the text following.

        ./LBI.sh {-t|-i} -d X -p N [ -D <default-image-label>

    The "-t" means test only - don't actually install, but do everything
    else. If you give it "-i", the boot blocks will be installed. The "X"
    should be replaced with the drive this run is to affect: a for hda, b
    for hdb, etc. The "N" is replaced by the partition number containing
    the root file system.

    If you provide the "-D" and the label of an image, it will be used as
    the default boot image, overriding any "default=" within the file. If
    there is no "default=" and no "-D ..." is provided, the system will
    generate a "-D ..." for you and tell you that it is doing that. This
    will be the same default as lilo would take.

    For first runs, be sure to use the "-t" parameter, test. It will process
    the prototype file and leave the results in a file named *-boot.conf.
    This is the lilo.conf file that will be referenced by a shell script
    that is also created, *-boot.sh. You can examine and adjust either of
    these files as needed.

    A file, *-boot.out will also be created, using a lilo debug level of v3,
    showing the information lilo garnered and the decisions made. When this
    looks good using the "-t" parameter, you can then remove the "-t" and
    run the *-boot.sh script or rerun LBI.sh and give the "-i" parameter.

    If you provide the "-i", install parameter, the shell will warn you
    that you are going to install the boot blocks and ask if you want to do
    it. Either way, both the "-t" and "-i" leave the *-boot.conf, *-boot.sh
    and *-boot.out files there for you to examine.

    The created shell has a "less" at the end that will page through the
    corresponding *-boot.out file created when the *-boot.sh script is run.

    The output log has a copy of the lilo command that runs.


XII. FOLLOW ONS
    In my real Lilo configuration files, I have removed everything that I
    can specify on the Lilo command line. That, combined with a little shell
    scripting, allows me to have a single configuration file that works with
    installing boot blocks on all three of my drives. The last thing I need
    to add to it is the adjustment of the "bios=" parameters.

    I have a rudimentary script that generates a find with a prune command
    that backs up just my root partition, regardless of what else is
    mounted. With automatic cron invocation at ungodly wee hours of the
    morning, I'm assured of having a reasonably current root backup that I
    can boot and root if needed. BTW, it automatically runs Lilo for the
    backup drive after the backup (not completed yet). If the normal
    boot/root drive gets corrupted, but is still mechanically/electrically
    sound, I can just boot into the backup and do a find|cpio operation or a
    cp -pDr (?) to recover the normal root after doing any *e2fs* operations
    needed.

    Since I have, essentially, 3 copies of my /boot directory, I can recover
    a corrupted boot directory from any of them and RERUN Lilo (very important to
    remember to do this).

    I have yet to implement the reduced service capability of my main
    server. But I have tested the BIOS fail-over capability and it works *if*
    the BIOS can not detect a valid boot block (the signature must be
    missing). Unfortunately, if it sees a valid boot signature and loads
    what it thinks is a good loader, and that loader fails (corrupted boot
    information, kernel or root file system) then no fail-over will occur. I
    have worked on IBM servers that have custom BIOS and hardware monitoring
    and a timer that we were able to use to get around this. If you have one
    of those, there is more that can be done.

XIII. SOME MORE READING
    See the man pages for lilo and lilo.conf.
    Read the README in /usr/src/Lilo*.
    Get to The Linux Documentation Project site (http://www.tldp.org) and
    look at the various things having to do with booting.

XIV. SUPPORT
    All the Lilo error codes are documented in the Lilo README. However,
    they don't necessarily increase your understanding by themselves.
    Additional research in that (and other documents) may be required.

    Post to blfs-support. But, if you have problems and the nature of your
    post indicates that you have not made a good-faith effort to read the
    stuff I mentioned above, I will not reply. Some others on the list may
    be more tolerant.

    This is an early version. I gratefully accept constructive criticism
    posted publicly to blfs-support.
ACKNOWLEDGEMENTS: John McGinn - see "Thanks" in the hint.
CHANGELOG:
   0.9.5 2003-09-08 - Convert to new LFS hints format requirements.
                    - Integrate the semi-automated lilo.conf processing
                      into this hint.
   0.9.4 2003-07-03 - Testing completed with lilo-22.5 ok. Update text.
   0.9.3 2003-06-27 - Correct typo, minor phrasing changes.
   0.9.2 2003-06-14 - Add warning about symlink in liloboot dir in Win*
                      partition. Forgot to mention in earlier versions.
   0.9.1 2003-06-14 - Discovered that Lilo 22.2 doesn't support swapping
                      more than two device assignments in the "other="
                      section of a configuration file. Add a note about it.
                    - Miscellaneous typographical error fixes and a few word-
                      ing changes to increase clarity, hopefully. No
                      substantive changes.
   0.9   2003-06-12 - Initial release