Check your /etc/default/grub, if you use raid 1.

Harald Hoyer harald.hoyer at gmail.com
Tue Jul 31 08:27:17 UTC 2012


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 <mrsam at 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.



More information about the users mailing list