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

[Canek Peláez Valdés]

On Sun, May 17, 2015 at 10:35 AM, <covici@××××××××××.com> wrote:
>
> Rich Freeman <rich0@g.o> wrote:
>
> > 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.
>
> Last time I tried to use dracut with openrc, it failed, I can't remember
> exactly what happened, I think udev did hang, but its been a while since
> this happened.  Dracut uses systemd internally, so maybe this is part of
> the problem.

Dracut only uses systemd optionally and (AFAIR) not by default. If you
don't specify it, dracut will use its own scripts as init.

Regards.
--
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México