Discussion:
Bug#939766: cryptsetup-initramfs: Trying to boot linux-image-5.2.0-2-amd64 fails, linux-image-4.19.0-5-amd64 works.
Add Reply
Alexander Brock
2019-09-08 23:10:01 UTC
Reply
Permalink
I searched for clues why that libgcc_s.so.1 is not added and found the
script:
/usr/share/initramfs-tools/hooks/cryptroot

it contains the line:

LIBC_DIR="$(ldd /sbin/cryptsetup | sed -nr 's#.* =>
(/lib.*)/libc\.so\.[0-9.-]+ \(0x[[:xdigit:]]+\)$#\1#p')"

but on my machine there is no /bin/libc.so.[0-9.-]+ instead it is in
/usr/lib/x86_64-linux-gnu. Therefore $LIBC_DIR is empty which leads to
the "find: ‘’: No such file or directory" error message in the log
(https://paste.debian.net/1099530/)

Allowing any number of characters before the /lib fixes the problem:

LIBC_DIR="$(ldd /sbin/cryptsetup | sed -nr 's#.* =>
(.*/lib.*)/libc\.so\.[0-9.-]+ \(0x[[:xdigit:]]+\)$#\1#p')"

I changed this and now the 5.2 kernel boots again. I made a merge
request:
https://salsa.debian.org/cryptsetup-team/cryptsetup/merge_requests/10
Guilhem Moulin
2019-09-09 01:10:01 UTC
Reply
Permalink
Control: tag -1 moreinfo

Hi,
Post by Alexander Brock
but on my machine there is no /bin/libc.so.[0-9.-]+ instead it is in
/usr/lib/x86_64-linux-gnu.
(I assume you meant ‘/lib.*/libc\.so\.[0-9.-]+’.) How did you end up
with a system where /lib/*-linux-gnu/libc.so.6 is neither a symlink to a
shared library under /lib nor /usr/lib? I can't reproduce that with a
clean bullseye nor with an upgrading system from an upgrading system
from a buster netinst. AFAICT the existing regexp work for these
systems in both normal and ‘usrmerge’ layouts. This on a sid system
upgraded from buster with a ‘usrmerge’ layout:

***@kvm-10487:~# ldd /sbin/cryptsetup | grep -F libc.so
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f075b205000)
***@kvm-10487:~# readlink -f /lib/*linux-gnu/libc.so*
/usr/lib/x86_64-linux-gnu/libc-2.28.so
***@kvm-10487:~# lsinitramfs /initrd.img | grep libgcc
usr/lib/x86_64-linux-gnu/libgcc_s.so.1
--
Guilhem.
Guilhem Moulin
2019-09-09 10:10:02 UTC
Reply
Permalink
Control: retitle -1 cryptsetup-initramfs: Missing libgcc_s on linux-image-5.2.0-2-amd64
Post by Guilhem Moulin
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f075b205000)
/usr/lib/x86_64-linux-gnu/libc-2.28.so
usr/lib/x86_64-linux-gnu/libgcc_s.so.1
And also:

***@kvm-10487:~# uname -r
5.2.0-2-amd64
***@kvm-10487:~# dpkg -l | grep -Fe linux-image-5.2.0-2-amd64 -e libc6 -e libgcc1
ii libc6:amd64 2.29-1 amd64 GNU C Library: Shared libraries
ii libgcc1:amd64 1:9.2.1-7 amd64 GCC support library
ii linux-image-5.2.0-2-amd64 5.2.9-2 amd64 Linux 5.2 for 64-bit PCs (signed)
***@kvm-10487:~# dpkg -L libc6 | grep -F libc.so
/lib/x86_64-linux-gnu/libc.so.6
***@kvm-10487:~# dpkg -L libgcc1 | grep -F libgcc_s.so
/lib/x86_64-linux-gnu/libgcc_s.so.1
***@kvm-10487:~# readlink -e /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libgcc_s.so.1
/usr/lib/x86_64-linux-gnu/libc-2.29.so
/usr/lib/x86_64-linux-gnu/libgcc_s.so.1
***@kvm-10487:~# cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf
# Multiarch support
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

So AFAICT libc6 installs its soname under /lib/$MULTIARCH, and with the
default ld.so.conf ldd(1) looks there before its counterpart in /usr, so
that's what we want LIBC_DIR to be.
--
Guilhem.
Guillem Jover
2020-01-14 01:10:02 UTC
Reply
Permalink
Control: tags -1 - moreinfo

Hi!
Post by Alexander Brock
I searched for clues why that libgcc_s.so.1 is not added and found the
/usr/share/initramfs-tools/hooks/cryptroot
LIBC_DIR="$(ldd /sbin/cryptsetup | sed -nr 's#.* =>
(/lib.*)/libc\.so\.[0-9.-]+ \(0x[[:xdigit:]]+\)$#\1#p')"
but on my machine there is no /bin/libc.so.[0-9.-]+ instead it is in
/usr/lib/x86_64-linux-gnu. Therefore $LIBC_DIR is empty which leads to
the "find: ‘’: No such file or directory" error message in the log
(https://paste.debian.net/1099530/)
LIBC_DIR="$(ldd /sbin/cryptsetup | sed -nr 's#.* =>
(.*/lib.*)/libc\.so\.[0-9.-]+ \(0x[[:xdigit:]]+\)$#\1#p')"
I changed this and now the 5.2 kernel boots again. I made a merge
https://salsa.debian.org/cryptsetup-team/cryptsetup/merge_requests/10
I've just hit the same problem, but I don't think this diagnostic is
correct?

The problem I've got is that I upgraded to gcc-10 from experimental,
which pulled in libgcc1-s1 and libgcc1 (that I later removed), neither
of which install libgcc_s.so.1 under /lib/$MULTIARCH anymore. The first
installs the shared library under /usr/lib/$MULTIARCH, the latter
under /lib/ (although that one might be in error, as there's an empty
multiarch dir under /lib in that package), so that logic does not find
it.

IMO the assumption that libgcc will be located in the same directory
as libc is incorrect, first because it comes from a different source
package, and second because nothing says they need to be on the same
directory. :)

Thanks,
Guillem
Guilhem Moulin
2020-01-14 02:30:01 UTC
Reply
Permalink
Hi Guillem!
Post by Guillem Jover
The problem I've got is that I upgraded to gcc-10 from experimental,
which pulled in libgcc1-s1 and libgcc1 (that I later removed), neither
of which install libgcc_s.so.1 under /lib/$MULTIARCH anymore. The first
installs the shared library under /usr/lib/$MULTIARCH, the latter
under /lib/ (although that one might be in error, as there's an empty
multiarch dir under /lib in that package), so that logic does not find
it.
I see, thanks for the follow-up!
Post by Guillem Jover
IMO the assumption that libgcc will be located in the same directory
as libc is incorrect, first because it comes from a different source
package, and second because nothing says they need to be on the same
directory. :)
Fair enough, and also ldd(1)'s output isn't meant to be parsable.
Finding libgcc that way a dirty hack which has served us well so far.

Not sure which one was first but FWIW there are a couple of other
packages using the same libc-based logic to determine which runtime
library to copy into the initramfs:

https://codesearch.debian.net/search?q=%2Flibc%5C%5C.so&literal=0

but rather than reinventing the wheel each on our end I'd welcome a tip
to find where libgcc_s (and other runtime libraries such as libnss) is
installed in a robust fashion. At least the one needed for a given
binary, but if there are multiple versions I guess shipping them all
wouldn't cause too much overhead. Parsing the output of `ldconfig -p`
sounds a bit overkill, but perhaps it's better (or at least not worse,
the output isn't meant to be parsable either AFAICT). If there is a
need for a complex logic I guess this could be done once and for all in
/usr/share/initramfs-tools/hook-functions.

Otherwise, I guess we could amend the sed script to allow an optional
/usr prefix (until the library moves elsewhere again).

Cheers,
--
Guilhem.
Guilhem Moulin
2020-01-30 23:30:02 UTC
Reply
Permalink
If there is a need for a complex logic I guess this could be done once
and for all in /usr/share/initramfs-tools/hook-functions.
Quick follow up about this: asked Ben for feedback and he agreed that it
would make sense to do it in initramfs-tools. That's #950254; I'm not
merging the bugs on closing -1 until this is actually implemented, but
we'll hopefully have a fine solution for all packaging using
pthread_cancel() & friends soon :-)
--
Guilhem.
Loading...