what you mention is not possible for the reasons i outlined on non-raid1.
under raid 5- the /boot directory inside the root partition does not exist
on everydisk. it is striped across multiple disks with a parity stripe on
one. lilo would have to pull blocks from different disks, and if one was
missing, it would have to use the parity stripe to re-generate the missing
data. to difficult, and prone to one major failure: suppose the mbr on all
disks points to the map file using CHS addresses. this means that all
disks that lilo needs must be accessable by the bios. (inside 1024 disk
limit, on first two disks) the first chs address for the start of the map
is on disk one, disk one dies. lilo never loads anything, cause it never
starts.
you must get the kernel into ram another way. i use floppies or 20meg
/boot partitions on each disk, with a multi- lilo setup.
al
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera
On Fri, 5 Feb 1999, A James Lewis wrote:
>
> Lilo being raid1 capable would be cool, it would be simple enough to have
> a 10 meg mirror to have /boot on.... then / could be mounted from a raid5
> or somthing... might even be cool to have the mirror across each disk in
> the raid5 then you could guarantee it would find one and boot no matter
> which disk had died! Mirroring the physical device (Rather than
> partition) might also allow the lilo information to be mirrored
> better....) but then if lilo were raid1 aware then this should not be a
> problem... it should write a book block to all appropriate devices!
>
> What's the likleyhood of this happening? I guess one could stop the
> mirror and run lilo against one of the devices... but that's less than
> ideal to say the least!
>
> Also, I have not had a chance to test over multiple disks... but my
> tests have demonstrated some good stability overall... I would love to
> know when this will be concidered stable enough for merging with 2.3 or
> even 2.2??? One thing I have noticed is that there are a few ways to
> crash the raid code... try to init a mirror with only one disk... the
> kernel daemon crashes and estimates an infinite amount of time to
> reconstruct... you cannot then raidstop or sync or reboot!... This can
> also be achieved (somtimes) by modifying a partition table on a disk that
> has raid active on it.... even if you don't touch the raid paritions....
>
> Unfortunately I don't have the skills to help debug this, but it's the
> only problem I can identify....
>
> On Thu, 4 Feb 1999, m. allan noah wrote:
>
> > ok- the main point with booting is thus- with the new raid code, you can
> > start raid from the kernel without any utils on the disk. meaning, all you
> > have to do is get the kernel into ram, and jump to its starting address.
> >
> > this is what lilo is for, along with loadlin, etc.
> > they are needed cause the kernel, and esp. multiple kernels cant fit into
> > the MBR on the disk. so the mbr contains basically the CHS or linear
> > addresses of where the map file is, and thus the kernels. (simplified to
> > the point of incorrectness)
> >
> > under RH, these all live in /boot, which is usually in the / partition.
> > you have a couple choices.
> >
> > 1. mkbootdisk. works well, i use it on some. makes setup simple, no
> > non-raid partitions, no multi-lilo.conf setups. but, it is the floppy, and
> > they suck for HA. (of course if ha is your deal, you have multiple
> > machines or multiple hardware raid adapters, etc)
> >
> > 2. small partitions at start of disk (within first 1024 Cyl) marked
> > bootable, mounted as /boot /boot1, etc. this requires some fooling with
> > lilo, etc, i used this on my latest box, works well (have floppy as
> > backup)
> >
> > 3. modify lilo to understand raid. this would be non-trivial for all
> > personalities except for raid1, as the actual kernel in those situations
> > will be split across disks, requiring lilo to know how to read the raid
> > superblocks, which is sometimes difficult, cause the superblock is at the
> > end of the disk, outside of the bios 1024 cyl range lilo has to use.
> > i had this working accidentally once. i setup lilo, somehow created an
> > array (raid1) using the root disk, without disturbing the data. the
> > kernels were
> > in the same CHS locations, and lilo still ran, even though it was a raid
> > partition. was impossible i thought, but neat! till i ran lilo again and
> > it bitched, could not upgrade!
> >
> > the lilo option seems doable for raid1. hardware solutions are also
> > feasable, but non-trivial
> >
> > al
> >
> > "so don't tell us it can't be done, putting down what you don't know.
> > money isn't our god, integrity will free our souls" - Max Cavalera
> >
> >
> >
>
> James ([EMAIL PROTECTED])
> My operating system unders~1 long filena~1, and yours?
>
>
