With ifupdown, bridges get set up by the /etc/network/if-pre-up.d/bridge script when that script detects that the iface block has a bridge_ports setting. That script is provided by the bridge-utils package which nowadays is "optional", so perhaps it's not installed?

Bridges are of course available as kernel networking elements regardless of that package, and the ip command operates on the kernel elements.

Generally speaking, the ifup and ifdown commands are tunable and extensible by means of scripts/programs in the /etc/network/if-* directories which all get invoked when interfaces are brought up or down by those commands. See man interfaces for more.

The ip command only operates on the kernel's networking setup and it does not make use of ifupdown. It's rather the opposite, that ifupdown scripts (and built-in functions) make use of ip to effectuate declared configurations.

You need to use Devuan's debootstrap (not Debian's).

Thanks, I think it does require coding though.

Generally a debconf dialog (set) is driven by a control script (typically an sh (dash) script) with successions of dialog building "commands", possibly in groups with intermediate decision logic. In this case it might be simply a single dialog for asking whether to use eudev or vdev, although designed so as to allow for expansion with further options. Then there would also be code for effectuating the choice at the appropriate time during an installation. I haven't thought about it in detail.

The debconf subsystem kicks in during package installation just prior to the processing of the postinst script. Thus this choice dialog software would be made as a package to be "automatically" installed so it then brings up the dialog. This would be similar to other debconf dialogs, and that is really the reason for implementing within that paradigm. I suppose the point is to fit it into the current installer framework which therefore requires a bit of learning about that framework.

There is also a point in that "hotplug handling" is kind of a forgotten concept area where a single solution (udev) has become unduly dominant whilst having grown into a rather opaque complexity. Perhaps one would be better off with something less opaque and complex?

Have we found the bottom now?
Or should I be less pessimistic?
Maybe jokes can always be worse...

I don't have your setup so can't say for sure, but experimented a little with the installer's partitioning dialogs.

It sure does seem that the partman developers try to be clever about the "EFI System Partition" and exclude the offer to erase a pre-existing ESP.

So instead you'll need to fiddle with the shell at that point, which of course is far from ideal. Basically enter the shell with C-A-F2 and erase the partition with dd.

The traffic shaping uses cbp and sfq (which are the queue types used) so you'll need the modules.

eth0 etc is the name of the interface assigned by the kernel module. All the rest are done afterwards, typically via udev rule(s). It may have been due to that eventually (with bookworm) udev has got programmed to generate specific naming rules for itself into /etc/udev/rules.d/ that then apply subsequently regardless of boot options. It requires a bit of "surgery" of the udev rules to get rid of that.

There is a web site, https://packages.debian.org/index, where one can search for details about debian packages. net-tools does exist in bookworm (version 2.10-0.1) so apparently Rackspace applies some "we know best" filter on package availabiility. I would choose some other mirror.

Have you made sure the kernel modules are available (like sch_cbq, sch_sfq and sch_ingress)? Or maybe it's a udev issue, and the modules need to be loaded manually?

Did you install it? It does depend on iproute2 (or iproute)

And then if this is ceres rather than daedalus anything (else) is possible

@semil, whan I just now installed gpm and tried it on a console, it happily responded to tapping as clicking. It's missing out on other fancy stuff that I've set up on synclient for X11 but it handls single, double tripple taps well.

Have you verified that /etc/gpm.conf says device=/dev/input/mice (and type=exps2) ?

Note that each desktop environment, whether it is kde or xfce or lxqt, is a largish stack of packages that have been made to work together, and in some cases the different desktop environments have competing demands of packages. Basically as a concept, having multiple DE's installed is not like having a house with many rooms, but more like having a single-room house with several collections of furniture in it.

E.g. one fundamental competition with your DE collection is wether the display server is Xorg or Wayland (some require the one or the other, some kind of work with either) and there are numerous of conflicting demands stemming from that. And I believe slim if you've installed that requires Xorg whereas sddm might handle either Xorg or Wayland although might need configuration choice about which to use.

Afaik startx is a completely different program which is supposed to run an Xorg as display server, and then have the desired auto-started programs nominated in an .xinitrc (or something similar).

I think you would have an easier task if you go back and rather make a single choice than pile up multiple options without bothering about or knowing how they compete.