My current setup:

  • Ubuntu 18.04.1
  • Encrypted partition with an LVM2 on it.
  • LMV
    • root (/dev/mapper/it--vg-root)
    • swap (/dev/mapper/it--vg-swap_1)
  • Random cryptswap that maps to /dev/dm-3, whatever that might be, that seems to be gone now.

What have I done:

  • Changed the swap for the system to /dev/mapper/it--vg-swap_1 via fstab
  • Changed the UUID in /etc/initramfs-tools/conf.d/resume to the new swap partition and ran sudo update-initramfs -u
  • Added resume=UUID=XXXXXXX to GRUB_CMDLINE_LINUX_DEFAULT= variable with the UUID of the new swap partition and ran sudo update-grub
  • I created a file /etc/systemd/sleep.conf with the following content:
  • I rebooted the whole system

Then I tested two cases:

  1. systemctl hibernate

The system goes to hibernation properly. It boots back up, asks me for the decryption password and opens up all the windows and applications that I had open before.

  1. systemctl suspend-then-hibernate

The systemd goes to suspend mode. My power key indicates that by blinking. After around ten seconds (mind the config in sleep.conf) it turns back on and the screen goes to a blinking terminal cursor. Then it goes down to what seems to be hibernation.

No indications that the system is still on. After pressing the power button the system comes back up, asking for the encryption key and continues to boot like it should after I typed it in.

After logging in all previously opened applications are not open anymore. Everything is closed and lost.

It seems like the computer was either shut down completely or the ram that was dumped after suspension was in fact empty, because the suspension already dumped it to the swap partition.

But those are just random theories.

My question is: how would I be able to debug this problem and find the problem?

If you have an answer to why this happening, I would take that, too :)

  • @Terrance I ran it without -k all (update my question). But I only use one kernel, so that should be fine. I'll try it anyway ;) – func0der Feb 9 '19 at 21:39
  • That shouldn't matter then. It only will apply to the running kernel. You just didn't have it at the time of my comment. I have all the settings correct on my system and the suspend-then-hibernate causes a massive non-responsive host to me. Wonder if it is a bug. – Terrance Feb 9 '19 at 21:45
  • Tried it. Sadly it did not make any difference. Though my system responses fine for me. – func0der Feb 9 '19 at 21:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.