+ George Karaolides <[EMAIL PROTECTED]> [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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]