Letting the chips fall where they may, I quote Randy Johnson:
>RAIDTAB
>
># raiddev configuration file
>
>raiddev /dev/md0
>raid-level0
>nr-raid-disks 4
>nr-spare-disks0
>chunk-size8
>
>device/dev/sda1
somone asked for something like this earlier
i applied both devfs and raid patchs to a recent kernel tree
you can try fetching this patch from:
http://www.comedia.it/bluca/linux-2.1.131-ac13+devfs-v81+raid0145-19981215.fix.gz
to apply:
untar kernel
apply alan's patch
find . -name \*.rej -exec r
a couple of notes
the problem with lilo is not the root device, but the device where the
kernel is stored, so if kernel is /boot/vmlinux and /boot is (say /dev/sda1)
you don't need changing real-root-dev in initrd, just tell lilo:
root=/dev/md0
and it wil work OK.
i tried to hack lilo to support
Hi,
> Sorry, don't know how to handle device 0x0900 (i.e. /dev/md0)
The bios device addresses are _completely_ different that the linux device
numbers. The bios device addresses exist before the kernel has been loaded
into memory and any of the md code _could_ even run. The bios device
addresses
I've hacked together an archive of the mailing list, it's initially
filled with the posts left in my mail folders. It will get better in
a few weeks, as I'll stop deleting posts of no interest to me. It
could be useful, if new list members had a way of finding it...(then
of course, there is the
At 17:44 19.12.98 -0500, you wrote:
>Martin Bene wrote:
>> I'm not too happy with this double-lilo setup I'm currently using - is
>> there any way to make the boot process more transparent while still
>> retaining the ability to start from either drive?
>
>Yes! Lilo allows you to do this nicely. I
