Hibernation? Using it?

@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.

2 Likes

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.

2 Likes

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.

1 Like

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.

1 Like

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.

2 Likes

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.

1 Like

In my experience, my boot speeds are like this, in order from fastest to slowest:

  • s2idle wake (aka modern sleep)
  • from scratch boot
  • hibernation boot
  • deep sleep wake (aka S3)

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).

2 Likes

Not OP, but I set my wife’s laptop up with a similar setup to OP. The benefit of going with hibernation, in addition to power concerns, is the ability to encrypt the system state in hibernation. When you go in and out of sleep, my understanding is that all your data is just sitting there waiting to be sniffed. Setting up hibernation with an encrypted swap means that this is no longer the case.

On the other hand, encryption is not a “free” operation. For my setup, which includes an encrypted swap, root, and boot, the whole process takes about 23 seconds. This is probably more than a normal encrypted swap setup, since having an encrypted boot slows down the whole process, AFAIK. I probably wouldn’t do this setup again, since I’m not sure if I should care about that attack vector, and it would probably be more useful for me to work on setting up the TPM.

2 Likes

Framework+gentoo here.
standard gentoo guidelines + adding resume partition:

linux /vmlinuz-5.15.41-gentoo root=/dev/nvme0n1p3 ro mem_sleep_default=deep resume=/dev/nvme0n1p2

makes hibernation (dumping into disk) working.
Also, when installed proper extensions
https://extensions.gnome.org/extension/755/hibernate-status-button/

and enabling them via gnome-shell-extension-prefs,
makes restoring working nice, password-locked

Time - up to a minute (i7).
The only cons - you need much disk space >= RAM (see guidelines for your distro)

The only thing I’m fighting with is “hibernation on lid close”) - this involves some diving into details & maybe some coding

Worth noting that the hibernation restriction with secure boot is the result of the Linux lockdown patches, which disable hibernation on secure boot systems due to there being no practical way (at the moment) to verify that the hibernation image is a secure, verified image. It’s possible to disable these patches (if you build the kernel yourself) or use a distribution that doesn’t enable those patches by default (like Arch). There’s also currently work underway to enable hibernation securely, too, so this may be changing soon.

I’m currently using a LUKS + TPM + SecureBoot setup this way.

Indeed, I’ve been waiting on that for a while, but I haven’t seen much since that blog post.

I didn’t realize that Arch disabled lockdown. I’ll have to try out enabling secure boot, then. My personal threat model could probably just ignore that kind of attack as too difficult.

Is that really a concern when the image in question is encrypted and has to be un-encrypted before being able to use it to resume?

I think the threat model here assumes that root level compromise is possible, so it’s possible for an attacker to compromise a running system (or boot an older signed kernel with a vulnerability) and create a doctored hibernate image to gain persistence.

Thanks @2disbetter and every one in this thread! I learnt a lot about about Linux Ubuntu and hardware settings! I had a Mac hardware, and for my everyday work, I missed the “save stated” or “reboot and find the same apps and windows open”. Now it is well set up and running and hibernating.

FrameWork 13, 12th Gen Intel, swap partition, Ubuntu 22.04.