Control: tag -1 + unreproducible moreinfo

On Fri, 12 Apr 2024 at 12:45:09 +0200, Milan Broz wrote:

Just FYI (for upstream code): if cryptsetup/libcryptsetup is linked with OpenSSL >= 3.2,
it does not need libphtread (as threads are implemented in OpenSSL for Argon2 internally).

Thanks for confirming! We're now linking with OpenSSL 3.2 indeed, and
our CI confirms that unlocking works in that environment.

2:2.7.2-1 builds with OpenSSL 3.2 *and* removes the libgcc_s/libargon2 workaround from the initramfs hook: https://tracker.debian.org/news/1517996/accepted-cryptsetup-2272-1-source-into-unstable/

It would also be nice if the "gui" view could show the error or at
least tell the user to pres ctrl-alt-del to get to a more informative
view, took me ages to figure out that one :-(

What is that “GUI” view? src:cryptsetup doesn't provide that, I wonder
if it might be what needs libphtread.

Otherwise, my guess is a race where the the initramfs image was somehow
rebuilt before libcryptsetup12 was upgraded, but AFAICT the dependencies
are properly set to avoid that. Does the broken initramfs image contain libargon2.so, if so does its libcryptsetup12 use it?

If you still have the broken initramfs image, please extract it with `unmkinitramfs /path/to/broken.initrd.img /path/to/destdir` and try to
find which executable / shared library needs libphtread, for instance
with

cd /path/to/destdir
for p in $(find -P {usr/,}lib/x86_64-linux-gnu {usr/,}{,s}bin/ -type f); do objdump -p "$p" 2>/dev/null | grep -q pthread && echo "$p"; done

This will hopefully shed some light on this.

--
Guilhem.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEERpy6p3b9sfzUdbME05pJnDwhpVIFAmYZKvwACgkQ05pJnDwh pVKBFA/9EgECmfdENc2e5B7V7aojTjvIuZVFVTIquigHg2hDF5aWdQs2SkGqq0Pd lEc09UlT5w2gYhf+1kOx0QEkt5XNA8/HD6Gq+sAh9jbElDgz4aioJDRz6CkQKOP3 a1S1q3S8EEMCR88tKARIa0q0kyuKIAaVxGrDi7IPSWqptkDluwHIpdL2iOaL4qIq MM6iL4AFDf0C5yYmrmGGFIXK5EdCnw5ctcHnr/CYuqtUB15MFRPUzG1kBcUpu9wy L6BjOyZUizhu9V/Xulvytiti2Sy3whkxMRegwt8JR6QoojYWATt+piMfLNhb/hR+ HGGFiy8hK8/gHryjruyThjIII3Kk+ynAcSweW8hNhd3ehkL8DxLuaBK0/2NkcXo4 yTMe4kn8wPLyV/ZhWCLVM+1zRm7NF4X1Z1FRl76wRtQvDu/Bmlc9dUJJ7RV89sFl DwCr7w/+ewrZjUXCy3LhrfTF4+/SAfCSJoUTeRllaU/tu8KQG3TYyHudicpI35Yn 6N5iTmhkek5/9QP46s2SatPc36G6wl0uiKowwrfKvWUX2L02tcWqi1qt9HEfNspH bXGT4PCzhHcg4we0URM5T43ueWGrKEFRwevwbiHxYfg4T8trDdgVkxq54Fyy+w9B 3/L1eTXJFL32i49A7gnjqT4wfwok8AQ4ANgo9th4VnHbuwH9EvU=
=M4wj
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 12 Apr 2024 at 14:37:16 +0200, Guilhem Moulin wrote:

What is that “GUI” view? src:cryptsetup doesn't provide that, I wonder if it might be what needs libphtread.

FWIW, I later noticed you used a splash screen (plymouth) and thought it
might be because of that, but I still cannot reproduce the issue in a
bookworm VM upgraded to sid (using d-i's “encrypted LVM” layout + a
splash screen).

After a ctrl-alt-del, I got to the console and there it showed an error about
libgcc_s.so.1 not available and aborting.

What was that error message exactly?

If you still have the broken initramfs image, please extract it with `unmkinitramfs /path/to/broken.initrd.img /path/to/destdir` and try to
find which executable / shared library needs libphtread, for instance
with

cd /path/to/destdir
for p in $(find -P {usr/,}lib/x86_64-linux-gnu {usr/,}{,s}bin/ -type f); do objdump -p "$p" 2>/dev/null | grep -q pthread && echo "$p"; done

Erm no, that likely won't work since pthread functions have moved from libpthread.so.1 to libc.so.6 with glibc 2.34. Otherwise copy_exec()
would have pulled in libgcc_s. New attempt:

rm -rf /tmp/initramfs-destdir && \
mkdir -m0700 /tmp/initramfs-destdir && \
unmkinitramfs /path/to/broken.initrd.img /tmp/initramfs-destdir && \
for p in $(find /tmp/initramfs-destdir/main -type f | sort); do \
objdump -T "$p" 2>&1 | grep pthread_exit && echo "^^ $p"; \
done

--
Guilhem.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEERpy6p3b9sfzUdbME05pJnDwhpVIFAmYZQ+kACgkQ05pJnDwh pVJtGhAAy+PGzsu9yLjdYhlsjRu3CDdSAX/kID/V1ObepKFPP2SlvAVastA0cXSP RSFwJOC5i+V2a9anGu3BmKp+obH+5mlAr6+1uFNgT13tsLqqMW+5S/XakuC/+Q6X XqSHNlECIEwNk7OT1/hr/2e1cJLAg5Xq4fVniYVGfCKCZEiH0DSQz27VnMq/6KED k+A0AdbIRjUC2oQ+bJ5xKJYHfdjIIhFmeFMyg9cXN/DbXyybyvyHkyPiRqZk5u7z Vjq//Osa2uFInoBXtf5EkszmoVQJgFaYSY3VImHDP03Q8pD8eSOAMF+raZ1xT9q4 tdwMCnssUmv/SJSLE69Y1N+TyCga+ykMH3xNjmdO8ULoAe6G5Z6J03Nq0AYyzj53 aUlF/G4F0ymg8MaoQWSmt6VcdBTttWYqUQBIhlQnp0NAyv9tf20kUc3RO9zYYnQc UBaWvSdCOGDUSPSz9JUOf5wFKZGef/7YvyIpHMJWcW4eP0FOTIPcU7B5RpCtj3lR 2iShePYt3vD7nghgMvJlgIULrt2wQuXcabsELG+HIJ0+OhnlEf9B4h+jqgUVULGX P1RAf7f4zojpFBrBG4HPmsoVUgh1Z7UjN+ePQo94Vwt2VCBgKT+TsEUUfdLELqx7 A0RC/YYugYrjUrpjfyW9qWIw0Xnv2LBlc6BQ5pxrqtolbf9HgC4=
=rDOk
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 27 Apr 2024 at 02:07:21 +0200, Christoph Anton Mitterer wrote:

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

Yup, that's what I wrote https://bugs.debian.org/1032235#97

| It was intentional, see the article
| https://developers.redhat.com/articles/2021/12/17/why-glibc-234-removed-libpthread .
| Unfortunately that change broke initramfs-tools' fix for https://bugs.debian.org/950254
| which we (src:cryptsetup maintainers) relied on for cryptsetup-initramfs.
| Until last week src:argon2 had never been rebuilt with the newer glibc,
| so it's just unfortunate that we missed that at the time.

On the one hand it was unfortunate to find such a severe RC bug
(unbootable system with the default config) so late in the freeze, on
the other hand it would have been even worse if src:argon2 would have
been uploaded to bookworm-security or -pu after the stable release :-)

$ 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?

Don't know if that's the best or most robust solution but that's what
I'd do as workaround at least.

Would you recommend me to reassign #1069912 to initramfs-tools, asking
for a more user-friendly solution?

Yup that'd make sense to me (and I see you did that already), thanks!

--
Guilhem.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEERpy6p3b9sfzUdbME05pJnDwhpVIFAmYsUZMACgkQ05pJnDwh pVI5eg//UT/FKMCYUsckpu2X60wIzUYjYY0+RKMVoGZLoTpSfqfDY6h9vj8+b7Xi gy0zYMM2ra+MXIiGAf9I/snSOZtl77nFOuJGEtRCv1e3y1nvy7c7tbG9CSxdzcjq eUoeb8tjfvFIC4pGyDvqC91FOeu5+VAkhPaZ6fw/KkzikFEvCyx5RZ7JFAtGkqHr EFvj7CjwKzNUjAjOLK3UL+zHkEeRaab7eZdgfyFfI+AhrCsSymau/6FbVxifCTxg RTpzoXSErogzWbIXCnhkVDXUd2krPJUbXvS0GHJLvld+HoBwJH5iPe6b3bruEm5I 3n2ey23rx2UuNUdzuWzqgl4Nrs0ziRmbN4KV2dxFcYpOhdj3xya67s+WrBYfeXHv 4bbJ2+nHlpZvZA+YNR/QL50sg72iRPB4GURwaiHKLlJAUL3StKTxN5DKPEk1QlpC QrMb+ydCQT/BXKEMAAvlE3nwD1EcDd9JrGxw75RoDZWiLL+jPYXF66RPkQndnlOb jvNgUq5alMDpSvLBZ3Sz6WjFe6jZiPXolhVQnF0sKcRKCXcIhkZdRfYMC4w+Wq7M KutzGNB64vVnUsHXXOMcG9dDRgkB1lbvRkJW/jCTywR6yJJla3boTmqZTkjoUhzP zdPa0F4HwTIYSQD+NFEo5fYG7guzYdfbXbNSUWPZFTE0VutD0P4=
=VWcE
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)