Configure and Verify Linux Hibernation Resume with systemd

You will finish with a clear way to check whether this system is configured to resume from a Linux hibernation image, understand which kernel parameters control it, and disable a broken resume attempt without guessing at service options. The examples match systemd 255, as installed on the reference machine.

Allow about 20 minutes for inspection. You need shell access and, for bootloader or initramfs changes, an administrator account. This guide does not create a swap area or edit bootloader files for you. Those changes are host-specific and can make the next boot fail if the device or offset is wrong.

1. Check the installed systemd version

Start with a read-only version check. It does not need elevated privileges:

$ systemd --version
systemd 255 (255.4-1ubuntu8.17)

Your package revision can differ. The relevant contract here is systemd 255: systemd-hibernate-resume.service is a oneshot service, and the companion generator understands resume=, resume_offset=, resumeflags= and noresume.

Do not expect useful command-line help from /usr/lib/systemd/systemd-hibernate-resume. The installed manual documents the service and its fixed executable path, not a general-purpose set of user-facing flags. Let the initrd service and generator supply its inputs.

2. Read the inputs used for this boot

Read the kernel command line and look specifically for the resume parameters:

$ tr ' ' '\n' < /proc/cmdline | grep -E '^(resume|resume_offset|resumeflags|noresume)(=|$)' || true
resume=/dev/disk/by-uuid/REPLACE_WITH_SWAP_UUID
resume_offset=REPLACE_WITH_PAGE_OFFSET

No matching line means this boot was not given those parameters. That does not by itself prove that hibernation cannot work: the generator can also use the EFI variable HibernateLocation, according to its manual. Treat the command-line output as evidence about this boot, not as a complete inventory of firmware state.

The resume= value identifies the device containing the hibernation image. Persistent paths, such as a path under /dev/disk, are safer for boot configuration than a device name that can change when disks are discovered in a different order. A value in fstab-style form, such as UUID=..., is also supported by the generator.

resume_offset= is the swap-space page offset on that device. The generator defaults it to 0 when it is absent. Do not copy an offset from another machine or calculate one from the swap size. Obtain it from the method used to create your swap setup and verify that the swap layout has not changed.

3. Confirm the service is an initrd operation

Inspect the installed unit as an ordinary user:

$ systemctl cat systemd-hibernate-resume.service
[Unit]
Description=Resume from hibernation
ConditionKernelCommandLine=!noresume
AssertPathExists=/etc/initrd-release

[Service]
Type=oneshot
ExecStart=/usr/lib/systemd/systemd-hibernate-resume

The exact output includes dependency lines and comments. The important checks are ConditionKernelCommandLine=!noresume and AssertPathExists=/etc/initrd-release. The first skips the service when noresume is present. The second means this unit is intended for the initrd, not for an ordinary late-boot service restart.

Check whether the current environment is the initrd:

$ test -e /etc/initrd-release && echo 'initrd environment' || echo 'normal root filesystem'
normal root filesystem

On a normally running system, seeing the second line is expected. Do not run the executable manually from the normal root filesystem as a test. It writes the selected device and offset to the kernel resume interfaces, so a manual invocation is an administrative, boot-affecting action rather than a harmless status query.

4. Inspect the kernel resume interfaces

The service implements resume by writing the device major and minor to /sys/power/resume, and the page offset to /sys/power/resume_offset when the kernel supports it. Read those files without sudo first:

$ for f in /sys/power/resume /sys/power/resume_offset /sys/power/state; do
    printf '%s: ' "$f"
    if test -r "$f"; then sed -n '1p' "$f"; else echo unavailable; fi
  done
/sys/power/resume: 9:0
/sys/power/resume_offset: 0
/sys/power/state: freeze mem disk

The values are kernel state, not a confirmation that a valid hibernation image exists. The resume value uses major:minor notation, and resume_offset is expressed in memory pages. The available states show that this kernel exposes disk, but they do not prove that the swap device is large enough or that its image is usable.

For a non-destructive device check, resolve the configured path and compare it with the swap inventory:

$ readlink -f /dev/disk/by-uuid/REPLACE_WITH_SWAP_UUID
/dev/nvme0n1p3
$ swapon --show
NAME           TYPE      SIZE USED PRIO
/dev/nvme0n1p3 partition  16G   0B   -2

Replace the placeholder with the real identifier. The resolved device should be the intended swap backing store. If it is missing from swapon --show, stop and inspect the swap configuration before changing resume parameters. Do not use mkswap, swapoff or a formatting command as a quick fix: those can destroy the hibernation image and, depending on the target, existing swap data.

5. Configure resume through the boot path

When the device and offset are confirmed, add the corresponding kernel parameters through the bootloader or distribution-specific kernel command-line configuration. A typical parameter set is:

resume=/dev/disk/by-uuid/REPLACE_WITH_SWAP_UUID resume_offset=REPLACE_WITH_PAGE_OFFSET

Use the distribution's documented boot configuration workflow, then rebuild the initramfs if that workflow requires it. The generator reads resume= from the kernel command line and creates the resume service configuration during early boot. A change that only affects the running root filesystem will not retroactively change the initrd that has already booted.

Reboot only during a suitable maintenance window. Before doing so, keep a recovery path available, such as a working boot entry that omits the new parameters. After the next boot, repeat step 2 and confirm that the exact values are present in /proc/cmdline.

Resume failure is not necessarily a service failure. The manual says that failing to find or initiate a resume image ordinarily allows boot to continue, for example when the machine was powered off rather than hibernated. Check the rest of the boot if the machine reaches the normal root filesystem:

$ journalctl -b -u systemd-hibernate-resume.service --no-pager
-- No entries --

Journal availability and the exact messages depend on whether the initrd journal was forwarded or persisted. No entry in the normal system journal does not prove that the initrd service did not run.

6. Recover from a bad resume attempt

Use the bootloader's one-time edit facility to remove resume= and resume_offset=, or add noresume, for the affected boot. The unit explicitly ignores resume= when noresume is present. Once the system is up, correct or remove the persistent kernel parameters using the same configuration method used in step 5.

The undo is complete when the next boot's command line contains noresume, or contains neither the stale resume= nor its offset. Confirm it before attempting any swap repair:

$ tr ' ' '\n' < /proc/cmdline | grep -E '^(resume|resume_offset|noresume)(=|$)' || echo 'no resume parameters on this boot'
noresume

Do not delete or recreate the swap area merely to make the warning disappear. A hibernation image is disposable, but a mistaken storage command can destroy data unrelated to hibernation.