Re: Woody+initrd+raid1+boot = :-(
+ George Karaolides <george@karaolides.com> [19.06.02 10:18]:
> Before we go into your message, which kernel version are you using?
kernel-image-2.4.18-686
[bios=0x80]
> When you install an MBR on a disk using lilo, lilo will use the BIOS ID
> currently lilo thinks is currently assigned to the disk. But when you
> select the disk to boot from using the BIOS setup, you will change the
> order of the BIOS disks so that the one you boot from has the first ID
> (0x80); that is how the BIOS selects which disk to boot from first. So if
> you are installing an MBR to a disk you will boot from by selecting it
> with the BIOS setup, you need to tell lilo to use the first BIOS ID
> (0x80).
IC - the disk that is booted by the BIOS always has the ID 0x80, no
matter if it is hda, hdb, hdc or hdd... If I don't tell LILO to change
that internally it would try to boot e.g. from 0x81 which perhaps is
inactive because of a broken raid.
> > I am stuck and booting while simulating a broken secondary IDE
> > controller.
>
> Have you got it all working normally before simulating failures? Can you
> boot into the RAID from either disk, using the BIOS setup to select?
I am not sure if I tried to change the boot-order in BIOS yet (I've
tried many things yesterday :), but will try this afternoon and post it
here.
> > created a new initrd (because the old one still had "failed-disk" in it)
>
> Er, no, the initrd contains kernel modules and possibly user-space
> utilities but there's no way the initrd can actually know about the
> state of the RAID arrays so that couldn't have been it.
The raidtab is read by all raid-tools, isn't it? I guess this is why it
is included on the initrd, since raidstart needs to look up the devices
in it?
[added 0x80 to lilo.conf]
> This also couldn't have been it; the system boots from the installed MBR,
> locates the kernel image and initrd and attempts to boot it, and then
> attempts to mount the correct root device. That is the end of lilo's
> jurisdiction; the fact that /dev/md0 starts when /dev/hda is down
> but doesn't start with /dev/hdc is down must be something to do
> with RAID: the array itself (likely), the way the system starts RAID
> (less likely) or the kernel RAID stuff.
Thats what I am wondering myself about. After Kernel and initrd are
started LILOs job is done.
ATM I think it has something to do with /dev/hda being the
"failed-disks" partitions that the basic installation was done to. But
if I boot with all disks on the raid is okay:
debian:/initrd# cat /proc/mdstat
Personalities : [raid1]
read_ahead 1024 sectors
md0 : active raid1 ide/host0/bus1/target0/lun0/part1[0] ide/host0/bus0/target0/lun0/part1[1]
48064 blocks [2/2] [UU]
md1 : active raid1 ide/host0/bus1/target0/lun0/part3[0] ide/host0/bus0/target0/lun0/part3[1]
4883648 blocks [2/2] [UU]
unused devices: <none>
This behaviour makes me believe, that if hdc fails while the system is
working the raid would fail at all.
I've also tried to remove /dev/hdc and put hda in that slot. This way the
system boots just as if hda got "broken" as described above. I think the
mirror is okay then.
Kinda wierd, eh? (no, not Canadian here ;) - I am going to check the
bios-boot-order and post a new message this afternoon.
Balu
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: