On Thu, 2011-03-24 at 18:20 -0500, Paul Hartman wrote: > On Thu, Mar 24, 2011 at 5:33 PM, Lindsay Haisley <[email protected]> > wrote: > > Newer versions? Kernel 2.6.36 has a config option for RAID autodetect. > > What are you referring to here, mdadm? > > Even the newest kernel supports autodetect, but autodetect only works > with a specific kind of RAID superblock, I think version 0.90. > Different versions of mdadm create arrays with different versions of > superblock by default. Newer versions of superblocks cannot > (presently) be autodetected by the kernel, so anyone using a newer > type of superblock will have to do the "manual" config like this > anyway.
Ah. So it follows that if the array was created with an earlier version of mdadm, and mdadm -D tells me that the superblock is persistent and is version 0.90 then autodetection should work. It would also follow that if I turn off RAID autodetection in the kernel, and spec'd ARRAYs by UUID in /etc/mdadm.conf, I should be OK. > As for why it's not working in your case, I really don't know, but > hopefully you can at least get it working /somehow/ so that you can > use your system normally to get real work done, and can investigate > why auto-detect doesn't work the way you'd like it to with less > urgency. If I can't, it's not the end of the world, since I can just let it be and build up a new box and move stuff to it. I need to emerge -u mdadm since I'm currently at v2.6.8 and the portage tree recommends v3.1.4. I need to really make sure that this upgrade will work, since, unlike udev-141, I can't back-version if the newer mdadm causes a problem. > I've got an old Gentoo system that takes days to update, but > if the system is usable during that time it's not really a big deal to > me. It's the days-long updates when the system is in an unusable state > that are a real nightmare. Yeah, there's some brilliant programming in Gentoo, and I really like the concept of what Duncan calls the "rolling upgrade" design philosophy, but it's a slow and complex process. I'd rather deal with a fixed version distribution these days and let others deal with the builds. -- Lindsay Haisley | "We are all broken toasters, but we still FMP Computer Services | manage to make toast" 512-259-1190 | http://www.fmp.com | - Cheryl Dehut |
