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