It seems like my problem may have been a different underlying cause with similar symptoms.
In my case, the entry in /etc/crypttab didn't match the location of the encrypted partition. Partition is on sda3, but /etc/crypttab read:
sda6_crypt UUID={uuid} none luks,discard
It appears that when the initramfs image is generated (as when a new kernel is installed, but also on other updates), a mismatch between the naming in /etc/crypttab and the actual partition causes an error (which of course I didn't see) such that the file in the initramfs (located at /cryptroot/crypttab) was empty (zero bytes). This lack of a file is what causes the boot process to hang.
Correcting /etc/crypttab to:
sda3_crypt UUID={uuid} none luks,discard
solves the problem. Of course, if your initramfs is already honked it needs to be regenerated:
sudo update-initramfs -u
But future updates should proceed normally. Thanks to everyone who provided pointers/thoughts that helped me track this down.
It seems like my problem may have been a different underlying cause with similar symptoms.
In my case, the entry in /etc/crypttab didn't match the location of the encrypted partition. Partition is on sda3, but /etc/crypttab read:
sda6_crypt UUID={uuid} none luks,discard
It appears that when the initramfs image is generated (as when a new kernel is installed, but also on other updates), a mismatch between the naming in /etc/crypttab and the actual partition causes an error (which of course I didn't see) such that the file in the initramfs (located at /cryptroot/ crypttab) was empty (zero bytes). This lack of a file is what causes the boot process to hang.
Correcting /etc/crypttab to:
sda3_crypt UUID={uuid} none luks,discard
solves the problem. Of course, if your initramfs is already honked it needs to be regenerated:
sudo update-initramfs -u
But future updates should proceed normally. Thanks to everyone who provided pointers/thoughts that helped me track this down.