On Mon, Apr 13, 2015 at 8:16 PM, Konstantin Olchanski <olcha...@triumf.ca> wrote: > On Mon, Apr 13, 2015 at 07:29:18PM -0400, Nico Kadel-Garcia wrote: >> > I am not sure what you refer to. With SL5 and SL6 you have 2 disks, >> > put "/" on a software RAID1 partitions put grub on both disks ... >> >> Until it fails. Grubby, along with the kernel installlation RPM, >> doesn't know how to update, manage, or keep synchronized this second >> /boot partition. Hilarity can then ensue, along with making sure that >> your /etc/fstab doesn't detect the wrong disk and mount it incorrectly >> as /dev/sda. See, if your first disk dies, unless you're very cautious >> with /etc/fstab, it's very much a crapshoot if hte right partition >> will mount as "/boot". >> >> Been there, done that, gave up on the silliness. >> > > You talk about /boot, /dev/sda, grubby, etc, I doubt you have been there, > done that. Gave up, sure. > > With mirrored disks, there is only /dev/md0 ("/"), /dev/md1 (swap), etc (if > you have /home, /data, etc), > in /etc/fstab, "/" is mounted by UUID of the /dev/md0 RAID1 device, > which in turn is assembled by UUID of component disks using mdadm magic.
Been there, done that. Don't have to make this stuff up, I spent some time *designing* Linux based storage servers, but it was more than 5 years ago. However, software RAID may have improved to the point where "/boot" doesn't have to be its own partition. So I just tried it on a VM runing SL 6.6, and got "unhandled exception", and git it to work flawlessly when I made "/boot" its own, non-RAID partition.. So I'm not filled with confidence that putting /boot on its partition is not still necessary. Are you finding that it actually works? Would you please post an /etc/fstab from a working system to help verify that it works?