On Mon, Apr 13, 2015 at 8:16 PM, Konstantin Olchanski
<[log in to unmask]> 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?