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.
Attachment:
pgp8Dt7n8tTAD.pgp
Description: PGP signature
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
