I'm running Centos 7. Originally, it was running on a single disk that looked something like this:
1 200M EFI System (/boot/efi) 2 500M Microsoft basic (/boot) 3 465.1G Linux LVM LVM VG centos - LVM LV ext4 centos-root (/) - LVM LV swap centos-swap (swap)
This was just a temporary solution as it was originally supposed to be installed on a Linux software RAID1 array. I got around to migrating it today. This is what it currently looks like:
Both new disks have this partition layout: 1 200M EFI System (/boot/efi) 2 457.6G Linux RAID /dev/md0 RAID1 (for boot and LVM) 3 8G Linux RAID /dev/md1 RAID0 (so 16GB total, for swap) /dev/md0 looks like this: 1 500M Linux filesystem (/boot) 2 457G Linux LVM (centos-root is migrated to this) LVM now has only one LV, centos-root
/etc/mdadm.conf looks like this:
ARRAY /dev/md0 level=raid1 num-devices=2 metadata=1.2 name=main.centos.local:0 UUID=5b5057b4:4235ba4b:5342dfda:acf63302 devices=/dev/sda2,/dev/sdb2 ARRAY /dev/md1 level=raid0 num-devices=2 metadata=1.2 name=main.centos.local:1 UUID=f82a8c99:9b391d83:4efc9456:9e9bad98 devices=/dev/sda3,/dev/sdb3
/etc/fstab looks like this:
/dev/mapper/centos-root / xfs defaults 0 0 UUID=fcb5f82f-ce6b-460b-800f-329e010bc403 /boot xfs defaults 0 0 UUID=C532-14AE /boot/efi vfat umask=0077,shortname=winnt 0 0 /dev/md1 swap swap defaults 0 0
blkid outputs this (relevant entries only):
/dev/sdb1: SEC_TYPE="msdos" UUID="C532-14AE" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="ed301bbd-c15c-40af-ae75-bf238d0e6270" /dev/sda1: SEC_TYPE="msdos" UUID="C532-14AE" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="f3a76412-41a0-4e04-9b04-ad1c159133cf" /dev/md0p1: LABEL="boot" UUID="fcb5f82f-ce6b-460b-800f-329e010bc403" TYPE="xfs" PARTLABEL="primary" PARTUUID="df8d6481-c6ce-423a-b5d5-205d355e5653" /dev/md0p2: UUID="7LfywM-oPHy-MTEt-swlI-EVbZ-opTo-m82E6R" TYPE="LVM2_member" PARTLABEL="primary" PARTUUID="19e7f9d5-a955-4036-8338-03a748faa1f6" /dev/mapper/centos-root: UUID="deaa9788-b487-4991-adf7-2945788fb6cd" TYPE="xfs"
I have a script which automatically mounts the other EFI partition to
/boot/efi_[device], and when the kernel is updated, the grub.cfg gets copied to this partition to keep everything in sync.
/dev/sdb1 are kept in sync by the script (I've verified this), so it shouldn't be an issue that fstab mounts either one to
/boot/efi (this also means that if one drive was removed due to failure, the system is still guaranteed to boot). I could have put swap in a LV to simplify things, but the RAID0 gets better performance (for what it's worth) and I get an extra 16GB of space.
I migrated the LV from the old drive to the new PV using the following commands:
pvcreate /dev/md0p2 vgextend centos /dev/md0p2 pvmove /dev/sdg3 vgreduce centos /dev/sdg3
Then I regenerated the initramfs with
dracut (after backing up the original), and finally regenerated grub.cfg. Afterwards, I mounted the new
/boot/efi partitions and copied everything over.
After disconnecting the old drive and booting, dracut fails to find my RAID arrays, and of course the
/boot partition and my LVG as well. It appears that it's simply not calling
mdadm --assemble on
/dev/md. I'm able to do just that from the
dracut prompt, after which
lvm_scan finds my LVG, I can link
/dev/root, and the system continues booting without any problems once exiting the prompt. Everything seems to be exactly where it should be.
There was a kernel update available, so I tried installing it (assuming I messed something up the first time around when regenerating the initramfs and grub.cfg files), but no dice. System still fails in the exact same way. This is true when I boot from either EFI partition manually (as it should be since the two are identical).
What am I missing here? How do I get dracut to assemble my arrays?