You are not logged in.
Did you install xserver-xorg-video-* package(s)?
Who is running startx; root or non-root?
The short story is "yes, install seatd; log out and log in". That will make you run Xorg while avoiding the buggy code path of logind.
The long story is longer but who cares?
How did you install? Which desktop environment did you choose? How have you got so many packages from "unknown" (especially both the nouveau and nvidia modules)?
You might try to reinstall libc6; version 2.31 is from chimaera:
apt-get install --reinstall libc6But be sure to have a rescue boot at hand, just in case, because it's a rather fundamental system transition. Otoh it should have happened on the upgrade... did you "dist-upgrade" at all?
Ok. Remove the link /usr/lib/x86_64-linux-gnu/libc.so.6 and run (as root)
# ldconfigwhich usually does good things to the libraries. You might also need to set a new link (as root)
# ln -sTf /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux-gnu/libc.so.6to sort out that dangling one.
I would think this all has to do with system differences between bullseye and daedalus (bookworm), and yet it's peculiar that only expr brings a problem.
Ok. Some of those "libraries" are actually "ld scripts" rather than actual libraries; though I don't have a clear idea how it works... try:
$ find /usr/lib* /lib* -name libc.so\* | xargs ls -l to get an overview of the "mess" ![]()
It's still peculiar that only expr is affected.
Peculiar. Try running
$ LD_DEBUG=all exprwhich should dump a haystack of goodies from the ELF loader. At a glance the problem appears to be with the ELF loader but I would then have expected it to concern all programs.
The haystack should include lines like
17051: checking for version `GLIBC_2.34' in file /lib/x86_64-linux-gnu/libc.so.6 .... Those indicate the particular ABI versions that the program requires. The hope is that there is some clue for the problem towards the end of it.
It looks to me that the general commercial drive is to make Linux a platform for "Apps", probably so that middlemen can own the distribution channels and siphon money of both developers and end users. The wayland protocol would form part of that as a way of isolating "Apps" from each other rather than providing the well integrated computing platform that was/is one of the drivers behind X11.
@Fierelier: yes, the Devuan repository is an "on-the-fly merge" of Debian packages that uses the packages directly from Debian repositories (except for the "forked" packages). I.e., Devuan only maintains and builds forked packages, and relies on Debian doing that for the rest.
In essence Devuan is simply a re-indexing of which packages are included and where to download them; forked packages from Devuan and all other packages from Debian. Thus, if Debian stops maintaining and building i386 packages, Devuan will follow.
bootlogd, if installed, kicks in after the devnodes are set up.
Iif you have another computer, you could set up a netconsole and then capture it there. Possibly with some clever hands-on, you could point that to a localhost console started (as early as possible) by initrd scripting. That would of course only capture from when that console starts.
Any bootloader (or earlier) output before the kernel is started might require a video camera, possibly even a fast-recording one.
Yes, that's due to the infamous "usrmerge" nonsense of Debian... they are in the process of moving stuff from /bin into /usr/bin because they think that everyone has set up links like /bin -> /usr/bin... and more. Web searching will tell.
You could have used --merged-usr for debootstrap and it would have configured the root filesystem with those stupid-links.
To come to there afterwards involves some manual copying hands-on and in particular a serious quirk in order to change /lib/ to a link without losing sight of the elf loader (e.g. /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2).
It might be possible to debootstrap if you add
--exclude=logrotate,cron,cron-common-daemonto the command.
Ok. I'm really not sure which efivars files (aka "variables") can be deleted so a to recover space, but at least the most important ones are "immutable" (see with lsattr). Perhaps there are a couple of unused boot options?
You should back them up before experimenting!
Ah yes, you also need to
mount -t efivarfs none /sys/firmware/efi/efivarsYou'll need to mount the EFI partition on /boot/efi.
Note that the /dev/dri/* devnodes should be in group video and the same for /dev/fb0; group video with read+write access. They are made so by eudev, so the first guess would be that you are using some other hotplug handler which fails to do so.
The second part of that is that the user also needs to be in group video.
"the mail system at host april.topoi.pooq.com" has broken DNS.
cryptsetup-initramfs is not a forked package, so you should report to bugs.debian.org rather.
Perhaps if you avoid removing libpulse-mainloop-glib0 it might not remove xfce4 and hopefully retain that which you will want to retain.
btw, such output you should rather wrap as "code" than "quote" which would have made a scrolling element instead of a full two pages with such "nothingness".
Presumably some residue from incompletely removed packages, but there is something claiming to be systemd-udevd in the log. Check for /lib/systemd/systemd-udevd and /ur/lib/systemd/systemd-udevd and remove that, and restart.
The other udevd logs (apparently competing with the extraneous systemd-udevd) belong to the eudev package, which I would have thought you installed as replacement. If not, then you have to chase up which binary is involved and where it comes from. Something like this (as root) perhaps:
# find /bin /sbin /lib /usr -name '*udev*[ 1.648553] systemd-udevd[197]: starting version 3.2.14I don't think you should run both udev and eudev!! (It looks like you do)
Get rid of systemd-udevd first. But if that doesn't fix it we should look further.
Which permissions does it have/get and which permissions would you want?
Do you use eudev?
Maintainer: Marco d'Itri <md@linux.it> ... hubris and deliberate intent to cause trouble.
Afaict, assuming you have eudev installed, the mode for /dev/dri/renderD128 would be set b.m.o line 42 in /lib/udev/rules.d/50-udev-default.rules.
Answer about seatd and elogind would start with asking which "service managment" you are using; (apparently not sysvinit?)
About apt using ipv4 there's web results like this, suggesting by example:
sudo apt-get -o Acquire::ForceIPv4=true install pkg
sudo apt-get -o Acquire::ForceIPv4=true update
sudo apt-get -o Acquire::ForceIPv4=true upgrade
sudo apt-get -o Acquire::ForceIPv4=true dist-upgrade
sudo apt-get -o Acquire::ForceIPv4=true install kshMaintaner: Anibal Monsalve Salazar <anibal@debian.org>
Like for sed, maintainer Clint Adams <clint@debian.org>, the only motivations for those moves are hubris and deliberate intent to cause trouble.