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

[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.

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

That doesn't sound right. You might come up using the incorrect raid member, 
but you should come up with two out of sync drives. (Maybe this could happen 
with some non-default setups, where the elements aren't labelled.)

There was a recent bug with raid arrays that could result in some elements 
failing when shutting down. It doesn't directly corrupt the data though. 
There is information about this bug here: 
http://neil.brown.name/blog/20120615073245