SDB:Suspend to disk

Jump to: navigation, search
This article or section refers to the version '11.3' and it is now obsolete!
Please refer to this article's discussion page for more information.
This article covers s2disk, the userspace suspend system

Tested on openSUSE

Recommended articles


There are two methods for doing suspend to disk:

  • the "old" kernelspace method, basically echoing "disk" into /sys/power/state
  • the "new" userspace method, handled by the commands s2disk and resume which are part of the "suspend" package.

This article focuses on the userspace method.

Technical information

The s2disk program does the following in order to suspend the machine:

  • tell the kernel to create a snapshot of the current system state
  • read the snapshot data from the kernel and write it to disk
  • power off the machine

The resume program does basically the same, in reverse order:

  • after a basic system boot, before (!) mounting any partitions, resume runs from the initrd
  • it reads the snapshot data from the disk and writes it to the kernel
  • it tells the kernel to restore the snapshot
  • the kernel returns at the place it was before suspend

Some things in the above workflow are simplified ("create a snapshot" involves quite some magic, and "read from / write to disk" actually can involve transformations such as compression and encryption.

Using s2disk

In openSUSE releases, it is advised to never call s2disk directly, except for debugging purposes, unless you know exactly what you are doing. As a normal user, you just click on "suspend to disk" or "hibernate" in kpowersave or gnome-power-manager, or you use the powersave command line tool. The suspend low level stuff is handled by SDB:Pm-utils and if you need to debug stuff, you can call pm-hibernate as root from a shell to invoke s2disk. This will check some prerequisites and create a config file in /var/lib/s2disk.conf, then invoke s2disk with this config file. If pm-hibernate does not suspend your machine but seems to do nothing at all, have a look at /var/log/pm-suspend.log and check for messages indicating problems during preparation of suspend (no swap partition found?) or error messages from s2disk.


Pm-utils' pm-hibernate creates /var/lib/s2disk.conf from autodetected stuff (e.g. the resume device and the image size) and then adds the parameters that are configured in /etc/suspend.conf, so you can always override the autodetection. Beware: changing stuff in suspend.conf might make your suspend fail, so be careful. The suspend.conf file is commented, so reading the comments might already give you a good idea on how to use it.

Splash screen

The splash screen during suspend and resume looks nice. It is, however, hard to debug failures if you do not see what is going on. Add

splash = n

to /etc/suspend.conf to disable the splash screen during suspend. During resume, the splash usage follows the global system settings, so either set "splash=verbose" in the grub config, or press Escape during early boot to disable the splash screen on resume.


Since on most halfway recent CPUs compression of the image is always a gain, at least resulting in faster load times, compression is on by default. If you want to disable compression for testing or suspect problems, then add

compress = n

to /etc/suspend.conf.


The encryption feature allows to encrypt the data written to the swap partition, so that nobody can resume the machine without entering the passphrase. To setup encryption, you first need to create the public key:

root@stoetzler:~# suspend-keygen
libgcrypt version: 1.4.0
Key bits (between 1024 and 4096 inclusive) [1024]:
Generating 1024-bit RSA keys.  Please wait.
Testing the private key.  Please wait.
Passphrase please (must be non-empty):
Confirm passphrase:
File name [suspend.key]:
root@stoetzler:~# cp suspend.key /etc/suspend.key

Do not forget the passphrase ;), then add the following to /etc/suspend.conf:

encrypt = y

Attention: right now (2008-06), no keymap is loaded in the initrd, so during resume you will have a US keyboard. Make sure that you know how to type your passphrase on a US keyboard!

Shutdown method

After the image is written to disk, there are two methods to shut down the machine:

  • going through the ACPI BIOS (called "platform mode")
  • plain shutdown (as in a system shutdown)

Usually the recommended mode is to go through the ACPI BIOS (on some machines this is necessary, otherwise various parts of the system might malfunction after resume, e.g. thermal management). There are machines, which have problems with that and e.g. wake up immediately after shutting down this way. The mode can be selected with

shutdown method = shutdown

There are three methods to choose from: "platform", "shutdown" and "reboot", which is only useful for debugging: the machine reboots and resumes immediately.

Boot another OS after hibernate (workaround)

By default on resume you don't see any choice from GRUB menu and starting directly to restore suspended system. It's done, probably, to protect your data from possible human mistake (your system memory is saved on the swap partition, and if this partition will be reused before resume - you'll simply loose all your data). Another very important point: hibernate process is not taking care about any mounted partitions! All mounted partitions will remain mounted! So, if you'll reuse+modify one of them within another OS - you may probably completely destroy its data...

However, if like me, you need once per year/month/week to load Windoze - it become painful to do a complete shutdown of Suse and restart again all applications 20 minutes later...

So, here is a workaround to get back your GRUB menu during the power on.

The hibernate procedure just before suspend will update your GRUB setting in way when you power-on your desktop you go directly to resume and not leave you any other choice...

The workaround: just to disable this last step (leave GRUB as it). (Instead of editing the file '99Zgrub' as described in the following you could simply remove (or better backup and then remove) this file.)

All you need is to open as 'root' user the


file, go to the end of the file, and put comments before 'prepare-grub' and 'grub-once-restore'.

In openSUSE, you will see

###### main()

if [ "$1" = hibernate ] || [ "$1" = suspend -a "$2" = suspend_hybrid ]; then
if [ "$1" = thaw ] || [ "$1" = resume -a "$2" = suspend_hybrid ]; then

Just comment out 'prepare-grub' and 'grub-once-restore' for example:

###### main()

case $1 in
###                prepare-grub
###                grub-once-restore

Umount all 'external' partitions first!
Then suspend to disk and enjoy! :-)


If you want to see some statistics after resume (for comparing the read/write speed of various option combinations e.g.), you can instruct resume to wait a few seconds after loading the image and before restoring the snapshot. Add the the following to /etc/suspend.conf:

resume pause = 10

to wait 10 seconds. You should disable the splash screen during resume (in the grub config), or you won't be able to see the numbers. The wait can be aborted by pressing "Enter".

Problems on some filesystems

Resume is very slow if grub resides on a reiserfs partition, see Bug #538795. It appears that grub has to replay the journal in memory before loading the kernel and initrd, and this takes some time. The obvious workaround is to create a separate /boot partition, format it as ext2, and move grub to it (plus the rest of /boot/*, of course)

It is possible that this issue has some effect on other journalled filesystems, perhaps ext3 or xfs. Someone could try that and report ;-)

Problems on older ThinkPad notebooks

Some older ThinkPad notebooks are reported to freeze during resume. According to the Bug #450256, this affects at least some models like X31 or T41 and relates to a feature called ACPI hardware signature, which was added to recent kernels. From the discussion it seems that the problem is caused by a bug in BIOS. There are two ways how to overcome this issue:

Problems in Virtual Machines

Suspend to disk is configured to use disk's by path-id instead of UUID. This can cause systems to be unbootable if you change their root disk driver type (virtual machines) or other hardware changes (addition/change of a pci-e controller). This is because the swap partition is defined by it's driver path not it's UUID.

This will be noted as the system will hang indefinitely during boot with a message related to searching for the disk device.

To work around this you can boot the system by editing the grub menu entry during boot with:


To permanently resolve this, you need to edit /etc/default/grub

hint: on transactional server or kubic you need to first run
# transactional-update shell

# vim /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0,115200 resume=/dev/disk/by-path/pci-0000:00:07.0-part3 splash=silent quiet showopts"

You can remove the "resume=..." or alter it with the correct location to the system swap partition (using /dev/disk/by-uuid is recommended).

After editing, you must run:

# grub2-mkconfig

hint:  if you are on transactional server, after running this now you need to reboot.


Right now, the pm-utils setup and our initrd code does not allow to suspend to / resume from a swap file, only a swap partition. This needs to be implemented and then documented.

See also

External links