Re: Check your /etc/default/grub, if you use raid 1.
Bruno Wolff III writes:
On Sun, Jul 29, 2012 at 10:02:00 -0400, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> 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.
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.
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.)
According to mdadm --detail, I have a "Name" label on it.All I know is that I spent half a day wondering why, every time I fscked this partition I found more crap. The other half of the day was spent resyncing the volume, after I figured out that the drives were not synced.
And, fail/remove/add did not resync the drive. Because the volume uses an internal bitmap: oh, the newly-added drive has a valid bitmap, apparently from the same volume, so let's add this drive without resyncing 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.
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
Since F17 is on 3.4, and this seems to indicate that only some 3.2 and 3.3 kernels might have an issue, doesn't look like this is related.
Description: PGP signature
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx 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
[Older Fedora Users] [Fedora Announce] [Fedora Package Announce] [EPEL Announce] [Fedora News] [Fedora Cloud] [Fedora Advisory Board] [Fedora Education] [Fedora Security] [Fedora Scitech] [Fedora Robotics] [Fedora Maintainers] [Fedora Infrastructure] [Fedora Websites] [Anaconda Devel] [Fedora Devel Java] [Fedora Legacy] [Fedora Desktop] [Fedora Fonts] [ATA RAID] [Fedora Marketing] [Fedora Management Tools] [Fedora Mentors] [SSH] [Find Someone Special] [Fedora Package Review] [Fedora R Devel] [Fedora PHP Devel] [Kickstart] [Fedora Music] [Fedora Packaging] [Centos] [Fedora SELinux] [Fedora Legal] [Fedora Kernel] [Fedora QA] [Fedora Triage] [Fedora OCaml] [Coolkey] [Virtualization Tools] [ET Management Tools] [Yum Users] [Tux] [Yosemite News] [Yosemite Photos] [Linux Apps] [Maemo Users] [Gnome Users] [KDE Users] [Fedora Tools] [Fedora Art] [Fedora Docs] [Maemo Users] [Asterisk PBX] [Fedora Sparc] [Fedora Universal Network Connector] [Libvirt Users] [Fedora ARM]