Gentoo Archives: gentoo-doc

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-doc@l.g.o
Subject: [gentoo-doc] Re: RAID install document
Date: Wed, 15 Feb 2012 09:04:25
In Reply to: [gentoo-doc] RAID install document by wireless
wireless posted on Tue, 14 Feb 2012 12:48:04 -0500 as excerpted:

> Hello, > > 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: > > > > 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? > > There is only a snippet in the handbook and it couches these and other > related issues around multilib. > > Any better, more complete documents are keenly appreciated.
There's no official gentoo grub2 docs at this point, and the existing doc (the link given in a grub2 postinstall einfo) is /seriously/ insufficient/ incomplete. That's one of the big reasons grub2 is still hard-masked, not even ~arch yet. If you can get your grub2 info elsewhere, however, or know it reasonably well from experience on other distributions, you'll know it's great for gpt even on BIOS systems. (That's one of the bits missing in that grub2 doc, BTW, it mentions EFI and mbr-bios but not gpt-bios.) Of course, it's also great for md/raid. I don't know about the status of gentoo gpt documentation, but gptfdisk is a great fdisk for gpt, and it has very good documentation on its homepage. I'm a great booster of both gpt and gptfdisk aka gdisk for a number of reasons, including that gpt does away with the primary/logical partition hassle, that it is *FAR* more reliable due to checksumming and the second partition copy, the gpt-labels (as opposed to filesystem labels, FWIW I use both but would prefer gpt labels as soon as mount, etc, learns to work with them), and the dedicated BIOS and EFI system partitions. It's worth noting that upgrading to grub2 was hugely easier for me because I was already using gpt and had set aside a dedicated BIOS partition (also an EFI partition, for the day I upgrade systems again). The caveat with grub2 here was the absolutely ridiculous number of calls to grub2-probe that the default grub2-mkconfig script has with apparently no caching, each one taking ~10 seconds on my multi-disk system, with the total script therefore taking something like five minutes to run (based on a bit of profiling I did, the script other than the grub2-probe calls 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 have absolutely no chance of being run as they don't appear on the system, then learned manual grub.cfg configuration and setup my own configuration by hand. That's the only practical solution for anyone who upgrades their kernel at all frequently (I build from linus-mainline git), at least for systems with multiple drives and mounts to be probed. As such and because the drive scanning order remains relatively stable here (and the parameter can be changed in grub "live" if I need to), I chose to stick with the relatively simple device names (not labels) for grub2. Here, I use md 0.90 metadata and no initr*. I don't autodetect, however, as I have multiple md/raid devices and I only want the one containing the rootfs autoassembled, with userspace assembling the others I want activated, later. Instead, I build in a kernel command line that includes and md= parameter and disable autodetect. I'm not entirely sure if that could be done with 1.x metadata or not, since I'm feeding it the devices to assemble into the raid instead of using autodetect. For /boot, depending on the number of spindles you're running, you may wish to split it down the middle /boot and a backup /boot, or setup independent /boot partitions on each one (if only 2-3 spindles). That way, you can upgrade grub or install new kernels on one (presumably the working /boot not the backup(s)), without risking damage to the others until you've tested booting the first upgraded one. Once it is known to boot the upgrade correctly, you can update the others. For people like me that test git kernels, that also allows me to only install them to the normal /boot. I only update the backup(s) when a release kernel comes 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 documentation a bit closer, installing grub-legacy first, to one /boot, then unmasking and installing grub2 to a second, to experiment with, switching in BIOS which one boots while testing, before replacing the documented grub-legacy that was installed to the first one only after you're comfortable with how grub2 is working and setup on the others. Talking about which... the below link is the official quick-start installation guide for gentoo on lvm2 on md/raid. I'm not personally much for lvm2 -- the additional layer was too much for me to understand well enough to be confident I could manage a proper recovery if I needed to and it's no longer all that necessary since md/raid devices can be partitioned like any normal block device these days -- but if you're running a desktop such as gnome or kde and want the automounting to work well, you'll still want to configure the device-mapper kernel options and need to install the lvm2 package, which contains the device-mapper userspace needed by udisks for automount handling, etc. You'd just not create the lvm2 volumes (and could wait until it's pulled in as a udisks dependency to merge lvm2 if desired). Of course, this still documents grub-legacy, but as I mentioned, you can either split up your /boot and install grub-legacy first, following the official documentation reasonably closely, then install grub2 later, when you have time to experiment with it, or ignore the grub bit too, and do the grub2 thing right off, if you're comfortable enough with it already that you can handle the lack of gentoo specific documentation for it. That's likely more than I should have written for the documentation list, 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 sig and contact me directly, if you've more questions, since it should be quite apparent by now that I have quite some interest and some experience in this area. If you do contact me directly, please mention whether amd64/x86/whatever (amd64/nomultilib, here), whether you're targeting stable or ~arch and how comfortable you are with unmasking stuff like grub2, etc, and reading other documentation, the number of spindles you're raiding and metadata version, the desktop you'll be installing if any and whether you care about the automount stuff (fwiw I'm a kde guy, 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), whether you're running an initr* (I don't and know little about them), etc, as that could well save a few rounds of email-ping-pong. =:^) -- 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