F16 - Converting to RAID1

[Sam Varshavchik]

Brian Hanks writes:

> 1.  Umount the two RAID devices with a current copy of data.
> 2.  Edit /etc/fstab replacing Device IDs with new RAID devices
> (UUID=???? becomes /dev/md?)

Although you can, /etc/fstab should still refer to filesystem UUIDs. If  
you're switch partitions, /etc/fstab will simply need to refer to the  
correct filesystem, by its uuid. As long as the md arrays get assembled  
properly, and contain a usable filesystem, select the filesystem by UUID.

> 3.  Make backup of /boot/grub2/grub.cfg
> 4.  Make backup of /boot/initramfs-$(uname -r).x86_64.img
> 5.  dracut --force initramfs-$(uname -r).img $(uname -r)

My favorite trick is run plymouth-set-default-theme with the --rebuild- 
initrd flag, that causes the current kernel's initramfs to get rebuilt.  
Right now, plymouth has a bug where it adds a redundant grub menu entry each  
time you run it, which will need to be manually dropped, and in your case it  
wouldn't matter because you're about to run grub2-mkconfig anyway.

> 6.  grub2-mkconfig -o /boot/grub2/grub.cfg
> 7.  I don't think I need to install grub2 on the new drive because
> that's already on the SSD primary drive.

Correct. grub2 only needs to be installed on the boot drive.

> 8.  Do I need to remove the "rd.md=0" from /etc/default/grub?  Or will
> grub-2-mkconfig fix this?

No, grub2-mkconfig won't fix it, and you will need to do it yourself.

Additionally, it's necessary to add the boot parameters

rd.md.uuid={uuid}

to the kernel boot line, for every mdraid device, where {uuid} is the MD  
uuid, not the filesystem uuid. That's the uuid reported by mdadm --detail  
/dev/mdN

Although it's been my experience that mdraid volumes usually still get  
assembled at system boot time even in the absence of an explicit rd.md.uuid  
boot parameter, the problem is the "usually" part, and I've had persistent  
problems with one of the RAID-1 volumes inexpicably coming up degraded,  
after a reboot, with one of the devices missing, forcing me to add it  
manually, and then wait for the array to resync.

This got old very quickly, and I just didn't want to waste time any more  
figuring out what's broken in initscripts, plus, without an explicit  
declaration the undeclared RAID volumes were getting assigned a high minor  
device number, like /dev/md127, rather than an expected low number. Which  
was a little bit of an eyesore, but after I figured out that my problem was  
the missing boot parameter, and added an explicit boot parameter for the  
partition, the problem went away, and the array was assigned a reasonable,  
low /dev/md minor device number.

The end result is that the boot parameters will get the arrays built at the  
system boot, by their MD uuids first, then mount can find their filesystem  
uuids, and mount them.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20120101/fc25ecdc/attachment.sig>