[pkg-cryptsetup-devel] Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Christoph Anton Mitterer]

Hey Guilhem

On Sat, 2024-04-27 at 01:48 +0200, Guilhem Moulin wrote:
> Even it weren't, libpthread wouldn't show up since src:argon2 from
> bookworm
> and later is built using glibc ≥2.34.

When argon2 builds, it uses -pthread ... not really sure what that does
exactly, the manpage merely says it links against pthread, but
statically? Dynamically?

Anyway, when building it manually and even with -lpthread, it doesn't
show up - just as you say.

Tried now for an hour or so to make it show up (eventually gave up and
filed #1069912).

So you say it's a glibc thingy, that this doesn't show up anymore?


>   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 .

Shouldn't initramfstools then not simply generally include libgcc?



> 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

As a workaround I've used now:
copy_libgcc /lib/x86_64-linux-gnu

with the libpath hardcoded... but I have no idea how I should get that
path properly.
As far as I can see from your commit, you simply used the path that
libargon2 was using?

But I don't have that since argon2 doesn't link against it ;-)
Any idea what would be the best solution in my case?


> 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.

Hmm yes, but I'm not sure if that would be a more proper solution than
mine (with the hardcoded path), cause:

In principle, my argon2 binary tool, might be from another arch as the
installed libargon2 (if it's installed at all, which isn't necessarily
the case).
So not sure, but maybe:

$ ldd /usr/bin/argon2
	linux-vdso.so.1 (0x00007ffcc67d4000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1a1ee48000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f1a1f058000)

I should use libc for determination?

> 



> > 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.

So... I assume the change in glibc is proper then... and a fix (if at
all) would rather need to go to initramfs-tools?
Would you recommend me to reassign #1069912 to initramfs-tools, asking
for a more user-friendly solution?


Thanks,
Chris.