[gentoo-doc] Re: RAID install document

[Duncan]

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:
>
> http://en.gentoo-wiki.com/wiki/RAID/Software
>
> 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.

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, 
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