Re: [gentoo-user] RAID-1 on secondary disks how?

[Grant Taylor]

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