Cryptsetup and initramfs issues after upgrade via Gnome Software
Open, HighPublic

Description

This is a placeholder to compile information regarding several cases with initramfs and cryptsetup that we have seen in a short period of time. Usually after the user does an upgrade with Gnome software.

All 3 cases so far share the same story: Users cannot unlock LUKS after a recent update, and are dropped to recovery shell.

They can only unlock LUKS and login via advanced options in GRUB with an older kernel.

All 3 cases were reported in less than two weeks

Case 1

Machine fails unlock encrypted partition, after failed attempts machine drops to initramfs.
User was asked to try to boot in graphic mode with an older kernel via advanced options in GRUB and run the following commands:

  • sudo dpkg --configure -a
  • sudo apt update && sudo apt full-upgrade
  • sudo update-initramfs

dpkg --configure and full-upgrade revealed no errors

sudo update-initramfs revealed the following error:

update-initramfs: Generating /boot/initrd.img-4.19.0-5-amd64
cryptsetup: WARNING: Resume target luks-1a9af0c3-db46-4947-8b83-5ad57975ad15 
    uses a key file

These are the user crypttab and fstab files

/etc/crypttab: mappings for encrypted partitions.


 <name>               <device>                         <password> <options>
luks-991a8170-d20f-48dc-b858-2ffb86d8dada UUID=991a8170-d20f-48dc-b858-2ffb86d8dada     /crypto_keyfile.bin luks,keyscript=/bin/cat
luks-1a9af0c3-db46-4947-8b83-5ad57975ad15 /dev/disk/by-id/wwn-0x500a0751e1d8a59f-part3  /dev/urandom swap,cipher=aes-cbc-essiv:sha256,size=256
/etc/fstab: static file system information.

 <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=b64b86f5-1c85-4761-bb38-0007cf00925f /boot          ext4    defaults,noatime,discard 0 2
/dev/mapper/luks-991a8170-d20f-48dc-b858-2ffb86d8dada /              ext4    defaults,noatime,discard 0 1
/dev/mapper/luks-1a9af0c3-db46-4947-8b83-5ad57975ad15 swap           swap    defaults,noatime,discard 0 2
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

Case 2:

Machine fails unlock encrypted partition, after failed attempts machine drops to initramfs
User was asked to try to boot in graphic mode with an older kernel via advanced options in GRUB and run the following commands:

  • sudo dpkg --configure -a
  • sudo apt update && sudo apt full-upgrade
  • sudo update-initramfs

dpkg --configure and `full-upgrade revealed no errors

sudo update-initramfs revealed the following error:

These are the user crypttab and fstab files

/etc/fstab: static file system information.

 <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=7e307419-1fb1-42c2-b2c7-959957a77790 /boot          ext4    defaults,noatime,discard 0 2
/dev/mapper/luks-24cee226-f119-4e37-8b2c-67de537e66fe /              ext4    defaults,noatime,discard 0 1
/dev/mapper/luks-16eaa33b-133f-49be-8624-24bc7d2e767a swap           swap    defaults,noatime,discard 0 2
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
# /etc/crypttab: mappings for encrypted partitions.

 <name>               <device>                         <password> <options>
luks-24cee226-f119-4e37-8b2c-67de537e66fe UUID=24cee226-f119-4e37-8b2c-67de537e66fe     /crypto_keyfile.bin luks,keyscript=/bin/cat
luks-16eaa33b-133f-49be-8624-24bc7d2e767a /dev/disk/by-id/wwn-0x5002538e4052606c-part3  /dev/urandom swap,cipher=aes-cbc-essiv:sha256,size=256

Case 3:

Machine fails unlock encrypted partition, after failed attempts machine drops to initramfs
Status: Still waiting on information from the user


Why create this issue:

Although these problems reported here are probably a bug that needs investigating.

We have some users that are affected by this and waiting for a reply from us regarding this issue. And we need some input about options to recommend to the affected users to restore their systems other than just say: reinstall the system from scratch.


This is our current wiki page regarding fixing broken system upgrade


@jonas.smedegaard already suggested that:

this all looks like an issue with PureOS - particularly with how the installer creates cryptsetup (and possible related to LUKS v2 not working well with GRUB: https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html ).

joao.azevedo added a subscriber: jonas.smedegaard.
jeremiah.foster triaged this task as "High" priority.Jun 14 2019, 8:05 PM
jeremiah.foster added a subscriber: jeremiah.foster.
joao.azevedo edited the task description. (Show Details)
Wayne added a subscriber: Wayne.Jun 17 2019, 3:15 PM

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.

Add Comment