Andreas M. Kirchwitz writes:
Basically the same problem has been reported by Sam Varshavchik in <cone.1323864504.969555.2535.1000@xxxxxxxxxxxxxxxxxxxxxx> but there wasn't a final solution.
Yup. But I did find a final solution, eventually.Take a survey of all your mdraid UUIDs. Reconcile it against your /etc/default/grub. GRUB_CMDLINE_LINUX should include rd.md.uuid={UUID} for all mdraid UUIDs. Add the missing ones there. Rerun /sbin/grub2-mkconfig to rebuild grub.cfg, updating the command line used to boot all installed kernels, and making sure that kernel upgrades get the updated command line from /etc/default/grub.
From what I've been able to figure out, it seems like there were actually
two ways for mdraid arrays to get started.• The mdraid UUIDs can be passed on the kernel boot command line. grub2- mkconfig is responsible for building the kernel boot command line, and setting up grub.cfg. The kernel finds the mdraid UUIDs listed on its command line, and starts the arrays.
• The mdraid UUIds are also enumerated in /etc/mdadm.conf, which finds its way into initramfs. Even if the UUIDs were not listed on the boot command line and the arrays don't get started by the kernel itself, the mdraid_start script in initramfs should start them anyway.
It appears that mdraid_start in initramfs is not reliable. I didn't bother wasting time trying to figure out what's broken in that short script, because after fixing the grub command line, so that the kernel itself brings up all the arrays itself, I never had any further raid start failures at boot time.
Attachment:
pgpyj5FICZrGZ.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
