I have configured hibernate, its working, just to make sure it will not fail sometime - this question.

I have two swap files on different devices, first is small swap on SSD, second as big as ram on HDD. Hibernate configured to small one. It works fine for now, as hibernate not always requires too much(not everything written or compressed, I don't known).

How to configure hibernate to use both swaps? Or it process them automatically and nothing need to do? At kernel options I have setup for first small swap, and its good if it will use it first(as fastest) and then second.
I don't want to make SSD swap larger as SSD is small.

leonid@DevSSD:~$ grep resume < /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="no_console_suspend initcall_debug resume=UUID=050f8852-d8f6-4979-a4e4-c3d9b981bee9 resume_offset=34816"


UUID=050f8852-d8f6-4979-a4e4-c3d9b981bee9   /   ext4    relatime,grpquota,data=ordered,usrquota,rw,errors=remount-ro,quota  0   1
UUID=3bcf1591-7033-416a-addf-9cf8e2e10c93   /home/leonid/hdd    ext4    defaults,rw,errors=remount-ro   0   1
/swapfile                   none    swap    sw  0   0
/home/leonid/hdd/swapfile   none    swap    sw  0   0
UUID=26DA-1C76  /boot/efi   vfat    defaults    0   1

Update: I have make even smaller swap for testing and setup priority. Hibernating not goes to swap with higher priority:

leonid@DevSSD:~$ swapon
NAME                      TYPE SIZE USED PRIO
/swap64k                  file  60K   0B    1
/home/leonid/hdd/swapfile file   8G   0B  100
leonid@DevSSD:~$ systemctl hibernate
Failed to hibernate system via logind: Sleep verb not supported

In short, no you have to use a single file or partition for hibernation.


There is nothing in the basic kernel documentation for Sleep States or Power Interface which says that the swap has to be in a single file. Indeed, there is some indication that the hibernation data is written to available swap space on the computer:

However, further exploration leads us to the documents for swsusp which has a short FAQ section, and the quote

Q: Does swsusp (to disk) use only one swap partition or can it use multiple swap partitions (aggregate them into one logical space)?

A: Only one swap partition, sorry.

Although this only speaks directly to partitions I would certainly interpret this as applying to swap spaces on your machine.

Your potential problem of "What if there is not enough space on my swap file". Here we run into some vagueness. The documentation assures us that the system will attempt by default to create an image about 2/5th the size of memory:

/sys/power/image_size controls the size of hibernation images.

It can be written a string representing a non-negative integer that will be used as a best-effort upper limit of the image size, in bytes. The hibernation core will do its best to ensure that the image size will not exceed that number. However, if that turns out to be impossible to achieve, a hibernation image will still be created and its size will be as small as possible. In particular, writing '0' to this file will enforce hibernation images to be as small as possible.

However the documents to not indicate what might happen if the image exceeds swap size. My own experience when I have accidenatly had swap turned off and tried to hibernate, is that nothing happens.


Does this say something about me, Ubuntu users or Linux users?

I was curious about what happens if the swapfile is too small, so I created a 44KB swapfile (that worked!) and tried to hibernate:

chick@dad:~$ swapon
/swap2 file  44K   0B   -2
chick@dad:~$ sudo systemctl hibernate
Failed to hibernate system via logind: Not enough swap space for hibernation

I further tested by using two swapfiles, the smaller one being higher priority:

chick@dad:~$ sudo swapon /swap2 -p 1
chick@dad:~$ sudo swapon /swapfile -p 2
chick@dad:~$ swapon
/swap2    file  44K   0B    1
/swapfile file  16G   0B    2
chick@dad:~$ sudo systemctl hibernate
Failed to hibernate system via logind: Not enough swap space for hibernation
  • Great answer! “[N]othing happens” in the sense that it just suspends to RAM or that it does nothing at all? – dessert Mar 9 '19 at 16:35
  • @dessert Thanks! I had just read https://meta.askubuntu.com/questions/16091/why-arent-most-questions-answered-with-references-to-documentation-or-mention-t yesterday... When I had swap off, choosing 'hibernate' simply did nothing. I thought nothing of it, re-enabled swap and went on with my life! – Charles Green Mar 9 '19 at 16:37
  • @dessert Edited question - I tested with a small swapfile. – Charles Green Mar 9 '19 at 17:05
  • 2
    @ leonid - man 2 swapon seems to indicate that there is also an "order loaded" preference in swap areas. This is an interesting question, and I migh suggest that for normal operations you load the SSD swap with a high priority, and the HDD swap with low priority, but load the HDD swap first in fstab. – Charles Green Mar 9 '19 at 18:35
  • 2
    @dessert I think the idea of scripting to add a swapfile, or change swapfiles is interesting, but I don't think it can be easily done at this time. The command systemctl hibernate as one of it's first acts checks for swap, and this seems to be integral to systemctl.c It may be possible to patch and recompile, but this is a big can of worms! – Charles Green Mar 12 '19 at 2:53

My personal experience with this: there is nothing wrong with having a smaller swap partition than available ram but in Debian Buster systemd seems to be failing if you have only a swapfile, and the priority of the swap devices must be set properly. recent versions of systemd seems to be using the swap area with the lowest priority for resume (probably to avoid failing if there's free swap but highest priority partition is already full). Also IIRC, leaving the system to assign priorities (in the negative range) did not work (feel free to prove me wrong...)

I'm unsure if the swapfile helps fitting the recovery image in the small swap partition or if a bug was introduced in the resume device selection - I don't recall if I actually verified which device was used for resume, what I know for sure is it was a regression (suspend used to work under identical conditions before last OS upgrade) and setting the priorities for swap devices did fix it.

Using uswsusp's s2disk tool did not have this issue, and I believe neither did pm-suspend.

Here's for example my swap configuration (fstab) - 16G ram (always fully used), 4g swap partition and 16g swapfile:

UUID=58e3097b-cd76-4d9b-a46b-98aa07590f8e none            swap    sw,pri=0        0       0
/swap                                     none            swap    sw,pri=1        0       0

By setting a lower priority to the partition (identified by a UUID), systemd will be able to resume properly. Removing the swapfile would cause an error during the suspend phase (swap areas too small) and removing the partition or not setting the priorities as shown would cause it to fail on resume (initrd unable to find the correct resume swap volume).

I'm not sure what drives the resume image size, but the kernel normally attempts to use no more than 2/5 of the total RAM. The documentation is a bit vague on this; it does say the resume image must fit in the resume swap volume but not so much about what it includes and whenever other partitions can be leveraged outside of the image itself. That said keep in mind that

  1. Your swapfile will be able to free ram and primary partition swap space, so it will help
  2. Kernel uses compression; the resulting image is much smaller
  3. I suspect the minimal resume image is mostly kernel memory, and applications can be swapped out to the other swap partitions - as if you ran a memory-hungry program and killed it before suspending.

The latest systemd code definitively has support for setting up resume on a swapfile; I'm unsure how long ago it was added though, nor if I'm using it or merely fitting the resume image in the small partition, but it does work with this setup.

There is a lot of useful documentation in the kernel's documentation under the power directory. You may also have more luck using uswsusp, and if you still need to have suspend initiated by systemd you can override systemd-hibernate.service to call s2disk too.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.