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?
