LinuxQuestions.org - Grub2, Dual boot and RAID problems

Hi folks,

I have a long-running problem with getting a dual boot system working.

I have four SATA 1Tb hard drives, all plugged directly into the mobo where the BIOS is set to emulate IDE. They are each split into four partitions. 1st – 10 Gb for /, 2nd – 10 Gb for swap, 3rd – 960Gb for /home & 4th – 20 Gb for /opt .
The first three are given over totally to raid5 using md, thus sd[abc]1 make up md1, sd[abc]2 make md2, sd[abc]3 make md3 & sd[abc]4 make md4. They are all labelled, raid_root, raid_swap, raid_home & raid_opt respectively. Debian Wheezy 64 is installed on this RAID5 set with the partitions mounted as described by the labels. Grub2 is the bootloader and is installed to the MBR of the first drive. This system boots and runs okay.

The fourth hard drive is identically partitioned with the labelling s_root, s_swap, s_home & s_opt. I would have liked to use drive this as part of the main systems raid but as Wheezy is pretty rubbish for gaming I have kept this drive for a Vector 6.0 (based on Slackware 12) installation. I would like to be able to dual boot this using the grub2 from the main system.

However, I ran into problems trying to install any system onto this fourth drive, I did try several distros with varying results but little luck. Eventually I unplugged the first three drives and installed Vector 6.0 with no trouble at all. This used LILO, the conf file is shown below.
boot = /dev/sda
prompt
timeout = 50
bitmap=/boot/bitmap/boot.bmp
change-rules
# lba32
reset
vga = 791
default=Vector_GUI

# Vector_GUI
image = /boot/vmlinuz
initrd= /boot/initrd
label = Vector_GUI
root = /dev/disk/by-label/s_root
append="4 "
read-only

# Vector Text
image = /boot/vmlinuz
initrd = /boot/initrd
label = Vector_TUI
root = /dev/disk/by-label/s_root
append = "2 nosplash"
read-only
You will note that nowhere have I referred to any partition except by use of the label. The only use of a device name is in the 'boot=' where I could see no alternative & believe that this is only used by lilo during installation & should have no effect thereafter, is this correct? As this stood, with the first three drives unplugged, the system behaves beautifully.

I then plugged the other drives back in and, on booting into Debian, added the new system to GRUB. Initially I tried letting GRUB work it out using os-prober which created
menuentry "Slackware Linux (Slackware 12.1.0) (on /dev/sdh1)" --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(/dev/sdh,msdos1)'
linux /boot/vmlinuz root=/dev/sdh1
initrd /boot/initrd
}
but this resulted in GRUB throwing up 'error: no such disc' when executing the 'linux /boot/....' line. Using the GRUB editor I have tried all sda[a..z] drive options, all give the same error.

So I added Vector manually to GRUBs 40_custom file. I have tried several variations over the past weeks but it currently stands as shown below. This appears to perform correctly but I cannot be sure.
menuentry "Vector_GUI (on 4th HD)" --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
# set root='(hd3,msdos1)' /*Now covered by 'search line'.*/
search --label --set root s_root
echo "Loading Vector vmlinuz ......."
linux /boot/vmlinuz root=/dev/disk/by-label/s_root ro vga=793 quiet nomodeset
echo "Loading Vector initrd ....."
initrd /boot/initrd
}
I'm not too hot on GRUB, does this appear correct?

On booting GRUB appears to pass control to the Vector boot process correctly, however I cannot confirm this. Immediately after the linux kernel (or initrd) starts it reports
pci 0000.00.00.0 bar 3: can't allocate resources
ata1: softreset failed (device not ready)
ata2: softreset failed (device not ready)
ata3: softreset failed (device not ready)
ata4: softreset failed (device not ready)
md: invalid raid superblock magic on sda1
md: invalid raid superblock magic on sda2
md: invalid raid superblock magic on sda3
md: invalid raid superblock magic on sda4
md: invalid raid superblock magic on sdb1
md: invalid raid superblock magic on sdb2
md: invalid raid superblock magic on sdb3
md: invalid raid superblock magic on sdb4
md: invalid raid superblock magic on sdc1
md: invalid raid superblock magic on sdc2
md: invalid raid superblock magic on sdc3
md: invalid raid superblock magic on sdd4
kernel panic – not syncing VFS: Unable to mount root fs on unknown block (0,0)

Why is it trying to access the RAID? I would like to use the same home partition later but at this point these drives are totally irrelevant to Vector. Vector uses 2.6.27.29 while Wheezy uses 3.2.0-4-amd64. Possibly, the softreset errors indicate that a version 3 kernel may be running as this is something I often see post 3.0 but not with older versions? Is there a way to check which kernel and partition are active here?

With all four drives in, and telling the BIOS to boot from the fourth drive, Vector get much further before again 'panic'ing with 'kernel panic – not syncing VFS: Unable to mount root fs on unknown block (8,0)'. The text scrolls far too fast to see how far the boot gets but it appears to be trying to use an invalid partition for /. Immediately prior to the panic it lists all partitions just after appearing to try and identify the fs type on sda1. I have looked into /var/log/ on s_root but there is no record of the failed boots.

My fstab for Vector is:-
LABEL=s_root / ext2 defaults 1 1
LABEL=s_swap none swap sw 0 0
LABEL=s_home /home ext3 defaults 1 2
LABEL=s_opt /opt ext3 defaults 1 2
devpts /dev/pts devpts gid=5,mode=620 0 0
proc /proc proc defaults 0 0
This works perfectly when this is the only drive installed. In this situation the system identifies the drive as sda while Debian, with a four drive setup identifies it as sdh. However, I believe have used labels throughout. In order to check this I have 'cd'ed into Vector /etc and run 'grep -r sda1 ./*', the only instances of this string are in commented out & replaced lines.

So, at the moment the only way I can use any 32bit software with a heavy graphics demand (specifically X3: Reunion) is to dismantle the case and unplug the first three drives, very much a highly undesirable solution. Can anyone help?