FS#56867 - [glibc][systemd] 236.0-2 Inconsistency detected by ld.so on travis-ci.org
Attached to Project:
Arch Linux
Opened by Mikkel Oscar Lyderik (moscar) - Tuesday, 26 December 2017, 10:42 GMT
Last edited by Toolybird (Toolybird) - Thursday, 02 February 2023, 05:18 GMT
Opened by Mikkel Oscar Lyderik (moscar) - Tuesday, 26 December 2017, 10:42 GMT
Last edited by Toolybird (Toolybird) - Thursday, 02 February 2023, 05:18 GMT
|
Details
Description:
Me and others are using https://github.com/mikkeloscar/arch-travis to setup a chroot Arch Linux environment when running builds on travis-ci. Since systemd 236.0-2 was released the builds have failed with this error: Inconsistency detected by ld.so: dl-open.c: 689: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed! (Full log: https://travis-ci.org/mikkeloscar/arch-travis/jobs/320383646#L721) When running commands like pacman or curl. Pinning systemd to the version of the latest Arch ISO (2017.12.01) (systemd 235.38-2) (https://github.com/mikkeloscar/arch-travis/pull/34), solves the problem, but I suspect there is something wrong with the latest systemd package since this happens. I have not seen any issues with my other "real" Arch Linux systems since upgrading to systemd 236.0-2 though. This is maybe a bit far fetched but when looking into the issue I found that glibc was build with debug symbols at some point (https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/glibc&id=629ac2aea21fb8bcabcf5974251d2335313619fe) Could it be that the latest systemd package is built against a glibc not in the repos? Additional info: * systemd 236.0-2 Steps to reproduce: Setup arch-travis build with this .travis.yml: https://raw.githubusercontent.com/mikkeloscar/arch-travis/broken-systemd/.travis.yml |
This task depends upon
Closed by Toolybird (Toolybird)
Thursday, 02 February 2023, 05:18 GMT
Reason for closing: None
Additional comments about closing: See comments
Thursday, 02 February 2023, 05:18 GMT
Reason for closing: None
Additional comments about closing: See comments
I do build all my packages in clean chroot. ;)
Any info about systemd 236.0-1? I guess that fails as well?
Neither pacman nor curl are linked against systemd libraries, so no clue what goes wrong here...
Given that libnss libraries are candidates for the issue: Anybody wants to build systemd with reverted b4b36f4405b7fba0deb2a0d6b5379e7ef66e5c61 [0] and try with that?
If that does not help... Bisecting this would be a good idea.
[0] https://github.com/systemd/systemd/commit/b4b36f4405b7fba0deb2a0d6b5379e7ef66e5c61
FS#57115(which was marked as a duplicate of this bug) when I try to launch kdevelop.$ kdevelop
Inconsistency detected by ld.so: ../sysdeps/x86_64/dl-machine.h: 540: elf_machine_rela_relative: Assertion `ELFW(R_TYPE) (reloc->r_info) == R_X86_64_RELATIVE' failed!
EDIT: After rebooting (and also updating my kernel from 4.17.5-1 to 4.17.6-1 it works again...
EDIT: The error I'm seeing is: Inconsistency detected by ld.so: ../sysdeps/x86_64/dl-machine.h: 540: elf_machine_rela_relative: Assertion `ELFW(R_TYPE) (reloc->r_info) == R_X86_64_RELATIVE' failed!
Feel free to ignore this again since I have no idea what happened. Could be cosmic rays or whatever...
$ eu-elflint --gnu-ld libasound.so.2.0.0-good
No errors
$ eu-elflint --gnu-ld libasound.so.2.0.0-broken
section [ 8] '.rela.dyn': relocation 1072: invalid type
section [ 8] '.rela.dyn': relocation 1072: invalid symbol index