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.

Reply via email to