luks/cryptsetup: slow decryption + "Gave up waiting for suspend/resume device"

[marwenius]

Fresh install of SpiralLinux Cinnamon 12.231008 release.

I have selected swap (with hibernate) and btrfs. Also, the drive is encrypted.

Processor: Intel Core i7-3520M

There are two problems:

1: decryption takes a very long time:

After I have entered the password after startup, it takes over 30 seconds until the message Slot 0 opened appears.

2: when decrypting the swap partition, a strange message comes:

After the grub-menu it comes to these outputs:

cryptsetup: luks-UUID-of-sda1: set up successfully
Gave up waiting for suspend/resume device

It also takes almost 30 seconds for the second line to appear.

Despite this error(?), hibernate works without problems. And lsblk correctly indicates that the drive has been mounted.

After switching to the Testing branch, these outputs occur:

cryptsetup: luks-UUID-of-sda1: set up successfully
cryptsetup: luks-UUID-of-sda2: set up successfully

The delay in decryption at the beginning remains, although it became less (15 seconds).

Troubleshooting steps (with the support of a major search engine):

When I run sudo cryptsetup luksDump /dev/sda1 I get the info that there are two key slots allocated on sda1. The same is true for sda2.

According to this post, this is normal: Disk encryption: Why are 2 key slots in use?

With sudo cryptsetup --verbose open --test-passphrase /dev/sda1 I found out that the password is stored in Slot 0 for sda1 (and sda2 respectively).

Also a luksDump information: The iterations for all four slots seem very high to me (over 1,000,000 each). Unfortunately, I can only change the iterations for the password-slots I have not found out how to change them for the keyfile-slots.

So I tried sudo cryptsetup luksChangeKey --iter-time 500 /dev/sda1 and did the same with sda2.

Default is 1000 (1 sec) and lowering it is not the best idea. I will try to compensate it with a strong password.

Result: Iterations for the password-slots are now at just over 300,000 and unlocking takes less than five seconds.

See also:

• 3.4 Unlocking a LUKS device takes very long. Why?
• 5.10 What is "iteration count" and why is decreasing it a bad idea?

Question:

Is there a possibility to lower the value for the luks-iterations in the Calamares installer in the live environment and include this in the documentation? At least for weaker hardware this seems to be reasonable.

Unsolved:

I couldn't figure out how the Gave up waiting for suspend/resume device message came up or why switching to the Testing branch solved this and lowered the decryption time from 30 to 15 seconds.

[marwenius]

2: when decrypting the swap partition, a strange message comes:

After the grub-menu it comes to these outputs:

cryptsetup: luks-UUID-of-sda1: set up successfully
Gave up waiting for suspend/resume device

It also takes almost 30 seconds for the second line to appear.

This message also occurs when I install SpiralLinux in VirtualBox.

[marwenius]

There are new findings regarding the Gave up waiting for suspend/resume device message: the solution is to execute the command sudo update-initramfs -u. I just tried one of the first solutions I found.

But why does it work? I have tried to find out what has changed in the following way.

Once again: Fresh install of SpiralLinux Cinnamon 12.231008 release.

After the first start after the installation I did the following:

sudo apt update
sudo apt install --reinstall rolldice
sudo update-initramfs -u
sudo apt install --reinstall rolldice

Since sudo update-initramfs -u does not create a snapshot itself, I used the trick of reinstalling rolldice before and after to look at the difference with snapper:

user@user-virtualbox:~$ snapper -c root status 2..3
+..... /boot/grub/grub-btrfs.cfg
c..... /boot/grub/grub.cfg
c..... /boot/initrd.img-6.4.0-0.deb12.2-amd64
c..... /var/tmp/snapper-apt

Since initrd.img-6.4.0-0.deb12.2-amd64 is a binary file, I didn't take a closer look at it (wouldn't know how at the moment, but maybe when I read the stuff under Miscellaneous).

Here is the output regarding grub.cfg:

user@user-virtualbox:~$ sudo diff -c /.snapshots/2/snapshot/boot/grub/grub.cfg /.snapshots/3/snapshot/boot/grub/grub.cfg
*** /.snapshots/2/snapshot/boot/grub/grub.cfg   2023-10-15 23:34:49.216808236 +0200
--- /.snapshots/3/snapshot/boot/grub/grub.cfg   2023-10-15 23:57:16.900186870 +0200
***************
*** 80,86 ****
    load_video
    insmod gfxterm
    set locale_dir=$prefix/locale
!   set lang=en_US
    insmod gettext
  fi
  terminal_output gfxterm
--- 80,86 ----
    load_video
    insmod gfxterm
    set locale_dir=$prefix/locale
!   set lang=de_DE
    insmod gettext
  fi
  terminal_output gfxterm
***************
*** 276,279 ****
--- 276,286 ----
  ### END /etc/grub.d/41_custom ###

  ### BEGIN /etc/grub.d/41_snapshots-btrfs ###
+ if [ ! -e "${prefix}/grub-btrfs.cfg" ]; then
+ echo ""
+ else
+ submenu 'SpiralLinux snapshots' {
+     configfile "${prefix}/grub-btrfs.cfg"
+ }
+ fi
  ### END /etc/grub.d/41_snapshots-btrfs ###

I assume it is the changes in initrd.img-6.4.0-0.deb12.2-amd64 that make the difference and not the changes in grub.cfg.

Question:

Would it be possible to run the sudo update-initramfs -u command via a post-install script?

Miscellaneous

A few bookmarks I want to look at in this context:

• https://wiki.ubuntu.com/Initramfs
• https://www.linuxfromscratch.org/blfs/view/svn/postlfs/initramfs.html
• https://access.redhat.com/solutions/24029
• https://linuxconfig.org/how-to-uncompress-and-list-an-initramfs-content-on-linux
• https://manpages.debian.org/stretch/initramfs-tools-core/unmkinitramfs.8.en.html

[geckolinux]

Thanks @marwenius for the excellent debugging research. It looks like we both spent yesterday looking at different aspects of the same core issue. Here's what I finally arrived at: https://github.com/calamares/calamares/issues/2217

Would it be possible to run the sudo update-initramfs -u command via a post-install script?

Technically Calamares is already doing that. (Look for initramfs in the list of steps that Calamares runs in /etc/calamares/settings.conf). But the problem I believe is that initramfs-tools has special handling when running in the chroot environment that Calamares uses to install the target system, specifically in /usr/share/initramfs-tools/hooks/resume :

# Try to autodetect the RESUME partition, using biggest swap device that
# is not ephemeral.  We need to be able to read the listed swap partitions.
resume_auto=
if ! ischroot && [ -r /proc/swaps ]; then
...

Since initrd.img-6.4.0-0.deb12.2-amd64 is a binary file, I didn't take a closer look at it (wouldn't know how at the moment, but maybe when I read the stuff under Miscellaneous

If this helps you can inspect its contents with lsinitramfs : https://manpages.ubuntu.com/manpages/xenial/man8/lsinitramfs.8.html

Here's a few other possibly relevant links:

• https://cryptsetup-team.pages.debian.net/cryptsetup/README.initramfs.html#resume-device-support
• https://manpages.debian.org/bookworm/initramfs-tools-core/initramfs.conf.5.en.html

[marwenius]

Thanks also to you for responding quickly and trying to find solutions to problems :-) And for the links!

Back to topic ...

One cause of the slow boot process seems to be grub, exemplified by this post (many similar ones can be found): Slow decrypt in GRUB

In short, grub is slow to decrypt an encrypted /boot. An unencrypted /boot would be faster here, but has other risks, as you can read there for example: Unencrypted boot partition risks

I don't know if you deliberately chose to encrypt /boot for this (or a similar reason), but perhaps it would be worth considering not encrypting /boot? Or maybe have something documented somewhere on how I can change to an unencrypted /boot myself.

[geckolinux]

I honestly don't know much about encrypted installations, so I just left the Calamares default configuration for everything related to LUKS. I'm pretty sure that there is no configuration option to only encrypt some parts of the filesystem when using the automated Erase Disk or Replace Partition options in Calamares. But it should be possible with manual partitioning, you can create two new partitions (or three if you want a swap partition), one would be fairly small and not encrypted, with /boot mounted to it, and the other partition large with / mounted to it and the Encrypt option enabled. I'm sure there's a way to convert your existing installation, but it sounds much easier and faster to just reinstall. You'd probably want to test it first in VirtualBox or something before committing your bare metal installation.

[geckolinux]

Question:

Would it be possible to run the sudo update-initramfs -u command via a post-install script?

I've been testing this as a workaround, and it seems to work. If you want to try it there are some release candidate ISOs in the Sourceforge in the staging directory.

[marwenius]

I've been testing this as a workaround, and it seems to work. If you want to try it there are some release candidate ISOs in the Sourceforge in the staging directory.

I will try to test today or tomorrow. Thanks!

[marwenius]

Scenario after installation: When the system was first started, the message Gave up waiting for suspend/resume device appeared. After a restart (i.e. the second start), the message disappeared. Is this the expected behaviour?

[geckolinux]

Scenario after installation: When the system was first started, the message Gave up waiting for suspend/resume device appeared. After a restart (i.e. the second start), the message disappeared. Is this the expected behaviour?

Yes, unfortunately it doesn't appear to be possible to generate the proper initramfs within the chroot environment that Calamares uses, so I had to include a one-shot systemd service that runs on the first boot.

[geckolinux]

https://github.com/SpiralLinux/SpiralLinux-project/releases/tag/12.231120