Just as a PSA for those of you thinking about moving to 24.04. It is real buggy. I have setup hibernation on it via this guide:
How to Enable Hibernate Function in Ubuntu 24.04 & 22.04 LTS | UbuntuHandbook
It works. Hibernation and suspend, BUT, about 1 or 2 hibernation cycles in, and all of a sudden the kernel isn’t able to address the NVME on reboot. The whole system is toast.
Has anyone else had success with 24.04?
I have the 13th gen and been using 24.04 for two weeks. I attempted to set up hibernation but had issues with the swap file on btrfs (possibly due to that bug mentioned in your link). Rather than trying to resolve that, I decided to switch to the way using a swap partition. So far it has been working fine.
Hi @Lutetium , can you elaborate more on this please, would be nice to try again on Ubuntu 24.04 
thanks.
Certainly! Here is what I’ve tried (can be not in a professional or even correct way)
Initially, there’s no swapfile. So, I used btrfs subvolume create and btrfs filesystem mkswapfile to create one. However, no matter how big the size I set to the swapfile, I received the “not enough swap space” message when trying to hibernate. Then I switch to swap partition with:
use gnome-disk-utility to reduce the size of my filesystem partition. Then, create a partition and set its type to Linux swap.
add the line to /etc/fstab: /dev/nvme0n1p6 swap swap defaults 0 0
mkswap /dev/nvme0n1p6 then activate it with swapon /dev/nvme0n1p6
edit /etc/default/grub: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=/dev/nvme0n1p6"
update GRUB with update-grub
test with systemctl hibernate and it worked.
Are you using LUKs encryption?
I am using swapfile on btrfs on lunks with hibernation just fine on arch just fine. Did you enable the swapfile you made, add it to the fstab and add the resume offset to the kernel parameters?
A default Ubuntu install will have a swap file at /swap.img and this is reflected in fstab as well.
I have done this with 24.04 at least 5 times. There is a bug that is captured in the link I posted with Ubuntu that you have to circumvent. I believe it is this workaround that is causing the instability. Things seem to be working just fine, and then all of a sudden resuming from a hibernation or a cold boot sees the kernel panic and the nvme drive is not accessible.
I believe for this reason using a swap partition is just more stable. I plan on using a partition on my expansion card storage.
Well that is certainly cursed. have you tried using uuid in the resume parameter instead of nvmewhatever?
I was addressing the “not enough swap space issue” not this issue though.
Swap partition is probably the more intended way but I prefer swap files cause doing encrypted swap partitions is a pain in the ass compared to just using a swapfile on my already encrypted main partition, also they are a lot easier to resize after the fact.
I always only use the uuid. I prefer the more specific naming approach.
Absolutely agree. Using luks means using a swap file is way easier to work with. On 22.04 I was doing this and it was rock solid. Sometimes the running image would get a little buggy, but this was usually after 20+ hibernate and resume sessions. A simple restart cleared things up.
For me, having my / encrypted is enough. If I am worried about something, I just don’t hibernate in that situation. I also like that I am putting the write cycle on the expansion storage. If it dies, I can more easily replace it, etc. Also if the swap partition fails, it doesn’t prevent booting or the use of the system.
Fully agree
Wait you mean encrypted root and unencrypted swap?!
Not really much point in the encrypted root if you can just pull it’s encryption key out of the unencrypted memory image.
Fair enough, though you gotta do a hell of a lot of hibernating to wear out a semi decent ssd.
Hence, why I don’t hibernate if I am worried about compromise. If there is no image on the swap partition, there is no vulnerability.
I personally think encryption is over the top most of the time, and so I am not so rigorous on using it all the time. I am happy to have it when I am in a hotel on a business trip, but at home it is pointless IMHO.
I feel like encrypted root and unencrypted swap is a good compromise there.
And you are sure it cleans up the previous one without a trace?
I don’t really disagree here. There are other advantages to encryption like being able to rma drives without having to be able to wipe them and stuff like that (main reason my nas has encryption).
I feel like that is a really backwards compromise but it’s your computer in the end.
There is just so much stuff in a memory image that really should never touch a disk unencrypted. The files on your root at least kind of expect to be on a disk, in a memory images you got stuff like the decrypted contents of you password manager and stuff like that.
Encrypted root and unencrypted swap is definitely better than both unencrypted but it does punch a huge hole in the security in exactly the most sensitive place.
I hope ubuntu fixes whatever weirdness is going on there soon so stuff like this won’t be nessecary.
If encrypting your swap partition wasn’t some exercise in dark magic, I would happily do it. Typing in two encryption passwords at boot wouldn’t bother me at all. Sadly this just doesn’t seem to be a thing.
I have done it before, it’s a bit of a pain (hence I migrated to swapfile) but does not require 2 passwords.
Alternatively you could also use the sed functionality of your ssd and use “unencrypted” root and sap on top of that. Even if the encryption was flawed which it may or may not be you’d at least have everything covered and even gain a bit of performance. Setting up sed is pretty easy.
Although I have read that most people advocate for software encryption instead of a drive’s built in hardware encryption. Mainly the rational for this is that if the hardware based encryption fails you are just screwed. Your chances with software encryption is a little easier, because unless the whole drive fails you are still able to decrypt.
Pretty sure the biggest one is that it’s a black box with a bog “trust me bro” from the manufacturers about the actual implementation. Also software encryption is very fast and these days very convenient (except for your case XD).
Also back when I actively used sed drives it was very easy to do a warm-boot attack
That is somewhat similar to sed too at this point, unless you se the bios to set the drive password and that bios does something weird to the password and it won’t work on other devices, that definitely never happened to me with a destroyed x260 before. If you use the on drive pre-boot the setup is pretty portable too.