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

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

On 8/6/19 6:31 PM, Rich Freeman wrote:
> So, an initramfs doesn't actually have to do ANY of those things, 
> though typically it does.

I agree that most systems don't /need/ an initramfs / initrd to do that 
for them.  IMHO /most/ systems should be able to do that for themselves.

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

Agreed.

Though I think that's rare enough that I chose to ignore it for the last 
email.

> Linux bootstrapping linux is basically the whole premise behind 
> coreboot.

Sure.

But coreboot is not a boot loader or a typical OS.  coreboot falls into 
the "firmware" family.

> Sure, but you don't need it ALL OVER YOUR FILESYSTEM.

I'd be willing to bet that 75% of what's contained in an initramfs / 
initrd is already on the root file system.  Especially if the initramfs 
/ initrd is tweaked to the local system.

Taking a quick look at the default initrd of an Ubuntu 16.04 LTS, just 
about everything I see in the following output exists on the system.

/boot/initrd.img-4.4.0-87-generic has 1908 items in it.

129 of them aren't already on the installed system.  Consisting of:

51 /scripts   Probably initrd specific
61 /bin       May be in /sbin /usr/bin /usr/sbin on the local system.
6  /conf      Probably initrd specific
5  /etc
2  /lib
4  misc

Digging further, 29 of the 61 for /bin are in /usr/bin.  12 are in 
/sbin.  That's 88 out of 1908 files in the 
/boot/initrd.img-4.4.0-87-generic file that aren't already all over your 
file system.

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

So, you're saving 88 files (out of 1908) and storing 1820 additional 
copies of files that exist in a container that's not easy to work with.

Why‽

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

How do the files that are needed for the system to operate, being placed 
where they need to be, interfere with the main system?

> Such as?

Allow me to rephrase / clarify slightly.

There have been many things that I've wanted to do in the past 20 yeras 
that the initramfs / initrd from the vendor did not support or was not 
flexible enough to do.

  · Not support root in LVM.
  · Not support root on LUKS.
  · Not support iSCSI disks.
  · Not support root on multi-path.
  · Not supporting the file system (tools).
  · Not support the RAID that (tools).
  · Not support ZFS.
  · Not support root on NFS.

These are just the some of the things that I've wanted to do over the 
years that the initramfs / initrd as provided by the distro did not support.

I have routinely found initramfs / initrd limiting.

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

Yes, /conceptually/ it's Linux (userspace) can do anything that Linux 
can do.  /Practically/ it can only do the things that the distro 
envisioned support for and included in their initramfs / initrd 
management system.

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

(See above.)

> In fact, you could create your super root filesystem that does all 
> the fancy stuff you claim you can't do with an initramfs,

Sure.  I did.  (Time and time again) it was the machine's root file 
system doing exactly what I wanted it to do.

> then create a cpio archive of that root filesystem, and now you have 
> an initramfs which does the job.

Why would I want to copy / permute something that's already working to 
add as an additional layer, which I don't need, complicating the overall 
process‽

> Sure, but only if the kernel can find that disk without any userspace 
> code.

There's a reason I said "if".  The extremely large majority of the 
systems that I've administered over the last 20 years could do that.

> What if that disk is on the other side of an ssh tunnel?

That would be a case where you would actually /need/ an initramfs / initrd.

I'd like to hear tell of someone actually using a root disk that is 
accessed through an ssh tunnel.  Short of that, I'm going to consider it 
a hypothetical.

> If you know the commands to do something, why would you have to wait 
> for somebody else to implement them?

Because I have hundreds of machines that need to be supported by junior 
admins and sticking within the confines of what the distro vendor 
supports is a good idea.

Or more simply, sticking within distro vendor's support period.

> Actually, for most of these the initramfs is the starting 
> root filesystem (just about all linux server installs use one).

Remember, an initramfs / initrd is (or gets extracted to) a directory 
structure.

Just about all of the servers and workstations (mid five digits worth) 
that I've administered over the years end up with a SCSI (SATA / SAS) 
disk off of a controller with the driver in kernel.  Include file system 
and NIC driver too, and you're good to go without an initramfs / initrd. 
  That includes physical and virtual systems.

The containers that I've worked with also end up being a collection of 
files on a file system.

Nope.  Very few of them actually /need/ an initramfs / initrd.

  · LUKS
  · Multipath SAN

Those are the big reasons for a server / workstation to actually /need/ 
an initramfs / initrd.

BlueTooth is not an issue for the servers that I've administered and 
handily enough the notebooks that have had LUKS have also had a keyboard.

> Usually it just mounts a simple filesystem on a local disk as root 
> and then pivots.

Why even bother doing that if it's not actually /needed/?

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

I've never really found what I can pass on the kernel's command line to 
be a problem.

I have had problems where the distro provided initramfs / initrd 
management system lost it's lunch at some things I wanted to put on the 
command line.  But Linux itself was quite happy with it.

> Initramfs is popular because it is way more flexible:

See above.  I've found them to be limiting.

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

That sounds like it's convenient for the distro maintainers.

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

I've been using file system UUIDs on the kernel command line for decades 
without problems.  I've not /needed/ an initramfs / initrd to do that.

> 3.  You can use "exotic" installations like iscsi and so on, which 
> seems pretty useful in an enterprise setting.

One would think.

Sadly, most enterprise admins that I've been around are scared to death 
of booting from the SAN.

The few places that I've seen do it are using Fibre Channel.  Which, 
handily enough, shows up as SCSI directly attached disk.

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

Not really.

My current employer has about fifty different model servers in the 
fleet, from about a dozen different vendors.  We keep about five storage 
drivers in kernel and things just work.

Former employers had about a hundred different models of servers from 
about twenty different vendors.  We had to keep about twenty drivers in 
kernel.

There really wasn't any tailoring.

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

I'm going to go out on a limb and guess that half of them couldn't 
actually tell me how a system boots, from the firmware through init 
scripts to a login prompt.

I'll go further out on a limb and blame that on ignorance and / or 
laziness.  Thankfully it's possible to remediate ignorance if the SA is 
willing.  Also, I'm referring to the bad laziness of I don't care if 
it's less efficient / requires more resources, if it saves me time to 
cut corners.

> What could be more elegant?

Not using something that you don't actually /need/.

> It minimizes the complexity of the kernel

No, it really doesn't.  It might minimize the kernel config.  /Might./

It's quite possible (and in many ways more secure) to run a kernel 
without modules.

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

I can't think of a time in the last ten years where the Linux kernel 
couldn't mount root when the storage driver (and file system) was 
compiled in with proper parameters on the kernel command line.

Root on LUKS, iSCSI, software RAID 5; sure, those things need help. 
Virtually none of the server's I've supported needed any of those for 
root.  Other disks / file systems that were activated via init scripts? 
Sure.



-- 
Grant. . . .
unix || die