Re: [gentoo-user] Tips for fresh install with GRUB2+RAID1+LVM2

[Rich Freeman]

Just a few clarifications below.

One thing this discussion is missing is any mention of BIOS / EFI.
Most of the discussion below seems most relevant to a legacy BIOS
installation.  Many specialized Gentoo install docs, like mdadm+lvm,
don't really make mention of EFI, or other more recent developments.
Now that all the docs are on the wiki I'd strongly encourage anybody
with an interest to improve them.  Many seasoned Gentoo users barely
reference the documentation these days and I think that is part of why
they've become a bit dated.

A few of the topics below are somewhat controversial, particularly on
this list.  I tried to stick to the facts and indicate where there is
a difference of opinion.  I'd prefer not to rehash all the various
debates...

On Sun, May 17, 2015 at 9:24 AM, Peter Humphrey <peter@××××××××××××.uk> wrote:
> On Sunday 17 May 2015 12:48:58 Nuno Magalhães wrote:
>
>> (Later i want to get rid of systemd-udev and use eudev instead.)
>
> I use openrc, not systemd. It still works well and has less complication - and
> less typing!

Most people using openrc are also using systemd-udev (and there is a
good chance you do too).  The latter was previously named udev and
long predates what most people call systemd.  Eudev is a fork of udev,
which comes from after it came under the systemd umbrella, but before
the name change and a number of changes that were controversial.  I
believe they try to incorporate many of the patches from systemd-udev
but some default behaviors are different.

In any case, I just wanted to clarify that systemd-udev is not the
"systemd" you're probably thinking of.  In particular, it doesn't
replace openrc or sysvinit.  Systemd-udev largely is concerned with
populating /dev, and running initialization of hardware when it is
detected, based on a configurable set of rules.

>
>> I intend to use XFS for /. Incidentally, if i later decide to "fork
>> out" /usr (or some other subdirectory) into it's own LV, is it "just"
>> a mater of copying its contents and updating /etc/fstab? Or should i
>> just do it now and expand the LVs if later required (especially if i
>> want to use different filesystems)?
>
> I can't help you with XFS. I know that ext4 in an LV in a VG in a PV on RAID1
> works reliably, even though it does look complex when I write it like that.

As far as LVM and xfs themselves go, you can do what you propose.

However, Gentoo QA policy is that it is expected that /usr is mounted
early in boot.  Various tools can break if it is not.  Typically this
is the responsibility of an initramfs, however you can also use
scripts that run early during initialization from / which mount it.
If you just stick /usr in fstab and rely on openrc to mount it for you
normally, you may or may not have problems.

It has been a long time since I actually used such a system in this
manner with Gentoo, but the last I saw discussion on it most who used
this configuration found it usually worked fine, unless you were using
something like a bluetooth keyboard or other key system component that
required a lot of userspace tooling to make work.  However, as a
matter of policy you're on your own if you choose not to mount /usr
early during boot in some way.

The reason it is not supported is that with the rise of things like
bluetooth the list of dependencies possibly required during early boot
has grown to the point where we'd end up not even having a /usr before
long.  My sense is that for the most part most maintainers tend to
respect the traditional definition of / and /usr on Gentoo, and thus
you can often get away with doing things the traditional way.
However, the policy does allow us to end debates over things like udev
rules invoking some userspace tool in /usr and such.  Some packages
more strongly depend on /usr being installed in early boot, and there
have been suggestions (but nothing concrete) that Gentoo consider
supporting the /usr-move that other distros have embraced (and that
would basically get rid of /lib, /bin, and so on).

>
> Again, legacy grub here. But if you're using an initramfs, from what I've seen
> you don't need to specify metadata 0.90.

I used to use grub legacy and kernel RAID auto-assembly.  As a result
I was using metadata 0.90.

I found this configuration problematic on rare occasions.  There is a
reason that mdadm changed the metadata, and why most distros don't do
it this way.  (more below)

>
> Damn. I've just checked and something has renamed my /dev/md7 to
> /dev/md127. Again. It's just too bad. I shall have to stop it when I get a
> quiet moment and reassemble it into /dev/md7. Actually, I know what caused
> it but I didn't notice at the time.

And this was one of the configuration problems I ran into on rare
occasion.  Often booting from a rescue CD or such caused something
like this to happen.

One of the advantages of using an initramfs is that they can be a lot
smarter about finding your partitions.  You can identify them by UUID
or label, and not care as much if mdadm or the kernel renames your
device nodes.

I'd seriously take a look at dracut, though I don't know if it works
with eudev.  It certainly should support openrc, and I know that it
did back when I was running openrc.  It can also mount /usr for you,
and in fact it should automatically do so.  It also respects your
fstab - it uses its internal logic and the kernel boot line to
initially find filesystems, but then it reads your /etc/fstab and
remounts everything as you define it there just in case something has
changed since the last time you built the initramfs/etc.  You can
define your own modules for it which makes it reasonably easy to get
it to do anything at all during early boot, and it doesn't require
anything to be built static (it finds required shared objects anywhere
on the filesystem and includes them in the initramfs).  It can also
give you a rescue shell if something goes wrong, and depending on your
settings you can make that rescue shell reasonably well-featured
(using either dash or bash as you prefer inside, and I imagine you
could tell it to install the other on the side).  A while ago I needed
to run some btrfs tools that aren't in dracut by default and it was
trivial to tell dracut to include them, and I forced a shell on next
boot which gave me the latest tools and kernel without having to build
a rescue CD with them, and a bash shell to run them from.

It certainly isn't necessary to use an initramfs to use Gentoo, and I
used to be among the more minimalist crowd that avoided them.
However, once I took the time to examine dracut it went from being a
blob that looked unnecessary to a tool that is often useful.

-- 
Rich