[pkg-cryptsetup-devel] Bug#939766: Bug#939766: cryptsetup-initramfs: Trying to boot linux-image-5.2.0-2-amd64 fails, linux-image-4.19.0-5-amd64 works.

[Guilhem Moulin]

Hi Guillem!

On Tue, 14 Jan 2020 at 02:01:09 +0100, Guillem Jover wrote:
> 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!

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20200114/ecf26ba8/attachment.sig>