Bug#939766: [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.
On Tue, 14 Jan 2020 at 03:22:20 +0100, Guilhem Moulin wrote: > 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. signature.asc Description: PGP signature
Bug#939766: [pkg-cryptsetup-devel] Bug#939766: cryptsetup-initramfs: Trying to boot linux-image-5.2.0-2-amd64 fails, linux-image-4.19.0-5-amd64 works.
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=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. signature.asc Description: PGP signature
Bug#939766: cryptsetup-initramfs: Trying to boot linux-image-5.2.0-2-amd64 fails, linux-image-4.19.0-5-amd64 works.
Control: tags -1 - moreinfo Hi! On Mon, 2019-09-09 at 00:53:44 +0200, Alexander Brock wrote: > 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 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
Bug#939766: [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.
Control: retitle -1 cryptsetup-initramfs: Missing libgcc_s on linux-image-5.2.0-2-amd64 On Mon, 09 Sep 2019 at 02:55:06 +0200, Guilhem Moulin wrote: > This on a sid system upgraded from buster with a ‘usrmerge’ layout: > > root@kvm-10487:~# ldd /sbin/cryptsetup | grep -F libc.so > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f075b205000) > root@kvm-10487:~# readlink -f /lib/*linux-gnu/libc.so* > /usr/lib/x86_64-linux-gnu/libc-2.28.so > root@kvm-10487:~# lsinitramfs /initrd.img | grep libgcc > usr/lib/x86_64-linux-gnu/libgcc_s.so.1 And also: root@kvm-10487:~# uname -r 5.2.0-2-amd64 root@kvm-10487:~# dpkg -l | grep -Fe linux-image-5.2.0-2-amd64 -e libc6 -e libgcc1 ii libc6:amd642.29-1 amd64 GNU C Library: Shared libraries ii libgcc1:amd64 1:9.2.1-7amd64 GCC support library ii linux-image-5.2.0-2-amd64 5.2.9-2 amd64 Linux 5.2 for 64-bit PCs (signed) root@kvm-10487:~# dpkg -L libc6 | grep -F libc.so /lib/x86_64-linux-gnu/libc.so.6 root@kvm-10487:~# dpkg -L libgcc1 | grep -F libgcc_s.so /lib/x86_64-linux-gnu/libgcc_s.so.1 root@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 root@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. signature.asc Description: PGP signature
Bug#939766: [pkg-cryptsetup-devel] Bug#939766: cryptsetup-initramfs: Trying to boot linux-image-5.2.0-2-amd64 fails, linux-image-4.19.0-5-amd64 works.
Control: tag -1 moreinfo Hi, On Mon, 09 Sep 2019 at 00:53:44 +0200, Alexander Brock wrote: > 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: root@kvm-10487:~# ldd /sbin/cryptsetup | grep -F libc.so libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f075b205000) root@kvm-10487:~# readlink -f /lib/*linux-gnu/libc.so* /usr/lib/x86_64-linux-gnu/libc-2.28.so root@kvm-10487:~# lsinitramfs /initrd.img | grep libgcc usr/lib/x86_64-linux-gnu/libgcc_s.so.1 -- Guilhem. signature.asc Description: PGP signature
Bug#939766: cryptsetup-initramfs: Trying to boot linux-image-5.2.0-2-amd64 fails, linux-image-4.19.0-5-amd64 works.
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
Bug#939766: cryptsetup-initramfs: Trying to boot linux-image-5.2.0-2-amd64 fails, linux-image-4.19.0-5-amd64 works.
Package: cryptsetup-initramfs Version: 2:2.2.0-3 Severity: important Dear Maintainer, * What led up to the situation? I ran apt upgrade and restarted the system since I noticed that some drivers were upgraded (firmware-linux-* stuff). I have an encrypted / partition, this is the output of lsblk: NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:00 931.5G 0 disk ├─sda18:10 512M 0 part /boot/efi ├─sda28:20 244M 0 part /boot └─sda38:30 930.8G 0 part └─sda3_crypt 254:00 930.8G 0 crypt ├─luna--vg-swap 254:10 14.9G 0 lvm [SWAP] └─luna--vg-root 254:20 915.9G 0 lvm / This is the output of "mount": sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,nosuid,relatime,size=32935756k,nr_inodes=8233939,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=6591424k,mode=755) /dev/mapper/luna--vg-root on / type ext4 (rw,noatime,nodiratime,errors=remount- ro) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime) bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=43,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=13961) debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime) /dev/sda2 on /boot type ext2 (rw,relatime,block_validity,barrier,user_xattr,acl) /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount- ro) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime) tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=6591420k,mode=700,uid=1000,gid=1000) fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime) /dev/fuse on /run/user/1000/doc type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000) After rebooting I entered my password and this happened: > Please unlock disk sda3_crypt: > libgcc_s.so.1 must be installed for pthread_cancel to work > Aborted > cryptsetup: ERROR: sda3_crypt: cryptsetup failed, bad password or options? > > Please unlock disk sda3_crypt: I booted a grml, mounted the partitions to make sure I got the password right, ran "grml-chroot /mnt" and used "update-initramfs -u, this didn't help. I was able to boot the older 4.19 kernel and ran "update-initramfs -uv", also did not help, this is the output: https://paste.debian.net/1099530/ -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 root=/dev/mapper/luna--vg-root ro quiet -- /etc/crypttab sda3_crypt UUID=4161a32d-e8b4-45a8-8f49-198b89278fda none luks,discard -- /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # /dev/mapper/luna--vg-root / ext4 noatime,nodiratime,errors=remount-ro 0 1 # /boot was on /dev/sda2 during installation UUID=d822425d-2328-42e5-b197-4125333ca853
