Re: Running Debian without initramfs?

[tomas]

On Fri, Jun 09, 2023 at 05:52:48PM +0100, mick.crane wrote:
> On 2023-06-08 19:08, Mike Castle wrote:
> 
> > I couldn't afford a large enough harddrive for the second system, nor
> > ethernet cards (and a local shop was going to charge me $50 to make a
> > crossover cable if I went that route!).
> 
> swapping around the red and red-white with the green and green-white wires
> seemed to work.
> mick

Wait... Ethernet crossover cables? You must have vintage hardware.
Most twisted pair Ethernet ports these days support Auto MDI-X [1]
so they do the crossover thingy themselves.

To find out, you do:

  tomas@trotzki:~$ sudo ethtool eth0
  [sudo] password for tomas: 
  Settings for eth0:
Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes:  10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Auto-negotiation: on
Port: Twisted Pair
PHYAD: 2
Transceiver: internal
MDI-X: Unknown (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x0007 (7)
   drv probe link
Link detected: no

...and look at the line "MDI-X: ...". In my case "Unknown" means that
there's nobody at the other end, "(auto)" means that my interface is
willing to bargain. NB: this is on pretty old hardware, a Thinkpad
X230, roughly from early 2010s.

Cheers

[1] https://en.wikipedia.org/wiki/Auto_MDI-X

-- 
t




signature.asc
Description: PGP signature

Re: Running Debian without initramfs?

[David Wright]

On Fri 09 Jun 2023 at 13:12:36 (+0100), James Addison wrote:
> On Fri, 9 Jun 2023 11:52:28 +0100,  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.

Re: Running Debian without initramfs?

[mick.crane]

On 2023-06-08 19:08, Mike Castle wrote:


I couldn't afford a large enough harddrive for the second system, nor
ethernet cards (and a local shop was going to charge me $50 to make a
crossover cable if I went that route!).


swapping around the red and red-white with the green and green-white 
wires seemed to work.

mick

Re: Running Debian without initramfs?

[Stefan Monnier]

> 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.

I've also often used the iniramfs as a kind of "rescue disk" when my
system failed to boot for a reason or another.  I also use it when
I need to rename the VG of my root disk (tho I can't see why LVM
doesn't let me rename those things live).


Stefan

Re: Running Debian without initramfs?

[James Addison]

On Fri, 9 Jun 2023 11:52:28 +0100,  wrote:
> On Fri 09 Jun 2023 at 10:44:23 (+0100), James Addison wrote:
> > On Fri, 9 Jun 2023 at 05:38,  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  wrote:
>
> On Fri, 9 Jun 2023 at 05:38,  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 

Re: Running Debian without initramfs?

[David Wright]

On Fri 09 Jun 2023 at 10:44:23 (+0100), James Addison wrote:
> On Fri, 9 Jun 2023 at 05:38,  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)

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.

Cheers,
David.

Re: Running Debian without initramfs?

[James Addison]

On Fri, 9 Jun 2023 at 05:38,  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)

Re: Running Debian without initramfs?

[tomas]

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.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Running Debian without initramfs?

[Michel Verdier]

On 2023-06-08, James Addison wrote:

> Basically what I'm wondering about is whether there's some kind of
> future utopia where operating system filesystem images -- and the
> process of managing and booting from them -- could be made
> significantly simpler.

You can already do that. Compile a kernel with all drivers needed and it
will boot without initramfs. Initramfs is still usefull in a lots of
special situations. So it's not an utopia it's a real thing: we have the
better from both world.

Re: Running Debian without initramfs?

[James Addison]

On Thu, 08 Jun 2023 17:13:30 +0200, Sven wrote:
> On 2023-06-08 15:41 +0100, James Addison wrote:
>
> > Does anyone have experience running Debian systems without using an 
> > initramfs?
>
> I did this in the distance past, some 15 years ago or so.  Have long
> abandoned that idea, though.
>
> > I'd be particularly keen to hear about laptop/desktop/server systems,
> > because I think that a large motivating factor to use initramfs --
> > across many distributions -- was to provide a mechanism
> > outside-the-compiled-kernel to load additional device driver modules,
> > and I'd like to check that that motivation is still valid.
>
> s/device driver//
>
> Loading modules via an intramfs is crucial for a distro kernel, because
> the only alternative would be to compile in support for dozens of
> filesystems that users might want to use as their root filesystem.

Thanks for the response and correction.

So, in order to load a chain of kernel modules (block I/O, logical
disk management, filesystem, ...) that can read the system's 'true'
root filesystem, we frequently (for example, after installation of
some packages) rebuild a second, separate root filesystem (the
initramfs), written according to a built-in kernel filesystem format,
and then subsequently re-read (often from a separate block device) and
re-evaluate the code from that filesystem at each system boot.

(further corrections may be required)

That was my understanding from around the same time you last loaded a
system without an initramfs, and it puzzled me a bit, but I let it
pass (there are only so many technical things that it's possible to
care about, especially with full-time employment).

Basically what I'm wondering about is whether there's some kind of
future utopia where operating system filesystem images -- and the
process of managing and booting from them -- could be made
significantly simpler.

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.

I guess I'm curious whether it could be time to start reversing the
polarity of some open source development experience to feed them back
into simpler standards that provide what we want while discarding the
cruft that doesn't -- based on practical and proven experience --
doesn't work so well.

Re: Running Debian without initramfs?

[Mike Castle]

On Thu, Jun 8, 2023 at 10:50 AM Greg Wooledge  wrote:
> Merged-usr is officially mandated for bookworm, and upgrades to bookworm
> will do the merge, if it hasn't already happened.

End of an era.  My first Linux system (predating the existence of
Debian), mounted /usr over NFS over PLIP.

I couldn't afford a large enough harddrive for the second system, nor
ethernet cards (and a local shop was going to charge me $50 to make a
crossover cable if I went that route!).



Anyway, I think it is also pretty common to install merged-usr on LVM
as well, which I think is another reason to need initramfs.

mrc

Re: Running Debian without initramfs?

[Greg Wooledge]

On Thu, Jun 08, 2023 at 06:34:36PM +0100, Tim Woodall wrote:
> IIUC trixy will enforce merged-usr, it's optional until then. (bicbw, it
> might be bookworm that will enforce it - all my systems are already
> merged and I don't run testing)

Merged-usr is officially mandated for bookworm, and upgrades to bookworm
will do the merge, if it hasn't already happened.

:

In February 2021, the Technical Committee has resolved that Debian
'bookworm' should support only the merged-usr root filesystem layout,
dropping support for the non-merged-usr layout. (978636)

The transition started on September 17th, 2022, by making
init-system-helpers depend on usrmerge.

Re: Running Debian without initramfs?

[Tim Woodall]

On Thu, 8 Jun 2023, James Addison wrote:


Hi folks,

Does anyone have experience running Debian systems without using an initramfs?

I'd be particularly keen to hear about laptop/desktop/server systems,
because I think that a large motivating factor to use initramfs --
across many distributions -- was to provide a mechanism
outside-the-compiled-kernel to load additional device driver modules,
and I'd like to check that that motivation is still valid.

Thanks,
James


I don't know for certain but I think running without initramfs is
'unsupported'. Some of the discussion around merged-usr has been
predicated on /usr always being mounted.

If you want to do this then at the very least I think /usr will have to
be on the root filesystem and I don't know if it will be possible at all
without a custom kernel.

IIUC trixy will enforce merged-usr, it's optional until then. (bicbw, it
might be bookworm that will enforce it - all my systems are already
merged and I don't run testing)

Re: Running Debian without initramfs?

[Michel Verdier]

On 2023-06-08, James Addison wrote:

> Does anyone have experience running Debian systems without using an initramfs?
>
> I'd be particularly keen to hear about laptop/desktop/server systems,
> because I think that a large motivating factor to use initramfs --
> across many distributions -- was to provide a mechanism
> outside-the-compiled-kernel to load additional device driver modules,
> and I'd like to check that that motivation is still valid.

I once compiled custom kernels for servers, including all (and only)
necessary drivers, and deactivating initramfs. I succesfully redo this
recently. It gave a smaller and quicker boot. But now I get back to
initramfs for encrypted partitions. There is also the microcode early
loading.

Re: Running Debian without initramfs?

[Sven Joachim]

On 2023-06-08 15:41 +0100, James Addison wrote:

> Does anyone have experience running Debian systems without using an initramfs?

I did this in the distance past, some 15 years ago or so.  Have long
abandoned that idea, though.

> I'd be particularly keen to hear about laptop/desktop/server systems,
> because I think that a large motivating factor to use initramfs --
> across many distributions -- was to provide a mechanism
> outside-the-compiled-kernel to load additional device driver modules,
> and I'd like to check that that motivation is still valid.

s/device driver//

Loading modules via an intramfs is crucial for a distro kernel, because
the only alternative would be to compile in support for dozens of
filesystems that users might want to use as their root filesystem.

Cheers,
   Sven

Running Debian without initramfs?

[James Addison]

Hi folks,

Does anyone have experience running Debian systems without using an initramfs?

I'd be particularly keen to hear about laptop/desktop/server systems,
because I think that a large motivating factor to use initramfs --
across many distributions -- was to provide a mechanism
outside-the-compiled-kernel to load additional device driver modules,
and I'd like to check that that motivation is still valid.

Thanks,
James