Swapon swap partition "went away"

Ubuntu Version:

24.04.2 LTS

Desktop Environment (if applicable):

GNOME

Problem Description:

Setting a swap partion in swapon seems to be non-persistent.

I would like to enable hibernation on my system because all other sleep methods are less reliable on my somewhat compromised machine. They seem all seem to fail to come back up at times. Tried leaving the system, suspending it, pressing the sleep mode key on the keyboard. None is reliable, at least not on this system.

So, I created a swap partition on my NVME and hibernate to there.

This works, until it doesn’t. And I then have to reboot the system.

This morning, I tried looking into the problem.

$ sudo systemctl hibernate
[sudo] password for scohen: 
Call to Hibernate failed: Not enough suitable swap space for hibernation available on compatible block devices and file systems

Say what???

I saw this same message a few days earlier. I had then executed this command and it worked:

sudo swapon PARTLABEL=/dev/nvme0n1p4

I was then able to reliably hibernate my system until it stopped working again yesterday.

~$ swapon -T --show returned no output. My swap partition had gone away!

I opened gparted just now. There I noticed that when I highlighted my swap partition (which still existed) there was “swapon” item on the Partition menu. I clicked it, closed GParted, and then, once again, I was able to hibernate the system. (Sorry, GParted disables print screen for some reason or I’d include a screenshot.)

But how confident should I be that this swap partition will persist? Something caused it to go away before and I don’t know what that was.

I do have one idea. I don’t know if it’s relevant or not. But I’ll share it with you. After successfully hibernating the system, I closed the lid of the laptop. I don’t usually do this. When I opened it back up, the system came on without pressing the power button, in some sort of disabled mode where no keypresses or mouse clicks did anything, forcing reboot. From that point on, hibernation no longer worked. Again, this may or may not be relevant.

But why would a swapon enablement of a swap partition go away?

Relevant System Information:

Lenovo Thinkpad P16 Gen 2
NVidia RTX 3500 Ada Gen GPU.

Screenshots or Error Messages:

What I’ve Tried:


It will only persist if you have an entry in /etc/fstab (or I guess a systemd unit that calls swapon) otherwise the system simply does not know that you want to use it…

Thanks!

Well, that’s weird:

$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/nvme0n1p3 during installation
UUID=0fc27bd9-4ea4-46e6-811e-7b4e7e37fd15 /               ext4    errors=remount-ro 0       0
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=FE65-86DB  /boot/efi       vfat    umask=0077      0       1
/swapfile                                 none            swap    sw              0       0

~$ ll /swapfile
ls: cannot access '/swapfile': No such file or directory

So fstab thinks there’s a /swapfile but there isn’t. Guess I’ve gotta go in there and fix that.

Easier said than done. I edited /etc/fstab, saved it, rebooted and when I got back in /etc/fstab did not have my changes. Or rather, it did have my commenting out of the swapfile entry, but not the line that added the swap partition entry:

$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/nvme0n1p3 during installation
UUID=0fc27bd9-4ea4-46e6-811e-7b4e7e37fd15 /               ext4    errors=remount-ro 0       0
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=FE65-86DB  /boot/efi       vfat    umask=0077      0       1
#/swapfile                                 none            swap    sw

getting odder and odder.

$ blkid
...
/dev/nvme0n1p4: LABEL="swap" UUID="23ad8a7c-91b8-4fd0-9d28-ecf00e05602a" TYPE="swap" PARTLABEL="/dev/nvme0n1p4" PARTUUID="9a2f82ac-999d-42c9-b42a-c359bfe1efb3"
...

Why is there both a UUID and a PARTUUID? Should my /etc/fstab entry use the UUID or the PARTUUID as UUID?

Is the PARTLABEL wrong because it’s the same as the device name?

Would the changing by the boot process of /etc/fstab be logged anywhere that I can see?

Mine:

 less /etc/fstab | grep swap
/dev/disk/by-uuid/66384887-2cc6-4941-9d04-082bc780b027 none swap sw 0 0
┌───────────────────>
│~ 
└─> blkid | grep swap
/dev/sdc3: UUID="66384887-2cc6-4941-9d04-082bc780b027" TYPE="swap" PARTUUID="cd0af8f5-00cc-4a3e-a76d-1a8019b0750d"

for my swap partition in fstab

less /etc/fstab | grep swap
/swap.img       none    swap    sw      0       0

and yes that system is not using a swap partition.

What seems to have worked for me finally was running

sudo mkswap /dev/nvme0n1p4

and then

sudo swapon UUID=[the new UUID generated by mkswap]

and finally creating an entry in /etc/fstab with this UUID.

This produced an /etc/fstab that survived reboot and successfully hibernated the system.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.