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 1Rxamm-00083q-R6 for garchives@archives.gentoo.org; Wed, 15 Feb 2012 09:04:25 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 32A30E0AAA for ; Wed, 15 Feb 2012 09:04:24 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id EA1EBE0B5A for ; Wed, 15 Feb 2012 08:13:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 7A7B61B401C for ; Wed, 15 Feb 2012 08:13:52 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5.5 tests=[AWL=-0.587, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtu4oZe2TqYM for ; Wed, 15 Feb 2012 08:13:45 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 1EFFF654CD for ; Wed, 15 Feb 2012 08:13:41 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1RxZzd-0000eO-OK for gentoo-doc@gentoo.org; Wed, 15 Feb 2012 09:13:37 +0100 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Feb 2012 09:13:37 +0100 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Feb 2012 09:13:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-doc@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-doc] Re: RAID install document Date: Wed, 15 Feb 2012 08:13:23 +0000 (UTC) Message-ID: References: <4F3A9E54.1030907@tampabay.rr.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-doc@lists.gentoo.org Reply-to: gentoo-doc@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 19ecd49 /st/portage/src/egit-src/pan2) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 2d5df346-c19f-4ab2-8854-3c95c085cd5c X-Archives-Hash: 36e1b96ddfc3cde9a450670d1a9ec212 wireless posted on Tue, 14 Feb 2012 12:48:04 -0500 as excerpted: > Hello, >=20 > I'm trying to build a simple (all) raid 1 workstation. Just > boot/root/swap like what is found in the handbook. > Is this the best document to follow: >=20 > http://en.gentoo-wiki.com/wiki/RAID/Software >=20 > Since grub2 is now defacto and drive sizes are routinely over 2T, I > guess that Disk-labels (UUIDs), fstab, gpt and grub2 should all be used > to 'future proof' installations? >=20 > There is only a snippet in the handbook and it couches these and other > related issues around multilib. >=20 > Any better, more complete documents are keenly appreciated. There's no official gentoo grub2 docs at this point, and the existing doc= =20 (the link given in a grub2 postinstall einfo) is /seriously/ insufficient= / incomplete. That's one of the big reasons grub2 is still hard-masked,=20 not even ~arch yet. If you can get your grub2 info elsewhere, however, or know it reasonably=20 well from experience on other distributions, you'll know it's great for=20 gpt even on BIOS systems. (That's one of the bits missing in that grub2=20 doc, BTW, it mentions EFI and mbr-bios but not gpt-bios.) Of course,=20 it's also great for md/raid. I don't know about the status of gentoo gpt documentation, but gptfdisk=20 is a great fdisk for gpt, and it has very good documentation on its=20 homepage. I'm a great booster of both gpt and gptfdisk aka gdisk for a=20 number of reasons, including that gpt does away with the primary/logical=20 partition hassle, that it is *FAR* more reliable due to checksumming and=20 the second partition copy, the gpt-labels (as opposed to filesystem=20 labels, FWIW I use both but would prefer gpt labels as soon as mount,=20 etc, learns to work with them), and the dedicated BIOS and EFI system=20 partitions. It's worth noting that upgrading to grub2 was hugely easier for me=20 because I was already using gpt and had set aside a dedicated BIOS=20 partition (also an EFI partition, for the day I upgrade systems again). The caveat with grub2 here was the absolutely ridiculous number of calls=20 to grub2-probe that the default grub2-mkconfig script has with apparently= =20 no caching, each one taking ~10 seconds on my multi-disk system, with the= =20 total script therefore taking something like five minutes to run (based=20 on a bit of profiling I did, the script other than the grub2-probe calls=20 takes well under 10 seconds, so it's nearly all due to the repeated grub2= - probe calls), more than a kernel build from clean! As a result, I INSTALL_MASKED grub2-mkconfig and /etc/grub.d so they'd=20 have absolutely no chance of being run as they don't appear on the=20 system, then learned manual grub.cfg configuration and setup my own=20 configuration by hand. That's the only practical solution for anyone who= =20 upgrades their kernel at all frequently (I build from linus-mainline=20 git), at least for systems with multiple drives and mounts to be probed. = =20 As such and because the drive scanning order remains relatively stable=20 here (and the parameter can be changed in grub "live" if I need to), I=20 chose to stick with the relatively simple device names (not labels) for=20 grub2. Here, I use md 0.90 metadata and no initr*. I don't autodetect, however,= =20 as I have multiple md/raid devices and I only want the one containing the= =20 rootfs autoassembled, with userspace assembling the others I want=20 activated, later. Instead, I build in a kernel command line that=20 includes and md=3D parameter and disable autodetect. I'm not entirely su= re=20 if that could be done with 1.x metadata or not, since I'm feeding it the=20 devices to assemble into the raid instead of using autodetect. For /boot, depending on the number of spindles you're running, you may=20 wish to split it down the middle /boot and a backup /boot, or setup=20 independent /boot partitions on each one (if only 2-3 spindles). That=20 way, you can upgrade grub or install new kernels on one (presumably the=20 working /boot not the backup(s)), without risking damage to the others=20 until you've tested booting the first upgraded one. Once it is known to=20 boot the upgrade correctly, you can update the others. For people like=20 me that test git kernels, that also allows me to only install them to the= =20 normal /boot. I only update the backup(s) when a release kernel comes=20 out and I've tested it on the working /boot, then deleted all the pre- release versions once the release is tested to boot. That also allows you, if you so choose, to follow the official gentoo=20 documentation a bit closer, installing grub-legacy first, to one /boot,=20 then unmasking and installing grub2 to a second, to experiment with,=20 switching in BIOS which one boots while testing, before replacing the=20 documented grub-legacy that was installed to the first one only after=20 you're comfortable with how grub2 is working and setup on the others. Talking about which... the below link is the official quick-start=20 installation guide for gentoo on lvm2 on md/raid. I'm not personally=20 much for lvm2 -- the additional layer was too much for me to understand=20 well enough to be confident I could manage a proper recovery if I needed=20 to and it's no longer all that necessary since md/raid devices can be=20 partitioned like any normal block device these days -- but if you're=20 running a desktop such as gnome or kde and want the automounting to work=20 well, you'll still want to configure the device-mapper kernel options and= =20 need to install the lvm2 package, which contains the device-mapper=20 userspace needed by udisks for automount handling, etc. You'd just not=20 create the lvm2 volumes (and could wait until it's pulled in as a udisks=20 dependency to merge lvm2 if desired). Of course, this still documents grub-legacy, but as I mentioned, you can=20 either split up your /boot and install grub-legacy first, following the=20 official documentation reasonably closely, then install grub2 later, when= =20 you have time to experiment with it, or ignore the grub bit too, and do=20 the grub2 thing right off, if you're comfortable enough with it already=20 that you can handle the lack of gentoo specific documentation for it. http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml That's likely more than I should have written for the documentation list,= =20 but it's topical in that it does represent the state of things, I guess. Meanwhile, feel free to ignore the "list replies preferred" bit in the si= g=20 and contact me directly, if you've more questions, since it should be=20 quite apparent by now that I have quite some interest and some experience= =20 in this area. If you do contact me directly, please mention whether=20 amd64/x86/whatever (amd64/nomultilib, here), whether you're targeting=20 stable or ~arch and how comfortable you are with unmasking stuff like=20 grub2, etc, and reading other documentation, the number of spindles=20 you're raiding and metadata version, the desktop you'll be installing if=20 any and whether you care about the automount stuff (fwiw I'm a kde guy,=20 and have udisks and lvm2 installed as dependencies but don't have device- mapper on in the kernel as I don't particularly care for automounting),=20 whether you're running an initr* (I don't and know little about them),=20 etc, as that could well save a few rounds of email-ping-pong. =3D:^) --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman