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

[Sam Varshavchik]

Bruno Wolff III writes:

> On Sun, Jul 29, 2012 at 10:42:26 -0400,
>   Sam Varshavchik <mrsam at courier-mta.com> wrote:
>>
>> All I know is in F16 I discovered that a raid 1 volume whose uuid does not  
>> get enumerated in the rd.md.uuid kernel boot parameters will come up with  
>> one drive not in the array, maybe 5% of the time. I wasn't the only one  
>> affected, there was another list member that reported the same bug, and that  
>> putting the uuid back into grub.cfg and /etc/default/grub fixed it.
>
>> That, I think is a bug. Failing a drive should zero its superblock, to force  
>> a real resync if it gets added back to the array.
>
> Do you know if there are bug tracker entries for either of these bugs?
>
> I'm interesting in following them.

Not clearing the superblock when a drive fails is something that I just ran  
into. This one should probably be discussed upstream.

I think I remember seeing someone reporting the array assembly bug when it's  
not enumerated in rd.md.uuid, but I can't find the bug right now.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20120729/b7a4f963/attachment-0001.sig>