Solved !
In the grub config, I set resume=UUID=xxxxx as all guides tell, but for an encrypted swap you actually have to use the device path instead (resume=/dev/mapper/luks-a0a21122-091b-46ed-89a5-a721e59ae4db for me)
This took me way too long to find out :’)
Yeah this is why configuring hibernation with encrypt is so tricky. I have yet to find one that just tells you how to take a pre-existing swap file (as is the case in Ubuntu, for example) and expand it to be used for hibernation, and then how to set grub to resume from it after decryption has occurred.
If you have the time and energy, it would be awesome if you could detail how you set it up in your case. 
Adopts Yoda voice…On or Off there is no hibernation! 
I can wait a few seconds.
It’s really not that tricky though! Here’s my partition tree (output of lsblk) on my Framework:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 232.9G 0 disk
├─nvme0n1p1 259:1 0 487M 0 part /boot/efi
├─nvme0n1p2 259:2 0 488M 0 part /boot
└─nvme0n1p3 259:3 0 231.9G 0 part
└─nvme0n1p3_crypt 254:0 0 231.9G 0 crypt
├─Crypto-Root 254:1 0 93.1G 0 lvm /
├─Crypto-Home 254:2 0 111.8G 0 lvm /home
└─Crypto-Swap 254:3 0 14.9G 0 lvm [SWAP]
If you set it up this way during install, it’s all pretty seamless (since the resume= parameter gets setup during installation) and "Just Works"™.
I’ve been using hibernation for about a month, and it works wonderfully.
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 931.5G 0 disk
├─nvme0n1p1 259:1 0 2G 0 part /boot
├─nvme0n1p2 259:2 0 865.5G 0 part
│ └─core 254:0 0 865.5G 0 crypt /
└─nvme0n1p3 259:3 0 64G 0 part
└─swap 254:1 0 64G 0 crypt [SWAP]
WD_BLACK SN850 1TB + 64GB RAM.
It’s Arch, I’m booting with systemd-boot, and using systemd and sd-encrypt in mkinitcpio.conf. This unlocks LUKS using systemd-cryptsetup, and allows me to set the same password on both volumes, to have them both unlocked after typing in the password once. Which, in turn, lets me skip LVM2 and use Btrfs for volume management on my single data partition.
On top of this, I’ve symlinked suspend.target to suspend-then-hibernate.target, and set the timeout to 2h. Any suspend will enter hibernation if left alone, and resuming takes about 10s. Along with saving some power, it’s a clean way to re-lock LUKS after a period of inactivity.
I’ve previously had some random reboots, but with enable_psr=0, the whole setup works perfectly reliably. The machine is a joy to use 
.
sounds glorious dk505! Thanks for sharing!
Sounds like we have a similar configuration as well. I’ve been thinking about giving Arch a try, but not sure I really need it. Glad to see hibernation performance there is excellent.
Anybody have a link to or want to throw me a bone on expanding the default Ubuntu swap file under LUKS? The drive is encrypted, and it would be great to be able hibernate using that file. The only problem is that I have never found a guide that walks your through that.
Much thanks in advance!
FYI: My Framework is back on Ubuntu!
@2disbetter I upgraded my initial nvme (500gb) to a new one (1tb). I have everything encrypted with luks except /boot.
Cloned the initial nvme to the new one and everything worked. After that I expanded my /home luks partition using this method I found online. Looks harder than it is.
But for you it might get a little for complicated because if your disk is already partitioned you might first have to make another partition smaller to expand your swap partition.
Worked on Arch i3wm Xorg
Initial setup:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 476,9G 0 disk
├─nvme0n1p1 259:1 0 300M 0 part /boot/efi
├─nvme0n1p2 259:2 0 442,4G 0 part
│ └─luks-95ed0f34 254:0 0 442,4G 0 crypt /run/timeshift/backup
│ /var/tmp
│ /var/log
│ /var/cache
│ /srv
│ /root
│ /home
│ /
└─nvme0n1p3 259:3 0 34,3G 0 part
└─luks-e7274619 254:1 0 34,3G 0 crypt [SWAP]
I can setup hibernation using a swap partition. I would like to expand the default vbubuntu_swap file is setup when you enable LUKs encryption at install.
The reason why this would be ideal, is that file is already encrypted, and so your swap partition would be as well.
@2disbetter Sorry, misunderstood you. Thought you wanted to expand a luks swap partition. Never tried a swap file because they are complex to hibernate.
This is how I would increase a swap file.
First the swap file has to be deactivated before its size can be changed.
sudo swapoff <swapfile>
Like when creating a fresh swap file we use dd to fill the file with
zeroes. But the trick is to add the parameter seek to leave the beginning
of the file unchanged. So we do not need to change the swap file offset
in the parameters for the Linux kernel.
To increase the size of the swap file type
sudo dd if=/dev/zero of=<the swap file> bs=1M seek=<S> count=<C>
where you choose integers S and M such that (S+C)*1M is the desired size of
the new swap file, S>0 and S*1M is smaller than the current size of
the swap file.
Format the swap file:
sudo mkswap <swapfile>
This should also detect when you created a hole in the file by not choosing S properly.
Then reactivate the swap file:
sudo swapon <swapfile>
You’re done.
Thanks, but could you show/tell me how to do that with the luks encrypted version that is configured by default when installing Ubuntu?
Sorry. I first understood, that you had a proper file as a swap file. However I now see that you are using a swap partition.
I think for hibernation a swap file is easier to install. You could follow this HowTo:
https://ubuntuforums.org/showthread.php?t=1042946
In what follows I try to explain how to increase the swap partition and use it for hibernation. But this process is more dangerous and you should be prepared to lose all you data. (Backup!)
First I have to say, that I could not figure out how to get initramfs to generate initial ramdisks that can resume from hibernation. Therefore, I switched from the default tool initramfs to dracut.
sudo apt install dracut
To configure dracut for hibernation add the file dracut.conf and add the following lines:
add_dracutmodules=" resume "
add_device+=" /dev/mapper/vgubuntu-swap_1 "
Install the new initial ram disk:
sudo dracut -f
Now let’s deal with the logical volumes on the encrypted LVM.
The problem is, that the logical volume with the root partition has to be decreased to get space for the swap partition. This cannot be done as long as the root partition is active. Therefore we have to boot into a system that uses a different root partition. The Ubuntu installation ISO is well suited for this purpose. So boot from the Ubuntu installation ISO. Select «Try Ubuntu». After the desktop has appeared, click on the disk symbol with the lock at the left edge of the screen. You should be prompted for the password of your encrypted partition. Enter it. Then use the terminal to change the sizes of the logical volumes like this:
sudo lvresize -L-5G -r /dev/mapper/vgubuntu-root
sudo lvresize -l100%FREE /dev/mapper/vgubuntu-swap_1
sudo mkswap /dev/mapper/vgubuntu-swap_1
Adapt the size by which the root partition is decreased (5G in the example) to your needs. You also can enter it with other units, for example in megabytes with the M suffix.
Note, the -r is important. Without it the file system size remains unchanged and decreasing the logical volume would cut off a part leaving you with a corrupted file system.
After removing the installation ISO and rebooting, you should be able to start hibernation with this command:
sudo systemctl hibernate
It depends on which desktop environment you are using, how you can configure a more convenient way for this.
I don’t intentionally use hibernate, but my system appears to drop into a hibernate state if the battery gets too low in sleep. I woke up one morning to a dead laptop but a perfectly preserved session after it booted, so I think it woke and hibernated at the 5% mark. I may be misremembering.
This was the missing piece to the puzzle I was looking for. To be clear this allows someone to take the default swap file (vgubuntu/swap_1) that is made during the Ubuntu install process and use it for hibernation purposes. The benefits of which are the speed the NVME supports, and your swap file will be encrypted, if you set up luks, as your entire drive is already.
One caveat though is unlike a standard swap file used on another drive or partition, where using the logical drive location is necessary as @jean points out here:
you still need to use the resume=UUID= format with the vgubuntu swap file.
Outside of this you will have beautiful hibernation service on your Framework.
Now back to seeing if I can get hibernation support added to the pi OS kernel.
I’m glad I could provide a missing piece to the puzzle.
Yes, you are right. I forgot to mention that. You still have to have the resume kernel parameter. So in /etc/default/grub after GRUB_CMDLINE_LINUX_DEFAULT= there should be resume=<reference to the swap partition>. However, I prefer it as
GRUB_CMDLINE_LINUX_DEFAULT="{<other parameters>} resume=/dev/mapper/vgubuntu-swap_1 {<more other parameters> }"
This also works and is easier to read.
Thank you once again! I wasn’t aware would could use the address in the place of the UUID altogether. I agree that this looks better and easier to read.
I read online that hibernation takes longer to boot up again compared to normal start up because it will have to read the files and all that. How are your experiences on that?
I really love the feeling of opening a laptop and instantly go to work but the battery drain of using sleep is quite heavy for me. I also rarely do something that I couldn’t just open again after a fresh start up. And given that the start up already takes quite a while on the framework (have to measure it but it is surprisingly long on fedora 35) - I didn’t want to add extra time by hibernating.
I know a few more seconds is not the world but especially when commuting short distances by train or bus it I notice I think twice about getting my laptop out of the back to work a bit. So the faster it is up and running the more motivated I might be.
So long story short - what are your experiences with the timings on linux (fedora at best)?
So, hibernation definitely takes a bit longer than a fresh boot. But in my case, the pre-boot stage is what takes the most time (since I have to enter my encryption password and such), so maybe I’m more insensitive to those little differences.
Oh, and I’m on Debian sid.
In my experience, my boot speeds are like this, in order from fastest to slowest:
I personally use deep sleep + hibernation after a delay to save power. Even though waking from that sleep is unbearably slow, I use it anyway because waking from hibernation means putting my password in for drive encryption again. (I’d forego password for TPM, but that would mean enabling secure boot which then means no hibernation, defeating the purpose).