:: Re: [DNG] /usr to merge or not to m…
Top Page
Delete this message
Reply to this message
Author: Roger Leigh
Date:  
To: dng
Subject: Re: [DNG] /usr to merge or not to merge... that is the question
On 24/11/2018 15:08, karl@??? wrote:
> Roger:
> ...
>> There's no clean separation between the "base" system and "everything else".
> ...
>
> I think my urge to have a separate /usr is that I want such a
> separation and there isn't a clear other place to have it.


Is there an underlying rationale for why you want this separation?

>> The other part of the scenario you mentioned here is "doesn't want to
>> use an initramfs". Why?
> ...
>
> I skip initrd to keep the boot setup simple.


I touched on this in another reply with regard to the relative number of
people testing a separate /usr, but I wanted to come back to this point
because there's a very important consequence to note here.

It's absolutely true that direct booting without an initrd is simple.
You're cutting out a relatively large amount of complexity, and you're
mounting the rootfs directly as a device from the kernel command-line.
You can't get much simpler than that.

However, there is a cost to bear in mind. Because this is a relatively
uncommon usage scenario (most people do use the initramfs since it's the
default), it's much, much less tested. There are a lot of special-cases
in many of the early boot scripts which are only run when direct
booting, and they are not exercised by the vast majority of systems out
there. By choosing to use the least-tested uncommon option, you are
bearing a certain risk.

The standard initrd generated by initramfs-tools is simply a busybox
shell, and a few shell scripts. It also copies in a few tools like udev
and a fsck for your system if needed. There is certainly some
complexity here. But it's not really all that complicated. No moreso
than the early init scripts. You could read through the scripts in a
few minutes. And you can even step through them by hand with the break=
option on the kernel command-line.


Regards,
Roger