It worked now after I re-build the initrd image with e following command:
mkinitrd --with=raid1 -f /boot/initrd-2.2.5-22.img 2.2.5-22
Now I want to move the root to the new raid device (/dev/md0). When rebooting, it
stopped at
LI
Here is the configuration:
1) Two disks with 4Gb of each.
2) /dev/sda1 1.5GB (raid1 as /)
3) /dev/sda2 100MB (boot device)
4) /dev/sda3 200MB (swap)
5) /dev/sdb1 1.5GB (raid1 as /)
5) /dev/sdb2 100MB (boot device)
7) /dev/sdb3 200MB (swap)
8) /etc/lilo.conf:
boot=/dev/sda2
map=/boot/map
install=/boot/boot.b
prompt
linear
timeout=50
image=/boot/vmlinuz-2.2.5-22
label=linux
root=/dev/md0
initrd=/boot/initrd-2.2.5-22.img
read-only
9) run lilo -U and lilo -v, then reboot
Thanks in advance.
JW
-----Original Message-----
From: James Manning [SMTP:[EMAIL PROTECTED]]
Sent: Monday, May 29, 2000 4:21 PM
To: Gregory Leblanc
Cc: [EMAIL PROTECTED]
Subject: Re: HELP with autodetection on booting
[Gregory Leblanc]
> I started seeing this when I blew away my RAID0 arrays and put RAID1 arrays
> on my home machine. I suspect that this is cause by RedHat putting
> something in the initscripts to start the RAID arrays AND the RAID slices
> being set to type fd (RAID autodetect), but I haven't been able to confirm
> this. And since I just totaled my RH install, it may be a couple of weeks
> before I get back to look some more.
Just to confirm :)
/etc/rc.d/rc.sysinit will attempt to activate any /etc/raidtab entries
that aren't listed as active already in /proc/mdstat. This can certainly
be a nuisance in some cases, but I guess they feel it works well in
most cases (and they may be right). Certainly can cut down the need for
partition types of "fd", although it would appear to be more important to
keep your raidtab aligned with reality (although that's a good practice
anyway since we may need it for recovery later on).
James
