https://bugzilla.novell.com/show_bug.cgi?id=227377 ------- Comment #19 from andreas.pfaller@gmail.com 2006-12-21 12:59 MST ------- Stefan, you got me confused: I thought the "device (hd0) /dev/sdb" command essential makes grub use /dev/sdb whenever the grub "hd0" specification is used. So the 2nd setup command should install grub on /dev/sdb. At least for my current setup (see below) this works - I have verified that the system is bootable from both disks by temporary removing /dev/sda and for the next try /dev/sdb. I even zeroed the relevant disk sectors and they were restored on both disks by grub (the stage1.5 sectors, see below). Regarding the modification of stage2: Thanks for the hint Stefan, I was not aware of this problem. (Note: I meant stage2 in the last paragraph of my comment #17). Currently I have installed grub with device (hd0) /dev/sda root (hd0,4) setup (hd0) and device (hd0) /dev/sdb root (hd0,4) setup (hd0) and as far as I interpret grubs output this should be safe as this install stage1.5 in the physical sectors (1-15) (i.e. outside of any mirrored partition) and as stage1.5 understands ext2 it should have no problems finding stage2 even if the sectors occupied by stage2 change or are not identical because of different physical positions of the raid component partitions. And as I said above I have verified that it works as expected on my system. Shouldn't YaST enforce something like this automatically as soon as /boot gets installed inside an raid-1 partition? One thing however still make me nervous. Does grub's e2fs_stage1_5 understand all current ext2 features? dir_index may be a problem. A further suggestion: All documentation I found regarding the combination of raid/grub while googling is highly contradicting. It would be nice if SuSE manual would provide some details about this quite common scenario. This leaves the problem with initrd failing to assemble the root device. In hindsight I should have opened a separate bugzilla entry for this. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.