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

[Sam Varshavchik]

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.

There's probably a third bug in here: mdmonitor should've mailed me when an  
array came up degraded at boot (I suspect that because mdmonitor gets  
started so early in the boot process, not all the moving pieces are there  
for mail delivery to happen). Eventually, you'll boot again with both drives  
in the array somehow, except they'll be out of sync, resulting in massive  
corruption. If you're lucky, you'll boot just with the other drive, and  
discover that your filesystem's contents are weeks/months out of date, and  
maybe you'll be lucky enough to figure out what happen, and switch back to  
the other drive and resync. But, not everyone's so lucky.

This first started happening in F16. It took me a while to figure out the  
cause for an occasionally raid assembly failure at boot. Fixed it, and  
forgot about it. Well, looks like the F17 anaconda brought back the broken  
/etc/default/grub, which found its way into my grub.cfg, and I just lost a  
full day, cleaning up this mess.

So, if you use raid 1 and upgraded to F17, you may need to fix this before  
it's too late: put back the missing uuid into /etc/default/grub, and into  
every entry in grub.cfg

Pissed.

-------------- 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/b2cf4d20/attachment.sig>