Re: Running Debian without initramfs?
On Fri, 9 Jun 2023 at 05:38, <tomas@tuxteam.de> wrote:
>
> On Thu, Jun 08, 2023 at 09:57:31PM +0100, James Addison wrote:
>
> [...]
>
> > Naturally a block device isn't a game cartridge - the former could
> > contain many different operating systems, with the potential for
> > dynamic resizing. But it feels like we haven't landed on the simplest
> > way to approximate the straightforward (and I think generally fairly
> > efficient and safe) experience of choosing and loading game cartridges
> > with boot configuration. It's not a criticism of Debian per-se - we
> > are following standards as opposed to setting them.
>
> What you should consider is that this initramfs setup allows you to
> pull the disk from your (possibly dead) computer and stuff it into
> some other (with hopefully similar architecture) and you have at
> least a fair chance that the thing will boot, because at initramfs
> time some modules are magically available.
>
> And even if things have changed a bit, you are dropped into a
> command line where you may fix things.
>
> Stuff like encrypted root partitions and similar are made much
> easier this way, too.
Thanks, tomas. I agree that disk portability is useful and should
continue to be a goal.
In the game-cartridge analogy, the initrd seems something like an
adapter that allows the same game cartridge to run on multiple similar
game consoles. But almost every game cartridge has one, and they're
continually being updated, and they're rarely mixed-and-matched (it's
rare for me to borrow an initramfs from a friend). In terms of system
design (and user understanding), it makes me wonder whether there
could be a better and simpler way.
(in terms of practicalities: I realize that if there were no
initrd/initramfs, then the kernel would need to know or be able to
load a (standard?) module in order to read the target filesystem. the
former module could either be compiled-in (but that could reduce
filesystem diversity), or it could be loaded from the 'true' root
filesystem block device extents somehow. if the latter, then it'd be
nice if it was based on a mechanism that allows for variable size of
module content, because /boot partitions for example fill up over
time, and generally speaking it seems awkward to divide a single block
device into two simply for the purposes of storing 'some boot stuff'
if the size of the stuff-partition is static and all of the (even
unused) space for it becomes unusable to the filesystem on the same
device)
Reply to: