Hi, On Sat, 27 Apr 2024 at 00:33:51 +0200, Christoph Anton Mitterer wrote: > Now the problem is that argon2 is statically linked, so there's no > libpthread showing up in its ldd, and thus copy_exec doesn't realise it > needs to invoke copy_libgcc.
Even it weren't, libpthread wouldn't show up since src:argon2 from bookworm and later is built using glibc ≥2.34. AFAICT the “if the ldd output includes libpthread then run copy_libgcc()” logic from initramfs-tools is mostly moot now, see https://bugs.debian.org/1032235#97 . We used the following workaround to manually call copy_libgcc() https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/4cade1eae57abd93e0d6491eebce5f5f163ef186#a630d04e2df57150e6a092fc23f955c6ea0ce412 https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/369cb651abad11a3844fa38ea86ece40f4f40078 for Bookworm, but removed it with 2:2.7.2-1 since src:cryptsetup no longer uses libargon. There is no stability guaranty for transitive dependencies so I'd indeed argue the regression is not src:cryptsetup's fault :-) Adapting the above workarounds to your custom hookfile should solve the issue, though. > Did anyone of your report this issue anywhere else? Some years ago I asked the initramfs-tools maintainers to inconditionally copy libgcc_s to the initramfs image, but IIRC Ben argued it was too seldom used to justify the cost in size and impemented the libpthread detection logic + copy_libgcc() instead. I don't know if the detection logic can be improved/fixed in initramfs-tools, but despite what I promised elbrus in https://bugs.debian.org/1032235#87 it looks like I didn't file a bug. -- Guilhem.
signature.asc
Description: PGP signature
