You are here

Hibernation

Some distributions, for one reason another, are not capable of hibernating (suspending to disk) out-of-the box. In many cases some underlying functionality has to be enabled or properly configured. This article gives an overview of hibernation and the underlying functionality that is necessary to enable hibernation.

Introduction

A computer can be in any one of eight power states, where two of these are susepend to RAM or sleep, and suspend to disk or hibernate. In recent computers the process of changing the system state to one of these states is managed by the Advanced Configuration and Power Interface (ACPI), which connects the operating system to the hardware, and is a replacement for Advanced Power Management (APM) and other methods of managing power states. Hibernation is the process that puts the system into one of these power states, specifically the power state where the state of the computer is saved to disk and all components of the system are powered off. When the computer is powered on after hibernating, the state of the computer is restored from the disk. The sleep state is similar except that the state of the system is saved to RAM instead of disk and all components are powered off except the RAM.

As far as I can tell, users can interface with the ACPI through three low level and two high level interfaces, which then use a specific utility to perform the actual writing of the state to disk. The first low level interface is a feature built into the kernel and involves interacting with the file /sys/power/state. This interface uses swsusp to write the system state to the swap partition. The other low level interfaces are uswsusp, a tool that replicates the function of the kernel built in interface and provides s2disk to write the state to disk, and tuxonice, which requires a custom kernel. The high level interfaces, providing a better experience for the user, are systemd and pm-utils, which interact with the low level interfaces. I made the following table of methods of manually initiating hibernation and the chain of tools each method uses to try to understand the relationships, which might be helpful to you, but for more information see this Ubuntu help page, this Arch wiki page, this page on kernel.org, and the page from the tuxonice developer.

high level interface low level interface disk writing method command
not used kernel built in method swsusp write to/sys/power/state
not used uswsusp s2disk s2disk, but preferable to integratepm-utilswithuswsuspto usepm-utilscommands
not used tuxonice requires custom kernel
systemd kernel built in method or something native to systemd? swsusp? see next table
pm-utils kernel built in method swsusp see next table
pm-utils uswsusp s2disk see next table

Each of these high level interfaces provide commands for changing the power state of the system as listed below, although using these is not necessary to change power states in an environment that provides a graphical interface to these commands, and monitors the power level and device actions such as closing a laptop lid and can trigger the appropriate command in the background.

change state to systemd pm-utils
hiberbnate
systemctl hibernate
pm-hibernate
suspend
systemctl hibernate
pm-suspend
hybrid suspend
systemctl hybrid-sleep
pm-hybrid

Besides these interfaces being available on the system, there are other details that need to be considered for proper operation of these interfaces. One of these considerations, which is a common source of hibernation not working as expected, is that the device to which the state is saved must be available and specified, for both parts of the hibernation process -- for saving the state and for restoring the state. Another consideration, also a common source of hibernation problems, is that the initial ram file system does not include the necessary components to restore the state of the system or the components are specified for inclusion into the inital ram file system in such a way that the restoration process does not work.

Most distributions implement the components necessary for hibernation well, especially with the suspend to RAM, however in certain cases small details of implementation or configuration prevent hibernate from working as it should. This article provides some of the necessary modifications to make hibernate work.

Specifying Device for Saving State

In order to save the state of the system to disk, space on the disk must be available and specified. The typical location for saving the system state to disk is the swap partition. The swap partition should be as large as the the amount of RAM on the system to ensure the entire state of the system is saved. The swap partition should be specified in the /etc/fstab file so it is available to save the system state when hibernation is initiated. There is another mechanisms -- maybe some component of systemd configured during installation that mounts an available swap partition for normal use in a session, as I have seen in Manjaro -- but this method of mounting swap apparently does not make an entry in /etc/fstab and does not allow for its use for hibernation. The fstab file I use in Manjaro is shown in the following code block, which shows the swap partition specified by its UUID, preferable to specifying it by device name.


# /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).
#
#
# Root File System : Manjaro-Root 
UUID=bb9fe5f1-93c5-4b1c-91f2-e841466b7182 / ext4 rw,relatime,data=ordered 0 1 
# EFI System Partition 
UUID=2005-1DB9 /boot/efi vfat defaults 0 0 
# Home File System: Manjaro-Home 
UUID=f1925c37-abd4-4ee6-945e-5eb8bcf25365 /home ext4 defaults 0 0 
# SWAP Partition 
UUID=69bb9b40-aedd-4278-ac57-0113a7dc816f swap swap defaults 0 0 
# Windows Virtual Machine Partition 
UUID=12189972-1a52-43bb-b2e1-c4518ee0e92a /mnt/Windows10TP ext4 defaults,noauto,x-systemd.automount 0 0 
# Common EXT4 Data Partition 
UUID=41b1494b-f354-4558-913d-f6097b93dc0e /mnt/CommonDataEXT4 ext4 rw,suid,dev,exec,auto,relatime,async 0 0 
# NTFS Common Data Partition 
UUID=347C2590613EB6CF /mnt/CommonDataNTFS ntfs rw,suid,dev,exec,auto,relatime,async 0 0

Specifying Device for Restoring State

The resume device (the swap partition) is specified in the editable, perisistant -- through GRUB updates -- GRUB configuration file, /etc/default/grub, as opposed to the non-editable, non-persistant one used by the GRUB configuration program, /boot/grub/grub.cfg or /boot/grub2/grub.cfg. The specification in my Manjaro installation, which required me to manually add the swap partition to fstab and to the GRUB configuration file, is:

GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/69bb9b40-aedd-4278-ac57-0113a7dc816f splash=silent quiet showopts video.use_native_backlight=1"

The one in my openSUSE installation, which dealt with all hibernation considerations correctly and automatically, is:

GRUB_CMDLINE_LINUX_DEFAULT=" BOOT_IMAGE=/boot/x86_64/loader/linux ramdisk_size=512000 ramdisk_blocksize=4096 resume=/dev/disk/by-uuid/69bb9b40-aedd-4278-ac57-0113a7dc816f splash=silent quiet showopts acpi_backlight=vendor acpi_osi=Linux"

Note that the backlight options at the end of these lines did not make a difference to the backlight control, they are only there because I never bothered to remove them. See this for backlight control on laptops with Intel integrated video.

Necessary Components of Initial RAM FS

Distributions that Use mkinitcpio to generate the initramfs

In Arch and the Arch based Manjaro -- distributions that don't use dracut to create an initramfs, the initramfs is created by a tool called mkinitcpio. (For an explanation of the initramfs, see this openSUSE reference, for information on dracut, see this Fedora wiki page.) It can be used to include hooks in the initramfs for necessary components such as resume from hibernation capability. In both of these installations it was necessary to rebuild the initramfs using this tool to include the resume hook. In Arch:

mkinitcpio -p linux

and in Manjaro:

mkinitcpio -p linux316

as root or with sudo, where the "316" represents the abbreviated kernel version, in this case 3.16.7.4-1, -- required in Manjaro because it supports multiple installed kernels. This command is run in both of these distributions after including theresumehook in the file/etc/mkinitcpio.conf. The section of the files including the hooks specification are in the following two code blocks.

The line specifying hooks in my Arch installation is:

HOOKS="base udev resume autodetect modconf block filesystems keyboard fsck"

The same line in my Manjaro installation is:

HOOKS="base udev resume plymouth autodetect modconf block keyboard keymap filesystems fsck"

The order of the hooks listed on this line is important. For example, any subcomponent of the items listed after autodetect is only selectively loaded. And any subcomponent of the items listed before udev that is required to be made available during startup by udev will not be available during startup as it should. For this reason, the resume hook will have to be listed after udev, as recommended on the Arch wiki; and I assume it might also be a good idea to put it and plymouth before autodetect.

Distributions that use dracut to generate the initramfs

Most other distributions use dracut to create the initramfs, so the method described above to add a resume capability to the initramfs does not apply. Instead of mkinitcpio, the dracut tool, a much more complicated, but more powerful tool is used to generate the initramfs. Analogous to the presets used by mkinitcpio, dracut has its own "preset" created by the distribution at /usr/lib/dracut/dracut.conf.d/01-dist.conf. End user configuration is done at either /etc/dracut.conf or in *.conf files in /etc/dracut.conf.d/.

It seems that if the kernel command line specifies a resume device, the resume module is automatically added to the initramfs by dracut. None of my the distributions I have used that use dracut have never failed to include the module, if the other necessary functionalities have been enabled (see this). But if it is necessary to add the module, the dracut documentation states that the module can be specified in /etc/dracut.conf, in a file in /etc/dracut.conf.d, or using the command line using the --add option (see the USAGE section of Chapter 6 of the documentation).

Desktop Environment Interaction with Hibernation Mechanism

One of KDE's many, many strengths (although I appreciate other DEs and use them sometimes, I have a bias for KDE) is that it includes all the tools to interact with the suspend to disk as well as the suspend to ram mechanisms by default, whether it is from the session control menu or the power management settings. Other desktop environments may have the capabilities but they may not be enabled by default. For example, Xfce has hibernation control in the session menu and in power management, but is disabled by its Ubuntu base in Xubuntu. Unity is also capable of hibernation control -- using the pm-utils backend instead of systemd -- but the desktop environment elements are disabled by default. Certain fixes must be implemented in Ubuntu's Unity and the Xfce desktop in Ubuntu based distributions, as described in the following section. GNOME, which I use in openSUSE -- a distribution that uses systemd by default, requires an extension to provide a hibernate button in the user menu. There is no way to trigger hibernation through, the desktop environment power management, even by using an extension.

Enabling Hibernation in Ubuntu and Ubuntu Based Systems

Enabling Hibernation in Ubuntu Unity

Even if the requirements of

  • having the interface to the suspend capabilities which in the case of systems that don't use systemd is limited to pm-hibernate from the pm-utils
  • having a swap partition that is as large as the amount of RAM
  • specifying the swap partition in /etc/fstab
  • specifying the resume device in /etc/default/grub

are met, in Ubuntu based systems, a fix specific to these distributions must be made to enable hibernation.

The steps required are as follows:

  1. Create the file
    /etc/polkit-1/localauthority/50-local.d/com.ubuntu.enable-hibernate.pkla
  2. Add the following lines to the file and save.
    
    [Re-enable hibernate by default in upower]
    Identity=unix-user:*
    Action=org.freedesktop.upower.hibernate
    ResultActive=yes
    
    [Re-enable hibernate by default in logind]
    Identity=unix-user:*
    Action=org.freedesktop.login1.hibernate;org.freedesktop.login1.hibernate-multiple-sessions
    ResultActive=yes

Enabling Hibernation in Xubuntu/Voyager (Xfce Desktop)

Because Xubuntu is based on Ubuntu, which disables hibernation, and Xubuntu doesn't reverse this, the above fix presented for Unity must be made for Xubuntu.

GNOME Extension for Hibernating

The GNOME shell doesn't have any desktop environment component where hibernation can be controlled. Hibernation control can be added to the user/session menu on the panel using a shell extension. The extension I have used with GNOME on openSUSE is Hibernate Status Button, although it uses uswsusp's s2disk instead of swsusp to write to disk, which would be my preference.

Conclusion

Besides backlight control issues, the lack of hibernation capability is the single significant issue that might need attention when installing a distribution. I hope this has provided some useful and practical information on resolving hinernation issues.