Bug#950551: libgcc1: after libgcc1 upgrade, can't unlock luks partition at boot
Control: retitle -1 libgcc1 should add a Breaks on cryptsetup-initramfs Hi Matthias, initramfs-tools maintainers, > Am Montag, den 03.02.2020, 18:59 +0100 schrieb Matthias Klose: > > I'm fine to add some breaks if required. cryptsetup-initramfs version 2:2.2.2-3 already worked around the issue and has migrated to testing. Adding a Breaks on cryptsetup-initramfs << 2:2.2.2-3~ (IIAC) will prevent this specific issue. > This gets now fixed directly in initramfs-tools: > > https://salsa.debian.org/kernel-team/initramfs-tools/commit/f2ac13e8881f975b062a56050ceda85ef9ccc015 > > See also #950254 > > So I guess as soon as that is uploaded, libgcc1 should then Breaks: the > older versions. I think it makes sense to add that Breaks for safety as well, once that fix gets uploaded, but do we need to block the migration of gcc-10 until that happens? If so, can that upload happen soon? Paul signature.asc Description: OpenPGP digital signature
Bug#950551: libgcc1: after libgcc1 upgrade, can't unlock luks partition at boot
Am Montag, den 03.02.2020, 18:59 +0100 schrieb Matthias Klose: > $ 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/. > > I'm fine to add some breaks if required. This gets now fixed directly in initramfs-tools: https://salsa.debian.org/kernel-team/initramfs-tools/commit/f2ac13e8881f975b062a56050ceda85ef9ccc015 See also #950254 So I guess as soon as that is uploaded, libgcc1 should then Breaks: the older versions.
Bug#950551: libgcc1: after libgcc1 upgrade, can't unlock luks partition at boot
Package: libgcc1 Version: 1:10-20200202-1 Followup-For: Bug #950551 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey! On both my systems running unstable, libgcc-s1 is installed, but I don't have /usr/lib/x86_64-linux-gnu/libgcc_s.so.1. So, it seems something removes it. I have no clue on why. Reinstalling libgcc-s1 fixes the problem. - -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 'experimental-debug'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgcc1 depends on: ii gcc-10-base 10-20200202-1 ii libc62.29-9 ii libgcc-s110-20200202-1 libgcc1 recommends no packages. libgcc1 suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl45Bb4SHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX5MDkP/AoeAopCOY4NEL8+GG5qC/4xiQk4SKWY tBqFKmEhrex/46+idUV9AmY5G7BGJQad1i0L551vcuyNye2utz6dP/2XIgSJk3Ai HVSjApSGDdo8MDVW6w2C0GucGSQAX55XPGtC6BU7I5C5ukny+MZx6Z0R/5cOYjy9 BWL8KejRawltzKIZpPIT7DuA+OG1tAQ6njdfbQxn5ihNGIHXoEcgEShEVlBhx48I lIadw5jKJkhK6LDYWmzfvigVo9NIC/IIgepvzapNrMirjjsQE6Q/OpsxMjakfk+t +dI4kiBbPqXNqDyaSMgUG3nKYZcIjgMU14fMC2JbRKIOOvXMHzgn5I/oj3zxau50 qZ5l1Yk1Rkds0u9mGVxmrGefxEd5IWet2HVwsqhDXNz+xyHH0yZE59UbXcdO+mfq JVn2vbbXUBpYaAVmKyaocinDlgUYMg987j+HCNQYtmbyXfgD0GobVc3yDJykHiRj T3Isk2ZbwLZhT5yb2p4KTbodZO1AWbGW2wabODjgAfeCtOM3tJjUioVYvXlHCnVm hxReC7+c81CvzkNA95hT23TL4GKu21KXUpD60TWUv3i6VFp2dvDs4YV2JGzPjXbB zIlSk04AhOlzLP8N3gRRW0J+vLQdLB+7USeyDlNgbf7HPhuNlvekPsAwh/BxDxdf bClIfmr3peYd =lto4 -END PGP SIGNATURE-
Bug#950551: libgcc1: after libgcc1 upgrade, can't unlock luks partition at boot
I can confirm this bug. After doing an apt full-upgrade, I faced the same issue as OP. However, I was not able to fix it by downgrading packages, but instead used a similar approach to the way described in the btrfs bug #950556 [1]. After chrooting into the system, I changed the following file: $ diff /usr/share/initramfs-tools/hooks/cryptroot.backup /usr/share/initramfs-tools/hooks/cryptroot 416c416 < find -L "$LIBC_DIR" -maxdepth 1 -name 'libgcc_s.*' -type f | while read so; do --- > find -L "/lib" -maxdepth 1 -name 'libgcc_s.*' -type f | while read so; do After this, I updated initramfs with "update-initramfs -u -k all". Note: for this to work cleanly, you need to bind proc, dev etc. and you need to open your encrypted volume with the same name as described in your system's /etc/crypttab. The commands I used: sudo cryptsetup open /dev/sda5 sda5_crypt [...] sudo mount --bind /dev /mnt/dev [...] Cheers Nico [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950556
Bug#950551: libgcc1: after libgcc1 upgrade, can't unlock luks partition at boot
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/. I'm fine to add some breaks if required.
Bug#950551: libgcc1: after libgcc1 upgrade, can't unlock luks partition at boot
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
Bug#950551: libgcc1: after libgcc1 upgrade, can't unlock luks partition at boot
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. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages libgcc1 depends on: ii gcc-9-base 9.2.1-25 ii libc6 2.29-9 libgcc1 recommends no packages. libgcc1 suggests no packages. -- no debconf information
