Can we assume that today's update (6/17) for the cryptsetup packages to 2.1.0-5 does not address this issue? I have marked all those as 'hold' for now.

I don't know for sure. I'm taking a look at them right now and have downloaded and updated here. I'll report my experience with the updates.

In the first case described here, updating grub (sudo update-grub) had no effect. Problem remains

I've not experienced any issues with recent updates, including update to cryptsetup packages.

Can we check to see if

GRUB_ENABLE_CRYPTODISK=y

is enabled in /etc/default/grub/. If that is enabled and not commented out the system asks for a password via the shell.

A user recently upgraded via Software Center and had this issue. He can successfully boot *4.19.0-2* but the newer kernel (4.19.0-5):

@mladen Can we ask the user to do an apt-get update && apt-get upgrade? Otherwise we need to get more information.

@jeremiah.foster

The user upgraded via sudo apt update && sudo apt full-upgrade and also did sudo update-initramfs -u -k all and here's the output:

sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.19.0-5-amd64
cryptsetup: WARNING: Resume target
luks-36631c43-3d73-428b-ac97-b518d1838185
    uses a key file
update-initramfs: Generating /boot/initrd.img-4.19.0-2-amd64
cryptsetup: WARNING: Resume target
luks-36631c43-3d73-428b-ac97-b518d1838185
    uses a key file

Hasn't fixed the issue.

@mladen @jeremiah.foster

cryptsetup: WARNING: Resume target
luks-36631c43-3d73-428b-ac97-b518d1838185
uses a key file

That is the same error that the first users in this thread had, in their case from reading their crypttab and fstab files, it corresponds to the swap partition

@mladen @jeremiah.foster

cryptsetup: WARNING: Resume target
luks-36631c43-3d73-428b-ac97-b518d1838185
uses a key file

That is the same error that the first users in this thread had, in their case from reading their crypttab and fstab files, it corresponds to the swap partition

@jeremiah.foster @mak not that update-initramfs did not fixed issues, but it made it worse: customer now cannot boot even the older kernel version.

We need to determine where the issue is. Can we get a copy of /etc/crypttab? Also, can the customer boot into recovery mode? Is there any other information on the situation like log messages or output from 'journalctl -xe'?

In the cases where the /etc/crypttab is pasted (in the original post in this issue) I can see that both crypttabs have /

 <name>               <device>                         <password> <options>
luks-991a8170-d20f-48dc-b858-2ffb86d8dada UUID=991a8170-d20f-48dc-b858-2ffb86d8dada     /crypto_keyfile.bin luks,keyscript=/bin/cat

Can those users try with;

# <name>               <device>                         <password> <options>
luks-991a8170-d20f-48dc-b858-2ffb86d8dada UUID=991a8170-d20f-48dc-b858-2ffb86d8dada  /etc/cryptsetup-initramfs/cryptkey.gpg luks,keyscript=decrypt_gnupg-sc

or

# <name>               <device>                         <password> <options>
luks-991a8170-d20f-48dc-b858-2ffb86d8dada UUID=991a8170-d20f-48dc-b858-2ffb86d8dada    none luks

Note

What is happening here is that we're changing the options section in the /etc/crypttab file to move away from "keyscript=/bin/cat" to either a decrypt_gnupg-sc script or to none.

I think this is relevant: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930696
IMO a keyscript is unnecessary.
I ran into it when migrating my unencrypted PureOS to a new disk and adding LUKS to it at the same time (I first tried a fresh install but the installer failed for which I already opened a separate bug). I wrote up a quick guide on how to do that on Pureos/Debian, by the way: https://github.com/jjakob/wiki/wiki/Migrating-an-unencrypted-PureOS-Debian-install-to-fully-encrypted
Also getting rid of the unencrypted /boot partition would largely improve the security, I would highly recommend it as the default for the encrypted install. There's no need to enter the passphrase twice if a keyfile is used, and it works flawlessly.

This is my working crypttab:

# <name>               <device>                         <password> <options>
crypto-nvme0n1p1 PARTUUID=de043f60-01 /etc/cryptkeys/nvme0n1p1.key luks

/etc/cryptsetup-initramfs/conf-hook has:
KEYFILE_PATTERN="/etc/cryptkeys/*.key"

initramfs.conf has:
UMASK=0077

/etc/cryptkeys is mode 700, the keyfile is mode 400. Created with dd bs=512 count=4 if=/dev/random of=/etc/cryptkeys/sdX#.key iflag=fullblock.

@joao.azevedo please note that bundling multiple issues makes them all harder to track - e.g. I would be uncomfortable assigning the issue report to myself if knowledgable about only a subset of involved issues, would only flag it as done when all parts were done, and would have a hard time noticing when all parts were done.

I recommend to file one report per issue. Issues are easy to merge if multiple issues turn out to be the same.