encrypted root fails to cryptsetup on disco

[Klaus Rennecke]

There is a subtle error message during update-initramfs:

    find: '': No such file or directory

I could trace this to /usr/share/initramfs-tools/hooks/cryptroot line 430:

    # libargon2 uses pthread_cancel
    LIBC_DIR="$(ldd /sbin/cryptsetup | sed -nr 's#.* => (/lib.*)/libc\.so\.[0-9.-]+ \(0x[[:xdigit:]]+\)$#\1#p')"
> find -L "$LIBC_DIR" -maxdepth 1 -name 'libgcc_s.*' -type f | while read so; do
        copy_exec "$so"
    done

ldd output shows:

 libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f41aa8c4000)

so the library is not in /lib anymore but /usr/lib

The root cause of this may be an update to libc, however the script may need adjusting anyway.

cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=19.04
DISTRIB_CODENAME=disco
DISTRIB_DESCRIPTION="Ubuntu 19.04"

[Klaus Rennecke (kre)]

WORKAROUND: Change line 429 to read:

    # libargon2 uses pthread_cancel
    LIBC_DIR="$(ldd /sbin/cryptsetup | sed -nr 's#.* => (/.*)/libc\.so\.[0-9.-]+ \(0x[[:xdigit:]]+\)$#\1#p')"
    find -L "$LIBC_DIR" -maxdepth 1 -name 'libgcc_s.*' -type f | while read so; do
        copy_exec "$so"
    done

This changes the first regexp group from "(/lib.*)" to "(/.*)" allowing /usr/lib.* as well.

After running

    update-initramfs -v -k 5.0.0-32-generic -c

cryptsetup succeeds in mounting the encrypted root.

[Klaus Rennecke (kre)]

+source: https://git.launchpad.net/ubuntu/+source/cryptsetup/tree/debian/initramfs/hooks/cryptroot?id=applied/2%252.1.0-6#n414

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Chris Baker (x-illuminati)]

This bug is affecting me on Kubuntu 19.04.
I rebooted my computer this morning and typed my password into cryptsetup during boot only to get the message "libgcc_s.so.1 must be installed for pthread_cancel to work".

There are a few factors that I believe should cause the priority of this issue to be increased:
1. Advanced boot options cannot be used to recover
   Selecting recovery mode from grub menu or older kernel/initramfs versions doesn't help.
   All of my old initramfs images have been updated to no longer include libgcc_s.so.1.
2. The initramfs scripts do not recover gracefully
   It has taken me at least 4 hours to recover from this issue because copying libgcc_s.so.1 from a usb stick into the initramfs isn't enough to recover. Upon exiting the recovery shell, it simply indicated that the root couldn't be mounted and dumped me back to the shell again.
   I manually ran cryptsetup to open the LUKS volume and this still resulted in getting dumped back to the initramfs shell.
   The problem, I think, is that the cryptsetup fails several times (in local-top and in local-premount or local-block) before the mount is considered failed and the initial recovery console is presented. So, when exiting the shell, it tries to resume at a point well past the initial mounting attempt.

I finally got the computer to boot by copying libgcc_s.so.1 from another computer into the recovery initramfs. I then had to source scripts/functions and run_scripts local-top. After that I was able to boot, but I don't remember if I also did a run_scripts local-premount.

[Chris Baker (x-illuminati)]

It looks like this issue might be resolved in a recent update.
At least for me, /lib is now a softlink to /usr/lib and the original cryptroot script will now find libgcc_s.so.1 and add it to the initramfs.

[Klaus Rennecke (kre)]

I can confirm that the soft link /lib -> usr/lib/ fixes this issue. Did a clean re-install of cryptsetup-initramfs and tested the updated initramfs boots okay. Issue is fixed in disco.