On 01/29/2019 12:01 PM, Rich Freeman wrote:
Not sure why you would think this. It is just a cpio archive of a root
filesystem that the kernel runs as a generic bootstrap.
IMHO the simple fact that such is used when it is not needed is ugly part.
This means that your bootstrap for initializing your root and everything
else can use any userspace tool that exists for linux.
Why would I want to do that if I don't /need/ to do that?
I can use IPs on VXLAN VTEPs to communicate between two hosts in the
same L2 broadcast domain too. But why would I want to do that when the
simple IP address on the Ethernet interface will suffice?
A similar concept lies at the heart of coreboot - using a generic
kernel/userpace as a firmware bootloader making it far more flexible.
Coreboot is not part of the operating system.
If you want to talk about the kernel in coreboot taking over the
kernel's job and removing the boot loader + (2nd) kernel, I'm interested
in discussing.
An initramfs is basically just a fairly compact linux distro. It works
the same as any distro.
IP over the VXLAN VTEP works the same as IP over Ethernet too.
The simple fact that there are two distros (kernel & init scripts) that
run in succession when there is no /need/ for them is the ugly bit.
Why stop at two distros? Why not three or four or more?
The kernel runs init, and init does its thing. By convention that init
will mount the real root and then exec the init inside, but it doesn't
have to work that way. Heck, you can run a system with nothing but an
initramfs and no other root filesystem.
You can also run a system in the halt run level with everything mounted
read-only. I used to run firewalls this way. Makes them really hard to
modify without rebooting and altering how they boot. }:-)
Linus would disagree with you there, and has said as much publicly.
He does not consider initialization to be the responsibility of kernel
space long-term, and prefers that this happen in user-space.
~chuckle~ That wouldn't be the first or last time that Linus disagreed
with someone.
Some of the lvm and mdadm support remains for legacy reasons, but you
probably won't see initialization of newer volume/etc managers supported
directly in the kernel.
That is news to me. Obviously it needs whatever drivers it needs, but
I don't see why it would care if they are built in-kernel vs in-module.
O.o‽
How is a kernel going to be able to mount the root file system if it
doesn't have the driver (and can't load) for said root file system type?
Or how is it going to extract the initramfs if it doesn't have the
driver for a ram disk?
The kernel /must/ have (at least) the minimum drivers (and dependencies)
to be able to boot strap. It doesn't matter if it's boot strapping an
initramfs or otherwise.
All of these issues about lack of a driver are avoided by having the
driver statically compiled into the kernel.
IMHO a kernel and a machine is quite a bit more secure if it doesn't
support modules. Almost all of the root kits that I've seen require
modules. So the root kits are SIGNIFICANTLY impeded if not completely
broken if the kernel doesn't support modules.
Sure, if you want to know exactly how it works that is true, but the
same is true of openrc or any other piece of software on your system.
Yep.
I think it's a LOT easier to administer a system that I understand how
and why it works.
Dracut is highly modular and phase/hook-driven so it isn't too hard
to grok. Most of it is just bash/dash scripts.
That may be the case. But why even spend time with it if it's not
actually /needed/.
--
Grant. . . .
unix || die
