I think almost everyone agrees with you, but it looks like it has happened, so now we (you) need to go on from there ... to stay you need to find appropriate debian repository snapshots that include the needed package versions, and then add those to your sources.list. And you might then also want to have pinning set up to restrict those sources to the particular packages. Alternatively you just download the deb files...

E.g. https://snapshot.debian.org/archive/deb … u1_all.deb is one of them.

EDIT EDIT: I couldn't convince apt-get to use a sources.list line, so I have to stay with advicing you to download the deb file(s).

As you knw, chimaera is "end of life" and there are a couple of newer releases now in play: daedalus, excalibur. How about upgrading?

And, if that snapshot has those debs, it'd be easy for you to add that to your sources list. Would be a way to fix the situation for yourself; your personal merge. if you like.

Yes there is some inconsistency there which might be due to those particular package version are available neither in deb.debian.org nor in archive.debian.org. They apparently where available in deb.debian.org but then have got removed from there and, contrary to expectation, not been placed in archive.debian.org. (Maybe I'm looking in the wrong places ?)

It does look like Devuan's amprolla will need some logic to handle that. Perhaps you would want to assist with that... (how to merge debian packages that get dropped from deb.debian.org without turning up in archive.debian.org). Or you could perhaps get in touch with the debian developers on that issue. Afaict it would affect Debian 11 Bullseye in a similar way.

I think that "documentation" thread does leave out a number of essentials as being assumed rather than stated explicitly, so it's no wonder you have problems.

Firstly, extlinux itself only knows about the one partition that the bootloder resides in, which in your case is /dev/sda1. Therefore all pathnames that you use in the menu declaration are pathnames into that filesystem, which basically is the /boot directory tree without the /boot prefix.

* Does that filesystem have a pathname /vmlinuz that identifies the linux kernel to load?
* Does that filesystem have a pathname /initrd.img that identifies the initrd to use?
* Is that filesystem really a root filesystem?

From you ascii graphics it looks like the /dev/sda1 filesystem is normally mounted on /boot of your actual root filesystem, which you spin up from an encrypted logical volume within the /dev/sda5 partition, and it's rather there one would expect to find those pathnames /vmlinuz and /initrd.img (as symbolic links into /boot).

They are thus not available for use by the extlinux bootloader. Rather you need to provide the pathnames to the kernel and initrd as they are within the /dev/sda1 filesystem; it would be something like /vmlinuz-6.12.95-amd64 and /initrd.img-6.12.95-amd64, depending on which versions.

Note that the toplevel of that filesystem (on /dev/sda1) is "normally" mounted on /boot, and the /boot prefix is part of "the normal root" filesystem rather than of the filesystem on /dev/sda1.

The third problem is that your declaration tells the booting kernel to try to mount /dev/sda1 as root filesystem, which of course fails. Rather, you need the initrd set up the decrypting device /dev/mapper/sdb5_crypt for the logical volume system to use, and then your actual root filesystem would be found using the LVM name /dev/userr-vg-root (or similar; I don't use LVM).

In parenthesis, I think it's confusing to use name sdb5_crypt for an encryption of /dev/sda5, especially as you apparently also have an /dev/sdb.

Anyhow, other than that confusion about pathnames it should all work fine.

Btw. please use bbcode markup around "code" portions to make them clearer.

The "what" is easy, the "who" is hard.

@greenjeans that's just stupid.

@fsmithred, tt of course depends on which hibernate-resume pathway you actually are using. Some go via pm-utils and for that you may check out man pm-hibernate. Or maybe you rely on logind in which case you'd check out man loginctl instead.

dev1galaxy.org is a "discussion forum", not a "blog site" ot "wiki".

If someone can articulate a sane, useful reason for having it accurately numbering IP addresses, I would imagine me be happy to assist that person in polishing the php concerned towards a behaviour that they would would deem accurate.

The field of study is called "Character Encoding", grounded in the particular mechanisms in use in your circumstances.

The Xorg run log looks perfectly ideal   and yes, BusID is for PCI address selection only; I think it might be possible to declare a PrimaryGPU option in an OutputClass section (replacing the Device section I think) with a MatchDriver directive (perhaps MatchDriver "V3D"), but I didn't want to pursue that line of thought. Check man xorg.conf.

The gnome-map issue is at "user level"; the program tries to allocate GPU memory and fails. My googling (or DuckDuckGo-ing actually) led to the raspian(?) solution of adding gpu_mem=512 in some config.txt file somewhere, or via the program raspi-config. I think that particular setting would let the GPU use 512 Mb of RAM, and the hope is then that that is enough for a mortal.

Some people seemed to refer to the same setting as kernel boot parameter cma=512m. Possibly that's an alternative.

In fact, perhaps either memory setting actually supercedes the "noOutputInitialSize" setting, which also related to the GPU RAM; or maybe they just are two different blisters on the same foot.

Did you try the device section I suggested as well?

Section "Device"
    Identifier "DRM"
    Driver "modesetting"
    Option "AccelMethod"    "glamor"
    Screen 0
EndSection

In my understanding both the Screen association and the Driver association are important. The Screen setting tells Xorg to use that Device specification for that default screen. The Driver setting tells Xorg that it concerns the modesetting driver. You would stll have the nomodeset boot parameter so as to tell the modesetting driver to avoid setting modes but rather rely on the default behaviour based on the monitor EDID.

I'm guessing you know more about this than I, but I would consider moving back settings from your previous xorg.conf to see if there's a working subset. I.e., whether possibly the newer Xorg version has some sensitivity to your settings... my first test would be to add a file /etc/X11/xorg.conf.d/device.conf with your device setup for screen 0, but then avoid disabling backing store and avoid binding it to the specific monitor configuration. The file would be like this:

Section "Device"
    Identifier "DRM"
    Driver "modesetting"
    #Option "BackingStore" "false"
    #Option "Monitor-HDMI-1" "AL1716"
    Option "AccelMethod"    "glamor"
    Screen 0
EndSection

The purpose with that would be to steer Xorg towards using the sub-module glamoregl which by my reading of the first log makes V3D be used.

(I guess you already have a .conf file in that directory with the InputClass specifications)