Re: [gentoo-user] Re: USE flag 'split-usr' is now global

[Grant Taylor <gtaylor@gentoo.tnetconsulting.net>]

On 8/6/19 10:28 AM, Rich Freeman wrote:
> An initramfs is just a userspace bootloader that runs on top of linux.

I disagree.

To me:

  · A boot loader is something that boots / executes a kernel with 
various parameters.
  · An initramfs / initrd (concept) is the micro installation that runs 
under the kernel that was booted (by the boot loader).

The initramfs / initrd micro installation does the following:

1)  fulfills prerequisites (e.g. loads requisite drivers, initializes 
networking for and discovers storage, decrypts block devices)
2)  mounts root (and some other) file systems
3)  launches additional init scripts.

None of those steps include booting / executing an alternate kernel.

Remember that the contents of an initramfs / initrd is a micro 
instillation that simply includes the minimum number of things to do 
steps 1–3 above.

The initrd is literally an image of a block device with a root file 
system on it that includes the minimum number of things to do steps 1–3 
above.

The initramfs is a CPIO archive of the minimum number of things to do 
steps 1–3 above which get extracted to a temporary location (usually a 
ram disk).

Both an initrd and an initramfs are a micro installation for the purpose 
of initializing the main installation.  They are not a boot loader.

> Nobody has any problem with conventional bootloaders, and if you want 
> to do anything with one of those you have to muck around in low-level 
> C or assembly.

That's because a boot loader, e.g. GRUB, lilo, loadlin, do something 
different and operate at a lower level than system init scripts.

> There has been talk of gathering up all the stuff you need from 
> /usr to bootstap everything, and then adding some scripting to mount 
> everything.  The proposals have been to shove all that in / somewhere 
> (perhaps even in /bin or /sbin).  If instead you just stick it all in 
> a cpio archive you basically have an initramfs,

Not basically.  That /is/ what an initramfs / initrd contains.

> and you don't need to have cruft all over your filesystem to do it.

Actually yes you do need that cruft.

Let's back up and talk about what that cruft is.

It's the minimum libraries and binaries required to:

1)  Requisite libraries
      - C library
      - other similar / minimal / unavoidable libraries
2)  Requisite binaries
      - fsck
      - mount
      - networking utilites (for iSCSI / NFS / etc.)
      - other similar / minimal / unavoidable binaries
3)  Scripts to bring the rest of the system up
      - minimal init scripts to go from a post-kernel-execution (what 
was traditionally /sbin/init) to launching second stage init scripts

To me, all of these things are going to exist on the main installation 
/anyway/.  There is going to be minimal, if any, difference between the 
version put in the initramfs / initrd and what's in the main / (root).

So, to me, what you're calling "cruft" is core system files that are 
going to exist anyway.

If anything, having an initramfs / initrd means that you're going to 
have an additional copy of said core system files in a slightly 
different format (initramfs / initrd) that's not usable by the main system.

> There are already configurable and modular solutions like dracut which 
> do a really nice job of building one,

Yes.  We've had many different tools in the last 28 years of Linux and 
longer for Unix for making the management of the boot process simpler.

It comes down to loading the kernel from something and starting the 
kernel with proper parameters (that's the boot loader's job) and 
starting something (traditionally /sbin/init) from some storage somewhere.

> and they make your bootstrapping process infinitely flexible.

Nope.  I don't agree.

There have been many things that I've wanted to do in the past 20 years 
that initramfs / initrd aren't flexible enough to do.

But adding an init script that calls tools on the root file system is 
infinitely more flexible.  I'm not restricted to doing things that 
dracut (et al.) know how to do.

If I can boot the kernel, point it at a root disk, and launch an init 
system, I can do anything I want with the system.

Let me say it this way.  If I can put together commands to do something, 
I can get thee system to do it on boot.  I don't have to wait for dracut 
to be updated to support the next wiz-bang feature.

> If you want root to be a zip file hosted on a webserver somewhere 
> that isn't a problem.  If you want root to be a rar file on a 
> gpg-encrypted attachment to a message stored on some IMAP server, 
> you could do that too.  To make all that work you can just script it 
> in bash using regular userspace tools like curl or fetchmail, without 
> any need to go mucking around with lower-level code.  Then once your 
> root filesystem is mounted all that bootstrapping code just deletes 
> itself and the system operates as if it was never there (strictly 
> speaking this isn't required but this is usually how it is done).

You need /something/ to be your starting root file system.  For most 
servers / workstations / VMs / containers, that's a local directory 
structure.

Sadly, I think people have thrust additional (IMHO) largely unnecessary 
complexity into the init process just to be able to support more exotic 
installations.  Then, they have said "We want to be consistent in how we 
boot, so we need to use this more complex thing everywhere."  To which, 
many greybeards have responded "I don't need nor want that on my simple 
server."

If you /actually/ /need/ a micro installation to make your main 
installation available, then go for it.  But if you don't /actually/ 
/need/ a micro installation, well Occam's Razor / Parsimony.

> I doubt we'll see a /usr merge anytime soon, or any huge rush to 
> break a separate /usr completely without an initramfs.

Okay.

> However, there are already use cases known where a separate /usr can 
> cause problems without either an initramfs or some kind of early-boot 
> shell script (there have already been solutions tossed out for that 
> which are much simpler than the ones in this thread).

How does the "early-boot shell script" that you speak of differ from an 
init-script?

> The biggest example I've heard is bluetooth keyboards - that was what 
> made most of the zealots give up on supporting anything that could 
> possibly be needed for bootstrapping being in /, as bluetooth has a 
> bunch of deps and at that point you might as well shove gnome in /bin.

If you want to burden your init system with supporting things like 
BlueTooth, that's your choice.  I sure as hell wouldn't do that.

> So, for the forseeable future your system probably won't break if 
> you are using a separate /usr, but if it does the policy has been 
> established for a long time that nobody is obligated to fix it (nor 
> are they prohibited from doing so).

~chuckle~

> Really, though, you should take the time to appreciate an initramfs 
> whether you decide to use one or not.

You seem to be assuming that people /don't/ appreciate an initramfs / 
initrd.  When for me personally, I do understand and appreciate what an 
initramfs / initrd does.  Enough so that I know that the systems that I 
run don't /need/ one.

> They're a really elegant solution to the problem.

I wouldn't use the words "elegant" or "solution".  "kludge" comes to mind.

> Sometimes I think that half the objection is due to the fact that 
> they use cpio which is a bit obscure

You are free to think that.  I'm free to disagree with what you think.

> if they were tarballs people would be tearing them apart and playing 
> with them more.

I know many people that have played with them (initramfs and / or 
initrd).  Many of whom have looked at what they do and realized that 
they don't actually /need/ them to boot their system.  So they choose to 
not use them, thereby reducing unnecessary complexity in the boot process.



-- 
Grant. . . .
unix || die