Am 29.07.2012 16:25, schrieb Reindl Harald: > > > Am 29.07.2012 16:19, schrieb Bruno Wolff III: >> On Sun, Jul 29, 2012 at 10:02:00 -0400, >> Sam Varshavchik <mr...@courier-mta.com> wrote: >>> There's a long standing combination of two bugs: the list of rd.md.uuid >>> boot parameters generated by anaconda for >>> /etc/default/grub may not include the raid uuid of non-stock partitions >>> like /home; and although the ramfs >>> initscript autodiscovers all raid volumes present, sometimes (not always, >>> I'll estimate 5% of the time) if a uuid >>> is not enumerated in the boot parameters, one of the drives in the raid 1 >>> volume may not get assembled at boot. >> >> My raid info is /etc/mdadm.conf and that is what gets used by dracut when >> building an initramfs as far as I can tell. > > > in theory > > sam is right and the problem exists since F16 > > you have to add all your UUIDs from /etc/mdadm.conf with MD_UUID=<youruuid> > entries to the kernel line or you are randomly boot with degrared arrays > > it does not help to have the driver in initramfs if the arrays are not s > tarted correct, it must also be used properly from the system > > maybe tehre are people affected even not recognize their degraded arrays > until it is too late >
I would consider it a dracut bug, if rd.md.uuid is specified and other raid arrays are assembled in the initramfs. -- users mailing list users@lists.fedoraproject.org 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
