On Fri, 9 Jun 2023 11:52:28 +0100, <deb...@lionunicorn.co.uk> wrote: > On Fri 09 Jun 2023 at 10:44:23 (+0100), James Addison wrote: > > On Fri, 9 Jun 2023 at 05:38, <to...@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. > > > > 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) > > 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 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. 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. 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. On Fri, 9 Jun 2023 at 10:44, James Addison <j...@jp-hosting.net> wrote: > > On Fri, 9 Jun 2023 at 05:38, <to...@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)
