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

[Rich Freeman]

On Tue, Aug 6, 2019 at 7:41 PM Grant Taylor
<gtaylor@×××××××××××××××××××××.net> wrote:
>
> 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).

Bootloaders are just programs that run other programs, ultimately.  We
can argue all day about what kinds of programs count as each.  But,
there is no point arguing definitions.

> 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.

So, an initramfs doesn't actually have to do ANY of those things,
though typically it does.

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

Nothing prevents an initramfs from booting an alternate kernel
actually, though if it does it will need its own root filesystem
initialized one way or another (which could be an initramfs).

Linux bootstrapping linux is basically the whole premise behind coreboot.

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

Sure, but you don't need it ALL OVER YOUR FILESYSTEM.  Some of the
proposed solutions in this thread involved sticking stuff in /bin and
so on.  An initramfs is nicely bundled up in a single file.

> 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.

Absolutely true, which means it won't interfere with the main system,
as opposed to sticking it in /bin or somewhere where it might.

> > 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.

Such as?

It is a linux userspace.  It can literally do anything.

> 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.

You don't need to use dracut (et al) to have an initramfs.

In fact, you could create your super root filesystem that does all the
fancy stuff you claim you can't do with an initramfs, then create a
cpio archive of that root filesystem, and now you have an initramfs
which does the job.

> 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.

Sure, but only if the kernel can find that disk without any userspace
code.  What if that disk is on the other side of an ssh tunnel?

> 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 know the commands to do something, why would you have to wait
for somebody else to implement them?

>
> > 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.

Actually, for most of these the initramfs is the starting root
filesystem (just about all linux server installs use one).  Usually it
just mounts a simple filesystem on a local disk as root and then
pivots.

However, an initramfs frees you up from the limitation that it be
something that can be passed directly on the command line.

> 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."

Initramfs is popular because it is way more flexible:

1.  You can build a fully modular kernel so that you can use the same
kernel on every system but not be loading countless drivers for
hardware most systems don't use, while still being certain of being
able to boot any particular system.
2.  You have more access to labels/uuids/etc for finding the root
filesystem so that when one of your hard drive fails the kernel
doesn't just dumbly use the next one in sequence, assuming they're
even always identified in the same order.
3.  You can use "exotic" installations like iscsi and so on, which
seems pretty useful in an enterprise setting.

>
> 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.

Except then you're tailoring your bootloader to individual systems.

Most sysadmins will prefer the Ubuntu/RHEL/etc approach where the same
kernel/bootloader/etc works everywhere, vs tailoring their boot
process to every individual host.

> > They're a really elegant solution to the problem.
>
> I wouldn't use the words "elegant" or "solution".  "kludge" comes to mind.

What could be more elegant?  It minimizes the complexity of the
kernel, which is why Linus generally prohibits the kernel from having
any more advanced root mounting logic, and why pretty much every Linux
system out there uses one.

-- 
Rich