> I was trying to explain that "a distribution"
> has to use initrd/ initramfs because of problems specific to
> distribution kernels but that individual users don't have to use this
> mechanism if they don't want to because they can just compile a kernel
> which will work with their hardware (which is usually rather static).
How about Devuan adopting an approach which supports both
explicitly - given that:
1 - freedoorstop.org and the big distributions want to merge
everything into /usr
2 - most big distributions have opaque, non-standard and otherwise
horrible initrd/initramfs systems
For Devuan to resist point 1, it would imply having to build custom
.deb files for large parts of the upstream core system (stripping
out systemd seems enough work already). So how about and alternative
which solves problems 1+2 in one go:
S - Assemble a small initramfs system which resembles a proper root /
filesystem as much as possible (which doesn't contain /usr)
and runs a sensible init process. For starters it really could
just be busybox and a bit of init. Devuan doing its own initramfs
is probably unavoidable anyway - the upstream initramfs might
be too entangled with systemd and udev to be useful or stable.
Depending on user preference and constraints there are then three
options:
A - Users who run custom kernels get to copy/uncpio this filesystem
on to a real partition, and never need run the initrd ever
again.
B - Users on systems with enough RAM run the initrd, but never
do a pivot_root - they just keep the ramdisk around and mount
/usr and whatever filesystems they need.
C - Only really small RAM constrained systems do the pivot root
(and then maybe switch to a disk based copy of /, as per case
A).
This has the nifty property that mkinitrd is less scary - it is
just takes a snapshot of the currently running root filesystem and
runs cpio on it. And it gives people the choice to run an initrd or
not. And it makes the content of the initrd visible. And / has a backup
in the initramfs image. And a disk crash means the system can still run.
Two things have to be solved for this to work though: modprobe
will then need a search path (/lib/modules for the essential ones
needed for boot up, and /usr/lib/modules for the rest) and
persistence for /etc needs to be addressed - some link or bind
mount into /usr or it own partition, a revision controlled
filesystem, something ...
regards
marc