Package: cryptsetup-initramfs
Version: 2:2.2.2-2
Severity: critical
The side effect of initramfs logic used to find libgcc leads to
unbootable system if libgcc is in different location than libc. Maybe
something like "ldconfig -p | grep libgcc_s.so.1" should be used to
locate libgcc instead?
Details:
The recent update of libgcc1 to version 1:10-20200202-1 (unstable) moved
it from:
/lib/x86_64-linux-gnu/libgcc_s.so.1
to:
/lib/libgcc_s.so.1
The initramfs hook for cryptsetup is still looking for it using previous
location based on libc:
# cat /usr/share/initramfs-tools/hooks/cryptroot
[...]
LIBC_DIR="$(ldd /sbin/cryptsetup | sed -nr 's#.* =>
(/lib.*)/libc\.so\.[0-9.-]+ \(0x[[:xdigit:]]+\)$#\1#p')"
find -L "$LIBC_DIR" -maxdepth 1 -name 'libgcc_s.*' -type f | while read
so; do
copy_exec "$so"
done
# echo $(ldd /sbin/cryptsetup | sed -nr 's#.* =>
(/lib.*)/libc\.so\.[0-9.-]+ \(0x[[:xdigit:]]+\)$#\1#p')
/lib/x86_64-linux-gnu
# ldd /sbin/cryptsetup
[...]
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4b0b6c0000)
This leads to omission of libgcc_s.so.1 in initramfs and makes unlocking
the root drive impossible (in case of LUKS2 at least) because of the
following error:
libgcc_s.so.1 must be installed for pthread_cancel to work
I created initramfs hook in /etc/ that includes libgcc and it solves the
problem (obviously as workaround):
cp /lib/libgcc_s.so.1 "${DESTDIR}/usr/lib/"
The difference in libgcc1 packages:
(version 1:10-20200202-1)
# dpkg -L libgcc1
/.
/lib
/lib/libgcc_s.so.1
/lib/x86_64-linux-gnu
/usr
/usr/share
/usr/share/doc
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/libgcc1
/usr/share/doc/libgcc1
(version 1:9.2.1-25)
# dpkg -L libgcc1
/.
/lib
/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu/libgcc_s.so.1
/usr
/usr/share
/usr/share/doc
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/libgcc1
/usr/share/doc/libgcc1
Thanks,
Karol
