On 2/3/20 3:46 PM, Felix Zielcke wrote: > On Mon, 03 Feb 2020 15:35:21 +0200 dimit...@stinpriza.org wrote: >> Package: libgcc1 >> Version: 1:9.2.1-25 >> Severity: grave >> Justification: renders package unusable >> >> hey, >> >> after upgrading some latest packages on sid, i can no longer unlock > luks >> partition and boot. message: >> >> "Please unlock disk rootfs: >> libgcc_s.so.1 must be installed for pthread-cancel to work >> Aborted" >> >> so i think it's libgcc1 related. >> had to chroot to disk from liveusb, downgrade some packages & finally > use a >> different kernel to boot. >> noticed that update-initramfs with libgcc1 1:9.2.1-25 adds file : > "Adding >> binary /lib/x86_64-linux-gnu/libgcc_s.so.1" , while libgcc1 version >> 1:10-20200202-1 doesn't add any libgcc_s.so.1. >> >> also, version from testing includes file /lib/x86_64-linux- > gnu/libgcc_s.so.1, >> while sid version uses /lib/libgcc_s.so.1 . libgcc-s1 also includes > this file : >> /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 >> >> let me know if you need anymore info. >> >> thanks, >> d. > > The btrfs binary in initramfs is also affected by this. > See #950556 [1] > > Just now with your report I saw that both btrfs and cryptroot initramfs > hooks expects libgcc_s.so.1 in the same dir as libc.so.6 > This was true in bullseye but now with the change to gcc-10 the path > has also changed. > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950556
$ dpkg -S libgcc_s.so.1 libgcc-s1:amd64: /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 libgcc1: /lib/libgcc_s.so.1 if you need the library in /lib, make sure that you depend on libgcc1, else it's found in /usr/lib/<multiarch>. I'm fine to add some breaks if required.
