Re: Running Debian without initramfs?
On Fri 09 Jun 2023 at 13:12:36 (+0100), James Addison wrote:
> On Fri, 9 Jun 2023 11:52:28 +0100, <deblis@lionunicorn.co.uk> wrote:
> > On Fri 09 Jun 2023 at 10:44:23 (+0100), James Addison wrote:
> > > (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.
> > > [ … ]
> > You seem to be keen to invent something. But the invention (initramfs)
> > has already been invented. If you read around the topic in some depth,
> > you'll perhaps realise the benefits it brings.
> >
> > BTW, loading stuff from the 'true' root in the absence of the
> > initramfs (or being compiled in already) merely begs the question.
> I have to admit that I've never completely understood the phrase/idiom
> 'begs the question'. It seems to be misinterpreted relatively often,
> so I wonder if it too could be refactored.
You made a circular argument, hinted at by the word "somehow".
To load a module from the 'real' root filesystem, you need to mount
it, which is precisely what you're trying to do in the first place.
> I think the design has worked extremely well and provides plenty of
> versatility. The success of various operating system distributions
> following this model demonstrates that fairly comprehensively, I
> think.
>
> I'd see (re)invention as an antipattern for a system like that. But
> if it's possible to refactor it into something that maintains the same
> benefits while being simpler to understand and maintain, runs less
> code during system startup, and can simplify operating system
> backup/inspection/transfer/restore operations, then I think it could
> be worth considering.
Running less code might have to be weighed against compiling in more
code, or else losing the flexibility gained by only loading what you
actually need at run/startup time.
But you could work on designing/refactoring a system without writing
any actual code to implement it. Perhaps have a go?
> Also agree that I should learn more about it in depth, and that it's
> possible that I'll end up realizing that it's a near-optimal solution
> already.
Cheers,
David.
Reply to: