On Sep 14, 2014, at 3:43 PM, Fred Smith <fredex@xxxxxxxxxxxxxxxxxxxxxx> wrote: > On Sun, Sep 14, 2014 at 02:51:29PM -0600, Chris Murphy wrote: >> >> On Sep 14, 2014, at 8:38 AM, Joshua Andrews <woodguy552010@xxxxxxxxx> wrote: >> >>> >>> >>> On Sat, Sep 13, 2014 at 12:13 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >>> Got a bug where the upgraded kernel isn't being booted by default. I'm not exactly sure why, or what release criteria to use, so I set it to final based on it being a security concern. >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1141414 > > This is probably completely unrelated to my little problem from a few > years ago, but here it is anyway, just in case: > I once had a case, in which I was running software Raid, with a pair of > drives in RAID-1 (CentOS 5.x, that was). > > At one point I noticed that I wasn't running the latest kernel, even > though I KNEW I had been installing all the updates. > > After some considerable head-banging, I discovered that one of the > two drives had been ejected from the RAID pair, and for reasons I can't > remember anymore, when kernel updates were happening, they were happening > on the one remaining member of the (degraded) raid pair, but the system, > was BOOTING from the OTHER member of the pair. > > Subsequently, I learned that root was getting the emails from mdraid > about the degraded array, and he doesn't read his email very often. So, > now they are sent directly to me so things like that won't happen anymore. > > An interesting learning experience, that was. Right and also why we shouldn't use mdadm metadata 1.0 anymore for creating /boot on md raid1 arrays. Instead it should be metadata version 1.2, which offsets the filesystem enough that an individual member can't be mounted. The array must be assembled first, something grub2 can do, either normally or degraded, and only then is the filesystem mountable. Prevents exactly the problem you're talking about. But then, checking degraded raid emails would too. Chris Murphy -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
