You are not logged in.
Pages: 1
Hello everybody.
I moved to Devuan from Debian Bullseye some weeks ago to get rid of systemd and usrmerge which caused my server to go bananas. The migration was quite smooth, but since some time I keep getting an error from "expr" executable, from coreutils:
expr: /usr/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by expr)
Devuan Daedalus updated:
coreutils 9.1-1
libc6 and libc6-dev 2.36-9+deb12u3
Now, GLIBC_2.34 is old I can speculate it's something related to the previous version of Debian, but I don't get why expr is looking for old components. So far, it is the only executable which gives that error, but I remember something similar immediately after migrating form Bullseye, unfortunately I don't remember anymore.
The error appears when running expr, both directly in terminal or inside a script.
Any clue? Thank you
Offline
This should give some more info:
which expr
On my system it's /usr/bin/expr (substitute below if it's not there). There might be an old version somewhere.
ls -l /usr/bin/expr
file /usr/bin/expr
ldd /usr/bin/expr
Post results here if that doesn't get you any further.
Offline
Tnx.
expr is in /usr/bin:
ls -l /usr/bin/expr
-rwxr-xr-x 1 root root 117808 20 set 2022 /usr/bin/expr
file /usr/bin/expr/
usr/bin/expr: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=b919757cbc30fbb64b14498222499d972fd80acd, for GNU/Linux 3.2.0, stripped
ldd /usr/bin/expr
/usr/bin/expr:
/usr/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /usr/bin/expr)
linux-vdso.so.1 (0x00007fff2b95c000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f45159ab000)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f45157d6000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4515a4c000)
Offline
Peculiar. Try running
$ LD_DEBUG=all expr
which 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.
Offline
Thank you. The output is:
10969: symbol=__vdso_clock_gettime; lookup in file=linux-vdso.so.1 [0]
10969: binding file linux-vdso.so.1 [0] to linux-vdso.so.1 [0]: normal symbol `__vdso_clock_gettime' [LINUX_2.6]
10969: symbol=__vdso_gettimeofday; lookup in file=linux-vdso.so.1 [0]
10969: binding file linux-vdso.so.1 [0] to linux-vdso.so.1 [0]: normal symbol `__vdso_gettimeofday' [LINUX_2.6]
10969: symbol=__vdso_time; lookup in file=linux-vdso.so.1 [0]
10969: binding file linux-vdso.so.1 [0] to linux-vdso.so.1 [0]: normal symbol `__vdso_time' [LINUX_2.6]
10969: symbol=__vdso_getcpu; lookup in file=linux-vdso.so.1 [0]
10969: binding file linux-vdso.so.1 [0] to linux-vdso.so.1 [0]: normal symbol `__vdso_getcpu' [LINUX_2.6]
10969: symbol=__vdso_clock_getres; lookup in file=linux-vdso.so.1 [0]
10969: binding file linux-vdso.so.1 [0] to linux-vdso.so.1 [0]: normal symbol `__vdso_clock_getres' [LINUX_2.6]
10969:
10969: file=libgmp.so.10 [0]; needed by expr [0]
10969: find library=libgmp.so.10 [0]; searching
10969: search path=/usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/x86_64/x86_64:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu (system search path)
10969: trying file=/usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64/libgmp.so.10
10969: trying file=/usr/lib/x86_64-linux-gnu/tls/x86_64/libgmp.so.10
10969: trying file=/usr/lib/x86_64-linux-gnu/tls/x86_64/libgmp.so.10
10969: trying file=/usr/lib/x86_64-linux-gnu/tls/libgmp.so.10
10969: trying file=/usr/lib/x86_64-linux-gnu/x86_64/x86_64/libgmp.so.10
10969: trying file=/usr/lib/x86_64-linux-gnu/x86_64/libgmp.so.10
10969: trying file=/usr/lib/x86_64-linux-gnu/x86_64/libgmp.so.10
10969: trying file=/usr/lib/x86_64-linux-gnu/libgmp.so.10
10969:
10969: file=libgmp.so.10 [0]; generating link map
10969: dynamic: 0x00007f1978e58ce0 base: 0x00007f1978dd9000 size: 0x0000000000080ba8
10969: entry: 0x00007f1978dd9000 phdr: 0x00007f1978dd9040 phnum: 9
10969:
10969:
10969: file=libc.so.6 [0]; needed by expr [0]
10969: find library=libc.so.6 [0]; searching
10969: search path=/usr/lib/x86_64-linux-gnu (system search path)
10969: trying file=/usr/lib/x86_64-linux-gnu/libc.so.6
10969:
10969: file=libc.so.6 [0]; generating link map
10969: dynamic: 0x00007f1978dd2b80 base: 0x00007f1978c04000 size: 0x00000000001d4680
10969: entry: 0x00007f1978c27e40 phdr: 0x00007f1978c04040 phnum: 12
10969:
10969: checking for version `GLIBC_2.3.4' in file /usr/lib/x86_64-linux-gnu/libc.so.6 [0] required by file expr [0]
10969: checking for version `GLIBC_2.14' in file /usr/lib/x86_64-linux-gnu/libc.so.6 [0] required by file expr [0]
10969: checking for version `GLIBC_2.4' in file /usr/lib/x86_64-linux-gnu/libc.so.6 [0] required by file expr [0]
10969: checking for version `GLIBC_2.26' in file /usr/lib/x86_64-linux-gnu/libc.so.6 [0] required by file expr [0]
10969: checking for version `GLIBC_2.34' in file /usr/lib/x86_64-linux-gnu/libc.so.6 [0] required by file expr [0]
10969: /usr/lib/x86_64-linux-gnu/libc.so.6: error: version lookup error: version `GLIBC_2.34' not found (required by expr) (continued)
expr: /usr/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by expr)
10969: checking for version `GLIBC_2.2.5' in file /usr/lib/x86_64-linux-gnu/libc.so.6 [0] required by file expr [0]
10969: checking for version `GLIBC_2.3' in file /usr/lib/x86_64-linux-gnu/libc.so.6 [0] required by file expr [0]
10969: checking for version `GLIBC_2.3' in file /usr/lib/x86_64-linux-gnu/libc.so.6 [0] required by file /usr/lib/x86_64-linux-gnu/libgmp.so.10 [0]
10969: checking for version `GLIBC_2.14' in file /usr/lib/x86_64-linux-gnu/libc.so.6 [0] required by file /usr/lib/x86_64-linux-gnu/libgmp.so.10 [0]
10969: checking for version `GLIBC_2.4' in file /usr/lib/x86_64-linux-gnu/libc.so.6 [0] required by file /usr/lib/x86_64-linux-gnu/libgmp.so.10 [0]
10969: checking for version `GLIBC_2.7' in file /usr/lib/x86_64-linux-gnu/libc.so.6 [0] required by file /usr/lib/x86_64-linux-gnu/libgmp.so.10 [0]
10969: checking for version `GLIBC_2.2.5' in file /usr/lib/x86_64-linux-gnu/libc.so.6 [0] required by file /usr/lib/x86_64-linux-gnu/libgmp.so.10 [0]
10969: checking for version `GLIBC_2.3.4' in file /usr/lib/x86_64-linux-gnu/libc.so.6 [0] required by file /usr/lib/x86_64-linux-gnu/libgmp.so.10 [0]
10969: checking for version `GLIBC_2.3' in file /lib64/ld-linux-x86-64.so.2 [0] required by file /usr/lib/x86_64-linux-gnu/libc.so.6 [0]
10969: checking for version `GLIBC_PRIVATE' in file /lib64/ld-linux-x86-64.so.2 [0] required by file /usr/lib/x86_64-linux-gnu/libc.so.6 [0]
Offline
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.
Offline
Yes, that's weird... find command says:
-rwxr-xr-x 1 root root 1922136 30 set 10.31 /lib/x86_64-linux-gnu/libc.so.6
-rw-r--r-- 1 root root 283 30 set 10.31 /usr/lib/x86_64-linux-gnu/libc.so
lrwxrwxrwx 1 root root 12 14 ott 2022 /usr/lib/x86_64-linux-gnu/libc.so.6 -> libc-2.31.so
Last edited by kinmen (2024-01-20 22:15:21)
Offline
Ok. Remove the link /usr/lib/x86_64-linux-gnu/libc.so.6 and run (as root)
# ldconfig
which 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.6
to 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.
Offline
Yes, now expr doesn't show that error anymore, thank you I really appreciate your help.
As always, the most weird things happen to my server. Note that I first migrated from Bullseye to Chimaera, and then I upgraded to Daedalus. The error appeared after upgrading to Daedalus, I'm quite sure it didn't show up before. It would be interesting to understand what happened exactly, but for the moment I'm happy that it has been solved. Thank you very much again.
Offline
Ok, it looks like I talked too much.
that link
/usr/lib/x86_64-linux-gnu/libc.so.6 -> libc-2.31.so
is recreated every time I update/install packages. I found that because updating php8.3 from https://packages.sury.org.
The system can't install php8.3-cli :
removed bad link, linked libc.so.6 to the right file as above, ldconfig, run dpkg -i package (I also tried apt before), then I get :
(Lettura del database... 100266 file e directory attualmente installati.)
Preparativi per estrarre php8.3-cli_8.3.2-1+0~20240120.16+debian12~1.gbpb43448_amd64.deb...
Estrazione di php8.3-cli (8.3.2-1+0~20240120.16+debian12~1.gbpb43448) su (8.3.2-1+0~20240120.16+debian12~1.gbpb43448)...
Configurazione di php8.3-cli (8.3.2-1+0~20240120.16+debian12~1.gbpb43448)...
expr: /usr/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by expr)
dpkg: errore nell'elaborare il pacchetto php8.3-cli (--install):
il sottoprocesso installato pacchetto php8.3-cli script post-installation ha restituito lo stato di errore 1
then,
find /usr/lib* /lib* -name libc.so\* | xargs ls -l
-rwxr-xr-x 1 root root 1922136 30 set 10.31 /lib/x86_64-linux-gnu/libc.so.6
-rw-r--r-- 1 root root 283 30 set 10.31 /usr/lib/x86_64-linux-gnu/libc.so
lrwxrwxrwx 1 root root 12 21 gen 12.50 /usr/lib/x86_64-linux-gnu/libc.so.6 -> libc-2.31.so
something recreated the wrong link...
I think the installation script of php8.3-cli is messing up something...
Offline
Check out if usrmerge has an influence, e.g. https://dev1galaxy.org/viewtopic.php?id=6290.
Offline
it isn't installed
Offline
I'm wondering if this third-party repository has packages that aren't Devuan compatible for whatever reason.
At your own risk you could try removing that symbollic link and installing php8.3 from Debian Experimental.
Offline
I don't feel to install stuff from experimental... it is a server with several services running. At the worst I can downgrade to php8.2
Btw I think that if the problem relies in the installation script of php8.3-cli, probably it will be the same for both repos...
Last edited by kinmen (2024-01-21 14:13:16)
Offline
You might try to reinstall libc6; version 2.31 is from chimaera:
apt-get install --reinstall libc6
But 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?
Offline
As I wrote in the first post, libc6 and libc6-dev are already v. 2.36-9+deb12u3... And I did dist-upgrade when moved to Daedalus.
With php8.3 & C. in a not complete installed status, now every try to install anything reports error in php8.3-cli etc, throws error.
I tried to install php8.2 from merged repos, but dpkg shows the same error for php8.2-cli as for php8.3-cli
(dpkg: errore nell'elaborare il pacchetto php8.2-cli (--configure):
il sottoprocesso installato pacchetto php8.2-cli script post-installation ha restituito lo stato di errore 1
The whole system, although still running looks to be inconsistent.
At this point I wonder whether has anybody successfully installed php on Daedalus...
Offline
There is a thread on this forum about deb.sury.org that has been running for years. The last post was in December 2023. This post, mentions "If using sury.org's repo one will need to install "systemd-standalone-tmpfiles" beforehand". I have no idea what that file does but having "systemd" in a file name is a mental but not necessarily a technical issue in Devuan. Please have a look at Why are systemd files present in Devuan?. Apologies if this is just noise . . .
Offline
I wonder whether has anybody successfully installed php on Daedalus
Er, yes (though not for a website)
$ apt search php | fgrep -i installed
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
php-cli/stable,now 2:8.2+93 all [installed]
php-common/stable,now 2:93 all [installed,automatic]
php-mbstring/stable,now 2:8.2+93 all [installed]
php8.2-cli/stable,stable-security,now 8.2.7-1~deb12u1 amd64 [installed,automatic]
php8.2-common/stable,stable-security,now 8.2.7-1~deb12u1 amd64 [installed,automatic]
php8.2-mbstring/stable,stable-security,now 8.2.7-1~deb12u1 amd64 [installed,automatic]
php8.2-opcache/stable,stable-security,now 8.2.7-1~deb12u1 amd64 [installed,automatic]
php8.2-readline/stable,stable-security,now 8.2.7-1~deb12u1 amd64 [installed,automatic]
Offline
About systemd-standalone-tmpfiles, it is already installed since before the migration to Chimera. Please note that the problem is not with the repo of sury itself, but with php packages: as I stated in my last post, I tried installing PHP8.2, from meged repos of Devuan, after disabling sury's repo. The problem persists. If I uninstall php8.3 and then try with php8.2-clli from Devuan, I still get:
php8.2-cli : Depends on: php8.2-common (= 8.2.7-1~deb12u1) but versione 8.2.15-1+0~20240120.39+debian12~1.gbp56f296 is goingto be installed
and it stops...
@alexkemp
could you please provide your sources.list ?
Last edited by kinmen (2024-01-22 11:56:48)
Offline
$ grep ^[^#] /etc/apt/sources.list /etc/apt/sources.list.d/*
/etc/apt/sources.list:deb http://deb.devuan.org/merged daedalus main non-free-firmware non-free contrib
/etc/apt/sources.list:deb http://deb.devuan.org/merged daedalus-updates main non-free-firmware non-free contrib
/etc/apt/sources.list:deb http://deb.devuan.org/merged daedalus-security main non-free-firmware non-free contrib
/etc/apt/sources.list:deb http://deb.devuan.org/merged daedalus-proposed-updates main non-free-firmware non-free contrib
/etc/apt/sources.list:deb http://deb.devuan.org/merged daedalus-backports main non-free-firmware non-free contrib
/etc/apt/sources.list.d/josm.list:deb https://josm.openstreetmap.de/apt/ alldist universe
Offline
tnx... same as mine excepted backports and I only have main
Offline
At the end I had to install Devuan again on a new VM and move data and conf from the old one.
Offline
Pages: 1