Can't access encrypted disks at boot after zypper dup

Hi all,

it looks like nobody else has run into this problem recently, so I’m opening a new thread.

I’ve recently updated a Tumbleweed machine I’m not using often from a rather old snapshot (April 2019) to the current one. I first tried in a Gnome terminal but the update failed with a Gnome shell crash. So I rolled back to previous state and tried again running zypper dup on a text console. At first glance this looked ok, but after reboot the system gets stuck after I enter the passphrase for disc encryption, giving the error

[xxxx] device-mapper: table: 254:0 crypt: unknown target type
[FAILED] Failed to start Cryptography Setup for <my disc>.

After that the system hangs for a while and then drops into dracut shell.

In rdsosreport.txt I can see errors that seem to indicate the new kernel doesn’t support the encryption scheme I’m using.


   40.564707] linux-9i7y systemd-cryptsetup[469]: Set cipher aes, mode xts-plain64, key size 256 bits for device /dev/disk/by-uuid/20fb402f-0581-4938-bf29-d62d266e0e5c.
   41.731681] linux-9i7y systemd-cryptsetup[469]: device-mapper: reload ioctl on   failed: Invalid argument
   41.728201] linux-9i7y kernel: device-mapper: table: 254:0: crypt: unknown target type
   41.728232] linux-9i7y kernel: device-mapper: ioctl: error adding target to table
   41.733408] linux-9i7y systemd-cryptsetup[469]: Failed to setup dm-crypt key mapping for device /dev/disk/by-uuid/20fb402f-0581-4938-bf29-d62d266e0e5c.
   41.733508] linux-9i7y systemd-cryptsetup[469]: Check that kernel supports aes-xts-plain64 cipher (check syslog for more info).
   41.733549] linux-9i7y systemd-cryptsetup[469]: device-mapper: remove ioctl on temporary-cryptsetup-469  failed: No such device or address
   42.734022] linux-9i7y systemd-cryptsetup[469]: device-mapper: table ioctl on   failed: No such device or address
   42.734839] linux-9i7y systemd-cryptsetup[469]: device-mapper: remove ioctl on temporary-cryptsetup-469  failed: No such device or address
   43.734635] linux-9i7y systemd-cryptsetup[469]: device-mapper: table ioctl on   failed: No such device or address
   43.735458] linux-9i7y systemd-cryptsetup[469]: device-mapper: remove ioctl on temporary-cryptsetup-469  failed: No such device or address
   44.735151] linux-9i7y systemd-cryptsetup[469]: device-mapper: table ioctl on   failed: No such device or address
   44.735959] linux-9i7y systemd-cryptsetup[469]: device-mapper: remove ioctl on temporary-cryptsetup-469  failed: No such device or address
   45.735429] linux-9i7y systemd-cryptsetup[469]: device-mapper: table ioctl on   failed: No such device or address
   45.735686] linux-9i7y systemd-cryptsetup[469]: device-mapper: remove ioctl on temporary-cryptsetup-469  failed: No such device or address
   45.735721] linux-9i7y systemd-cryptsetup[469]: Failed to activate with specified passphrase: Input/output error
   45.735917] linux-9i7y systemd[1]: systemd-cryptsetup@cr_nvme\x2dCA3\x2d8D512\x2dQ11_NVMe_LITEON_512GB_TW092X04LOH0084J003B\x2dpart2.service: Main process exited, code=exited, status=1/FAILURE
   45.736133] linux-9i7y systemd[1]: systemd-cryptsetup@cr_nvme\x2dCA3\x2d8D512\x2dQ11_NVMe_LITEON_512GB_TW092X04LOH0084J003B\x2dpart2.service: Failed with result 'exit-code'.
   45.736279] linux-9i7y systemd[1]: Failed to start Cryptography Setup for cr_nvme-CA3-8D512-Q11_NVMe_LITEON_512GB_TW092X04LOH0084J003B-part2.
   45.736406] linux-9i7y systemd[1]: Dependency failed for Local Encrypted Volumes.
   45.736477] linux-9i7y systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'.
   45.736619] linux-9i7y systemd[1]: Reached target System Initialization.
   45.736678] linux-9i7y systemd[1]: Reached target Basic System.
  169.723093] linux-9i7y dracut-initqueue[395]: Warning: dracut-initqueue timeout - starting timeout scripts

Any help solving this or triaging further would be much appreciated.

Regards, Tim

Can you boot with a previous kernel? (Use the “Advanced” menu choice in the grub menu to select the boot kernel).

No, the same error occurs with both kernels that I’m offered:

  • 5.2.9.1
  • 5.0.3.1

I’ve been suggested offline to try rebuilding my inirtd, which didn’t solve the problem yet, but I wanted to report the steps I’ve tried.

[ol]
[li]Boot from the latest Tumbleweed live rescue image[/li][li]Mount the encrypted volume[/li][LIST=1]
[li]I do this by double-clicking on the volume icon in the graphical desktop of the live system. It gives me an error but the volume is nevertheless accessible afterwards under /run/media/linux/<uuid>[/li][li]Mounting from the command line does not work, mount complains that it does not support the file system type, manually decrypting first and then mounting didn’t work with the instructions I found on the web so I left it there[/li][/ol]

[li]Mount the relevant directories from the live system into the mounted “actual” root partition[/li][ol]
[li]cd /run/media/linux/<my system root>[/li][li]mount -t proc /proc proc/[/li][li]mount --rbind /sys sys/[/li][li]mount --rbind /dev dev/[/li][li]mount --rbind /var var/[/li][li]mount /dev/<my boot partition> boot/efi[/li][/ol]

[li]sudo chroot /run/media/linux/<my system root>[/li][li]dracut -f[/li][li]update-bootloader[/li][/LIST]

At first glance this seems to work fine, and a new initrd is generated, seemingly including all needed kernel modules for encrypted volumes. But once I exit chroot, the changes seem to be gone, and rebooting the system still shows unchanged behavior. I have tried to properly unmount the previously mounted directories in reverse order but was only able to do so with /proc, the others were claiming “device busy”. So I just poweroff the live system and reboot to hard disk.

Is it likely that skipping the unmount causes the changes to be non-persistent? Any ideas how I can manage to unmount those volumes after dracut?

Then I think it is not a kernel problem. Perhaps there was an update to “cryptsetup”.

That is not supposed to be a problem. But you can exit from the chroot environment (just type exit), and them unmount before you reboot.

Are you using “btrfs”? If you are, then the first think after that “chroot” should be:

mount -a

That’s to make sure that the “btrfs” subvolumes are mounted.

If you are using UEFI booting, then you also needed “/boot/efi” to be mounted (relative to the system you are trying to repair).

I have exactly the same problem here but on tumbleweed with KDE. It stopped asking for passphrase at the boot for the new kernel.
Booting with previous kernels bring same problem but I have successfully rolled back to previous kernel 5.2.9-1 from last snapshot.

I’m relatively new to opensuse, so I’m not familiar with all tools.

I’m not updating anymore until it’s resolved. Help appreciate!

Regards,
Bernard :frowning:

Thanks to all who tried to help. I have reinstalled the system from scratch now since that seemed like the faster solution.

Yes, sometime a clean reinstall is the best solution.

Thanks for reporting back.

I’d rather not reinstall. Any other suggestion ??? :frowning: