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
