public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Jaco Kroon <jaco@uls.co.za>
To: gentoo development <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] separate /usr without initramfs
Date: Fri, 25 Oct 2019 21:52:56 +0200	[thread overview]
Message-ID: <6c42a495-4397-50f9-ed46-804a39db61af@uls.co.za> (raw)
In-Reply-To: <20191025181417.GA4290@whubbs1.dev.av1.gaikai.org>

Hi,

On 2019/10/25 20:14, William Hubbs wrote:
> Hey all,
>
> I have been advised to bring this topic back to the list before taking
> any action, so here it is.
>
> First, I need to clarify what I'm *NOT* talking about.
>
> This discussion has nothing to do with whether or not you have the
> split-usr use flag turned on; all of us officially have that on because
> /bin, /lib* and /sbin are directories in the official Gentoo setup. In
> other words, I am *not* talking about forcing the /usr merge.
>
> Unfortunately, the concept of separate usr has gotten wrapped up in the
> split-usr use flag and doesn't have to be.  For the record, I mean something
> very specific when I say "separate usr". I am talking about the situation
> where /usr is a mount point separate from /, so in this thread, let's stick
> to "separate usr" for that situation. I am *not* even saying that using
> separate usr is wrong or unsupported. You can even run separate usr with
> split-usr turned off if you would like to do so.
>
> Now for the use case I want to talk about, and that is using separate
> /usr without using an initramfs to boot your system and pre-mount /usr.
>
> If you do this, many things are broken, and this is why the binary
> distros all use an initramfs if you do this. This configuration is also
> unsupported officially in Gentoo [1] [2], and it is not shown as the
> example setup in our handbook.
>
> I want to hear from people who have / and /usr on separate partitions
> and who are not using an initramfs.
>
> If you are in this group, I have a very specific question. Why aren't
> you using an initramfs?

Because until recently it wasn't an issue.  So for me the final kicker 
was still not a separate /usr.  For my use case everything except a big 
warning about md5sum not being available during boot works.  This is NOT 
desktop setup for MOST of my systems.  On the few that are I don't 
generally have things like bluetooth keyboards etc that I need available 
during early(ish) boot or anything crazy.  So the argument that "many 
things break" may be accurate, but I've yet to find a concrete example 
that bugs me enough to care.

There is basically one thing that I found that broke "out of the box" 
with a separate /usr - and that's if I have one of those stupid LTE 
modem things that pretend to be a disk drive/cdrom or something similar 
until you tell it to switch to network mode. The same thing that, for 
me, breaks with suspend resume (after resume I have to kill 
modem_manager, and start it *before* replugging the modem or it simply 
will not work - another discussion).

So frankly, I just don't see the benefit.  The reason I've eventually 
bothered with setting up and creating an initramfs now was because of 
/lib/firmware which I need available during module load (pre 
/etc/init.d/localmount) so that firmware is available as soon as amdgpu 
and i915 loads or else I end up with a borked screen.  Only uefi fb 
compiled into the kernel (required to get hand-over from grub2 ... at 
least, the only way I could get it to work smoothly).

The initramfs we ONLY pull in on systems where it's required (one 
currently, the machine I'm typing this on).

Why do I have /lib/firmware on a separate partition now?  Because 512MB 
for / used to be plenty, and I have MANY history systems out there which 
is non-trivial to make partitioning changes to (I keep / in a raw 
partition).  Now just /lib/firmware is larger than that.

Like William, / and /boot are definite partitions, and I want to keep 
these small.  Everything else is LVM.  Most systems have >50% of VG 
space unallocated because people always overestimate what they really need.

Separate partitions means I can set up separate mount options 
(nosuid,nodev etc ...)

Like William, I feel more cogs means more opportunities for breakage. I 
roll my own vanilla kernel, with one or two of my own patches.  I roll 
my own init script for initramfs.  Why - because system bootability is 
of utmost importance.  So I absolutely have to KNOW that it'll work, and 
when it doesn't that I can walk someone through fixing it over the 
phone. Never used the default gentoo initramfs.  genkernel always pulls 
in stuff I don't want nor need.  Sometimes it's just simpler I guess.  
But that's the thing - Gentoo gives me CHOICE.  Which I don't get from 
other distributions.  These are not the kind of things I like to leave 
to chance, or in the hands of a continuously changing tool (eg, dracut 
as mentioned by William).

Recently we ran into a bug causing filesystem corruption on /usr/portage 
(for some reason it was always under /usr/portage). With /usr on a 
separate partition we could recover that by setting appropriate boot 
options *remotely*.  No need to drive out.  Some of these systems were 
 >100km away.

So another motivation for separate / and /usr for me is that / is much 
more read-heavy than /usr, and as such, with the lower write ratio lower 
risk of corruption.  Better ability to recover.

As to why not use the initramfs - simple:  It's not needed.

The only potential advantage in my opinion is if you can build a 
recovery system in there that's small enough, and contains all 
conceivable tools required to recover from just about any boot failure.  
Work-in-progress I guess.

I'm not sure that answers your question, and this is one of those 
debates that can run in circles for hours, days and even weeks. So I 
hope I at least managed to give you some insight into my thinking and 
reasoning.

Kind Regards,
Jaco



  parent reply	other threads:[~2019-10-25 19:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-25 18:14 [gentoo-dev] separate /usr without initramfs William Hubbs
2019-10-25 18:40 ` Dale
2019-10-25 20:08   ` William Hubbs
2019-10-25 20:16     ` Dale
2019-10-25 20:56       ` William Hubbs
2019-10-25 19:52 ` Jaco Kroon [this message]
2019-10-27  9:38 ` Joshua Kinard
2019-10-27 10:06   ` James Le Cuirot
2019-10-27 16:12     ` Matt Turner
2019-10-27 16:17       ` Michael Everitt
2019-10-27 17:01         ` James Le Cuirot
2019-10-27 19:55       ` Joshua Kinard
2019-10-27 19:52     ` Joshua Kinard
2019-10-27 11:22   ` Benda Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6c42a495-4397-50f9-ed46-804a39db61af@uls.co.za \
    --to=jaco@uls.co.za \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox