Configure Linux Hibernation Resume with systemd's Generator

You will configure the boot-time information systemd needs to resume a Linux hibernation image, then check whether the generator acted on this machine. The practical result is a kernel command line containing the correct swap device and, when required, its page offset. Allow about fifteen minutes for inspection, plus a reboot window if you change the boot configuration.

The examples use systemd 255.4-1ubuntu8.17, installed here as part of package systemd. This guide reads the current configuration and uses a temporary generator directory. Changing a boot loader entry is a privileged, service-disrupting operation: a bad value can make the next boot skip resume or fail to find the hibernation image. Keep a working recovery path before editing it.

1. Confirm what the generator does

systemd-hibernate-resume-generator is not a command you normally run by hand. It is a systemd generator that runs during boot and creates systemd-hibernate-resume.service when the boot parameters identify a resume device. The service writes the device number, and the page offset when supported, to the kernel's hibernation interfaces. If there is no hibernation image, continuing the boot is normally not an error.

Check the installed version and the generator path with ordinary, read-only commands:

$ systemd --version
systemd 255 (255.4-1ubuntu8.17)
$ command -v systemd-hibernate-resume-generator || true
$ ls -l /usr/lib/systemd/system-generators/systemd-hibernate-resume-generator

The generator is commonly found under /usr/lib/systemd/system-generators/; this machine also provides the equivalent path under /lib. The generator's three-argument interface is for systemd's generator manager, not a replacement for setting the kernel command line.

2. Inspect the current boot parameters

Read the parameters that actually selected this boot:

$ tr ' ' '\n' < /proc/cmdline | grep -E '^(resume|resume_offset|resumeflags|noresume)(=|$)' || true

No output means that none of these four parameters is present on the running boot. On this host, the command prints no matching line, so the generator has no explicit resume= value to use.

Checkpoint: inspect the complete command line if the filtered command surprises you:

$ cat /proc/cmdline

The generator understands resume=, resume_offset=, resumeflags= and noresume. It can also use the EFI variable HibernateLocation when suitable, so an absent resume= does not prove that every possible resume source is absent.

3. Choose the resume device identifier

resume= names the device containing the hibernation image. Use a persistent path or an fstab-style identifier such as UUID=..., rather than a device name whose numbering might change:

$ lsblk -o NAME,TYPE,FSTYPE,UUID,SIZE,MOUNTPOINTS
$ findmnt --verify

Identify the swap device you deliberately use for hibernation. Do not copy a UUID from an unrelated data partition, and do not assume that any active swap area is large enough or configured for hibernation. If you need to change swap layout, stop here and make a tested backup and recovery plan first.

A representative kernel parameter looks like this:

resume=UUID=SWAP-UUID-FROM-LSBLK

This is an example with an obvious placeholder, not a value to paste unchanged.

4. Add an offset only when your swap setup needs one

resume_offset= is the page offset of the swap space on the resume device. It defaults to 0 and was added in systemd 254. A plain swap partition commonly needs no separate offset. A swap file can require one, depending on how it is placed on the underlying filesystem.

Do not guess this number, convert a byte offset casually, or reuse a value from another installation. Obtain the page offset using the documentation for your distribution and filesystem, then add it alongside resume=:

resume=UUID=SWAP-UUID-FROM-LSBLK resume_offset=PAGE_OFFSET_FROM_YOUR_SWAP_SETUP

If the offset is malformed or belongs to a different swap arrangement, resume will not work reliably. The installed generator logs parsing failures during boot, but it cannot infer a corrected value.

5. Decide whether to suppress resume

Add noresume when a particular boot must not attempt hibernation resume. This is useful while recovering a stale or incompatible image. When noresume is present, the generator ignores resume=:

noresume

This is a boot-time decision, not a permanent deletion of the hibernation image. Remove the parameter from the boot entry when you want normal resume behaviour again. Do not use noresume as a substitute for fixing a wrong device or offset.

6. Change the boot entry carefully

Use your boot loader's supported configuration method to add the verified parameters to the kernel command line. This step normally requires elevated privileges and may regenerate boot files. The exact file and command vary by distribution, so do not edit a generated entry unless your boot loader documentation says to do so.

Before applying a change, save the current entry and ensure you can select an older entry or edit the command line once from the boot menu. After the change, reboot only when you have a recovery route. If the new boot skips resume, remove the added parameters or select the saved entry, then correct the device or offset before trying again.

After rebooting, verify the effective command line rather than trusting the file you edited:

$ tr ' ' '\n' < /proc/cmdline | grep -E '^(resume|resume_offset|resumeflags|noresume)(=|$)' || true

resumeflags= supplies resume-device mount options and defaults to rootflags= when it is not specified. Leave it alone unless your setup has a documented reason to provide those options. It is not a replacement for resume=.

7. Check generation without changing the running boot

You can exercise the installed generator against the current command line and an empty temporary destination. This is an ordinary read-only test of the current inputs:

$ generator_dir=$(mktemp -d /tmp/systemd-resume-generator.XXXXXX)
$ /usr/lib/systemd/system-generators/systemd-hibernate-resume-generator \
    "$generator_dir" "$generator_dir" "$generator_dir"
$ find "$generator_dir" -maxdepth 2 -printf '%P\n'
$ rmdir "$generator_dir"

On this machine, with no matching resume parameter and no usable EFI location, the generator exits successfully and prints no generated file. That means it had nothing to schedule, not that hibernation is configured. When a valid resume input is present, expect generated content referencing systemd-hibernate-resume.service in systemd's generator output directory during a real boot.

For boot-time diagnostics, inspect the current boot's journal:

$ journalctl -b -u systemd-hibernate-resume.service --no-pager
$ journalctl -b | grep -F systemd-hibernate-resume-generator

An empty service journal can simply mean that no resume image existed. Parsing errors, a missing device, or a system identifier mismatch are different problems and should be corrected before repeating a hibernation test.