readme.raid1

LINUX lilo-22.7 源代码。

  raid-extra-boot = "/dev/hdc,/dev/sda"

Now both disks in the RAID set have usable boot records on the MBRs. 
There is no need to worry about "active" partitions in a recovery
situation.


BACKWARD COMPATIBLITY
=====================

Backward compatibility with earlier versions of LILO raid is provided
by (versions 21 through 21.7.5)

   raid-extra-boot = mbr-only

Use of "mbr-only" defeats writing the boot record to the RAID
partition, '/dev/md1' in the examples above, defeats the protection
against writing to the MBR of BIOS device 0x80 (which is usually
'/dev/hda' or '/dev/sda'), and writes to all MBRs of the drives in
the RAID set.  Except for not writing to the boot record of the 
raid partition, this option is otherwise the same as the "raid-
extra-boot=mbr" specification discussed above.

On XFS filesystems, writing a boot record to the RAID partition itself
would be catastrophic.  Hence, on XFS filesystems, use of this option
is MANDATORY.


MASTER BOOT RECORDS and ACTIVE PRIMARY PARTITIONS
=================================================

The active partition, /dev/sda1 in the case above is booted by a
"Master Boot Record" written to /dev/sda.   LILO may be requested
to write such a Master record with the command:

   lilo -M /dev/sda     # write master boot record

The Master Boot Record performs the same function as the DOS utility
'fdisk /mbr', except that the DOS code is only used for the C: drive. 
The LILO master boot record facility may be placed on sector 0 of
any drive.  It serves an additional function in RAID1 installations,
in that it will determine, and pass to the boot sector of the active
partition the correct BIOS device code of the drive, whether it is
0x80, 0x81, or higher.

The active partition may be set with the -A flag; viz.,

   lilo -A /dev/sda 1   # note the space!!!

or checked; viz.,

   lilo -A /dev/sda     # check active partition

(response:  /dev/sda1)


REMINDERS
=========

Unstated, but required by an installation of LILO to a RAID
partition, all of the files used in booting must reside on the RAID
set.  This means:  initrd, kernel, and message files; plus the LILO
internal files:  map, boot.b, and chain.b, if used.  Normally, the
internal files are kept in the '/boot' directory.  Many distributions
of Linux also place the kernel and initrd files in this same
directory.  Others place them in the root, '/', directory.  Either
location is acceptable, as long as they are within the same RAID
partition which you are making bootable.

LILO variations:  version 22.2 enforces the placement of the map file
on the RAID parition.  Version 22.3 eliminates the need for the
boot.b and chain.b files, and relaxes the restriction that the
message file be on the RAID partition by copying it into the map
file.  Likewise, any bitmap= file is copied into the map file, so it
too may reside anywhere.  It remains the user's responsibility to see
that the Kernel and Initrd files are on the bootable raid partition. 
The /boot directory, with the map file, is the recommended location for
these files.

If for some reason you want to write the MBR of BIOS device 0x80, you
will have to specify it explicitly.  Since LILO tells you where all
other auxiliary boot records have been written, if any, you will have
to mention these in addition to the MBR on drive 0x80.

(versions 22.0 through 22.4.1):
When making an installation of LILO to a RAID set, remember that LILO
will only make the disk with the lowest device code bootable.  For
very many RAID installations, this will be BIOS device code 0x80. 
The second and succeeding disks in the RAID set are not bootable in
the running RAID configuration; they only become bootable if the disk
on device code 0x80 is removed, so that one of them becomes BIOS
drive 0x80.


ERROR MESSAGES (versions 22.0 through 22.4.1):
==============

If LILO is unable to write all of the auxiliary boot records it would
like, or your map file is not on the RAID partition, you will get the 
error message:

  "Warning: FLAG_RAID_NOWRITE has been set"

This warning has two consequences.  First, the clearing the '-R'
stored command line will not take place; 'lock' will not work
properly; and 'fallback' will not work properly.  All of these LILO
options require LILO to re-write the stored boot command line before
the kernel is booted.  Because RAID set consistency cannot be
maintained, the boot loader will fall back to a read-only mode of
operation.  For many installations this is acceptable.  The command
line switch, '-R' will still work from a running system, since the
kernel RAID codes will maintain set coherency.

The second consequence of this message, is a warning that not all
boot records needed for booting in a disk failure scenario were
written.  The system may boot fine with the lowest BIOS code disk
running, but be prepared to use a boot floppy in the event this disk
fails.  This may or may not be acceptable.

This message will most often appear when 'raid-extra-boot=' was
specified as "none"; or, if specified as (or defaulted to), "auto",
the extra boot record it could not write was to the MBR of BIOS
device 0x80, usually '/dev/hda' or '/dev/sda'.  This could happen
with a skewed installation, where the RAID set partition on BIOS
device code 0x80 is not a primary partition.  If it were a primary
partition, then the RAID partition boot record written to '/dev/md?'
would be used, and there would be no necessity to write to the MBR of
BIOS disk 0x80.


NEW CONSIDERATIONS        (version 22.5 and later)
==================

Booting is now based upon a 32-bit industry standard Volume ID,
rather than the 8-bit BIOS device code.  Device codes are still
generated, but are used primarily as an index into a volume id table. 
This means that the LILO-installed boot sector must contain the
volume id of the drive containing the map file, since this is where
the second stage loader is guaranteed to be located.  The record on
the first sector of a RAID1 partition is not unique, but is shared
among all the partitions in the raid set.  These partitions span two
or more drives.  

The worst case scenario is that the boot scheme falls back to actual
device codes, and is as reliable as the version 22.4.1 and earlier
codes.  A failed installation will still boot, as long a the failed
(first) drive is removed, and the backup (second) drive fills the
emptied BIOS device code slot formerly occupied by the failed drive.

Version 22.5 (and later) installations are more robust, as long as
the boot record on the RAID1 partition has access to the BIOS device
code under which it is booting; or, booting takes place from an
auxiliary boot record installed using the option "mbr"; or by
explicit declaration.  Auxiliary boot records are not shared across
drives, so they may have variations within them, such as their own
unique volume id's, for use in accessing the correct map file.  (They
also contain unique offset information, in the case of skewed
partitions.)

The most fault tolerant systems will be those installed using the
"mbr" (or "mbr-only") specification.


CONSERVATIVE INSTALLATION    (version 22.5.1 and later)
=========================

The most robust RAID1 installations, PARALLEL or SKEWED, are installed
with:

   lilo -x mbr

This installation will boot any disk with a RAID partition on any
BIOS device code. It is not restricted to PARALLEL installations only
as is the next method.

Equally robust PARALLEL installations will use the new Master Boot
Record, activate the RAID1 partition on each drive, and install using
the specification that the MBR bios can be relied upon to pass the
correct BIOS device code in the DL register:

   lilo -x auto
     or
   lilo -x none

will produce a warning message telling you that the following is needed:

   lilo -M /dev/sda	# install new MBR
   lilo -A /dev/sda 3	# activate the correct partition (# 3)
   lilo -M /dev/sdb	# install new MBR
   lilo -A /dev/sdb 2   # activate the correct partition (# 2)

If the partitions of the PARALLEL installation are not all primary, the
warning message will not be issued, and non-primary partitions will not
be bootable.  (The MBR from LILO version 22.5.1 or later MUST be used.
Once installed, it does not have to be re-installed each time you update
the boot record on the RAID partition.)

Since it is easier to achieve the most robust state of affairs with
the "-x mbr" or "raid-extra-boot=mbr" specification, it is the
suggested method of installation.


REMEMBER
========

With a RAID installation, always run:

   lilo -t

first -- just to let LILO tell you what it is about to do.  Use the
'-v' flag, too, for more verbose output.


REFERENCES
==========

The 'man' pages for "lilo" and "lilo.conf" have been updated, and are
the main reference material for using the new switches and config
options.

The 'README' file in the LILO source directory, generated from the
doc materials, is still the best tutorial on booting, as well as a good
reference for many of the more obscure lilo options.  The 'man' pages
now contain most of this reference material, but in a condensed form.


CREDITS
=======

Thanks to Piete Brooks <[e-mail]> for prodding me
into attacking the RAID1 issues, for his incisive criticism of the
resulting work as it emerged, and for testing the early codes.

(end)
written 04/19/01 -- John Coffman <[e-mail]>
updated 05/10/01 -- John Coffman
updated 08/08/01 -- John Coffman
updated 03/15/03 -- John Coffman (to version 22.5.1)
updated 09/07/04 -- John Coffman (spelling & punctuation)