Boot any OS from any hard drive. - Linux From Scratch by wuyunyi

VIEWS: 5 PAGES: 18

									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

								
To top