From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Q2t6z-0001Gz-Ru for garchives@archives.gentoo.org; Thu, 24 Mar 2011 22:34:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2E0C71C02F; Thu, 24 Mar 2011 22:33:10 +0000 (UTC) Received: from shakti.fmp.com (shakti.fmp.com [208.81.244.105]) by pigeon.gentoo.org (Postfix) with ESMTP id F0CF11C02F for ; Thu, 24 Mar 2011 22:33:09 +0000 (UTC) Received: from [192.168.1.16] ([::ffff:10.8.0.4]) (AUTH: LOGIN fmouse@fmp.com) by shakti.fmp.com with esmtp; Thu, 24 Mar 2011 17:33:09 -0500 id 000000000026B8E9.000000004D8BC6A5.0000623E Subject: Re: [gentoo-desktop] System problems - some progress From: Lindsay Haisley To: gentoo-desktop@lists.gentoo.org In-Reply-To: References: <1300596366.8325.30.camel@vishnu.fmp.com> <20110320095034.6b27043a.zilka@fi.muni.cz> <1300637317.1698.38.camel@ubuntu> <20110321001034.42e087b8.zilka@fi.muni.cz> <1300672634.8325.179.camel@vishnu.fmp.com> <20110321095742.758b2278.zilka@fi.muni.cz> <1300724287.1757.78.camel@ubuntu> <685081770-1300738047-cardhu_decombobulator_blackberry.rim.net-274633814-@bda261.bisx.prod.on.blackberry> <1300746267.11877.76.camel@vishnu.fmp.com> <4D87D52F.4060706@gmail.com> <4D87FD44.1030502@gentoo.org> <1300990587.8052.61.camel@vishnu.fmp.com> <1300999110.8052.287.camel@vishnu.fmp.com> Organization: FMP Computer Services Date: Thu, 24 Mar 2011 17:33:08 -0500 Message-Id: <1301005988.8052.359.camel@vishnu.fmp.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-desktop@lists.gentoo.org Reply-to: gentoo-desktop@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Evolution 2.26.3 X-Archives-Salt: X-Archives-Hash: 5cc13dd85f7a51a4653d356287c13264 Thanks, Paul. On Thu, 2011-03-24 at 16:42 -0500, Paul Hartman wrote: > I was actually referring to the ARRAY lines and the array UUIDs. In > fact I don't even have a DEVICE line, man mdadm.conf says: > If no DEVICE line is present, then "DEVICE partitions containers" is > assumed. > > My mdadm.conf only contains 2 ARRAY lines, for my 2 raid arrays. I > also specify the metadata version, I assume you're using superblock > 0.90 since you've been using autodetect and autodetect isn't supported > for newer versions. Newer versions? Kernel 2.6.36 has a config option for RAID autodetect. What are you referring to here, mdadm? mdadm is at 2.6.8 on this box. If I upgrade to v3.1.4 will I lose the ability to autodetect the arrays, on which the system depends even on the 2.6.23 kernel on which I'm currently depending? > So, mdadm scans all partitions (doesn't matter what they are named) > looking for superblocks containing the UUID of the arrays I specified. > Anything that doesn't match gets ignored for this purpose. > The mdadm manpage has this example command: > mdadm --examine --brief --scan --config=partitions So I get: # mdadm --examine --brief --scan --config=partitions ARRAY /dev/md0 level=raid1 num-devices=2 UUID=d3176595:06cb3677:46406ca7:d12d146f ARRAY /dev/md1 level=raid1 num-devices=2 UUID=9463a434:24dbfcb6:a25ffb08:d8ab7c18 ... which is what I would expect. Does this mean that the UUID of the _array_ has been pushed onto the component drives? If so, why does the RAID assembly fail so miserably with kernel 2.6.36? I'm lost here. It looks to me, from the boot log, as if the problem is that there are _two_ partitions named /dev/sda1 and the RAID subsystem can't see the one that's a component of md0. /etc/mdadm.conf contains: DEVICE /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 ARRAY /dev/md0 devices=/dev/sda1,/dev/sdb1 ARRAY /dev/md1 devices=/dev/sdc1,/dev/sdd1 > Create a list of devices by reading /proc/partitions, scan these for > RAID superblocks, and printout a brief listing of all that were > found. This gives me the UUIDs of the arrays, but my question here is whether I can spec the component devices using UUIDs, and I'm not finding any clear guidance on that. The mdadm man page talks about the former, but doesn't mention the latter. In other words, can I put into mdadm.conf a line such as the following: ARRAY /dev/md0 devices=UUID=d3176595-06cb-3677-4640-6ca7d12d146f,UUID=d3176595-06cb-3677-4640-6ca7d12d146f > Hopefully you can find your array UUIDs with that command (and if it > finds them, that's a good sign for it's ability to assemble the arrays > once the config file is made) Finding the ARRAY UUIDs isn't the problem, it's assigning the array components using _their_ respective UUIDs. If I can do this, the problem may be solved. I don't know that this will work, I don't know that it won't. I have everything on the arrays, and the LVMs built on them, backed up. I probably should just try it and back out of it if it doesn't, since I don't see any potential for data loss if it fails, in which case the RAID arrays simply won't be built and I'll be dumped into the workable but not very useful non-RAID configuration. -- Lindsay Haisley | "The difference between a duck is because FMP Computer Services | one leg is both the same" 512-259-1190 | - Anonymous http://www.fmp.com |