Thanks. On Sat, Mar 7, 2015 at 4:26 PM, Miguel Medalha <miguelmedalha at sapo.pt> wrote:> Assuming your raid group is /dev/md127, you can run: > > ls -l /dev/disk/by-uuid > > or > > blkid /dev/md127 > > and use the ID both will show for /dev/md127 > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >
/etc/fstab needs the UUID for the filesystem volume; so if you use blkid, find the line with the filesystem type and label you used when you created the file system, and use the uuid listed after UUID The grub.cfg should have a boot parameter mduuid which makes mdadm in the initramfs aware that it should assemble the array as soon as it can. It ought to be able to discover what it needs from mdadm metadata 1.x from the member drives, but I'm actually not certain of the role the /etc/mdadm.conf plays or whether it needs to be baked into the initramfs these days. You can use 'systemd-analyze blame' to see if any particular unit file is waiting for either the fs uuid or md uuid to appear. If so I'd probably start with just rebuilding the initramfs with a 'dracut -f'. I'd like to believe on-disk metadata can just be discovered automatically but... Chris Murphy
On Sat, Mar 7, 2015 at 5:23 PM, Chris Murphy <lists at colorremedies.com> wrote:> The grub.cfg should have a boot parameter mduuid which makes mdadm inI'm not sure if grub2-mkconfig will automatically detect and add mduuid to grub.cfg. You can try it. If not then you could add the entry to the extra boot params line in /etc/default/grub and then recreate the grub.cfg with grub2-mkconfig -o... -- Chris Murphy