Resume from hibernate fails sometimes with systemd resume/hibernate

Erwin Iosef · 2025-12-06 05:56:13

I've been noticing this since the mkinitcpio move to systemd although it was a while after the issues began, this never happened with the busybox style initrd mode, I hibernate my system infrequently, here's a partial output of the log: https://paste.rs/T5byY , please let me know if you need more info and thank you so much for your help

seth · 2025-12-06 09:35:08

Dec 06 10:21:27 archlinux kernel: PM: Using 3 thread(s) for lzo decompression
Dec 06 10:21:27 archlinux kernel: PM: Loading and decompressing image data (640278 pages)...
Dec 06 10:21:27 archlinux kernel: Hibernate inconsistent memory map detected!
Dec 06 10:21:27 archlinux kernel: PM: hibernation: Image mismatch: architecture specific data

The part where you're entering hibernation might be important as well…

Generically, there've been reports w/ hibernation
* issues that might or not be zswap related (so disable that)
* try a different compression algorithm
* and if there's a parallel windows installation see the 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

Erwin Iosef · 2025-12-06 12:44:24

Oh right, here's another another partial output but pre hibernate: https://paste.rs/uRUzK
If you look at line 71 you can spot some ACPI errors.
EDIT: reposted link.

Last edited by Erwin Iosef (2025-12-06 12:47:42)

seth · 2025-12-06 15:14:57

Dec 04 21:53:02 Kelly-PC systemd[1]: Finished System Hibernate.
Dec 04 21:53:02 Kelly-PC kernel: PM: hibernation: Basic memory bitmaps freed
Dec 04 21:53:02 Kelly-PC systemd[1]: systemd-hibernate.service: Consumed 2.237s CPU time, 2M memory peak.
Dec 04 21:53:02 Kelly-PC kernel: OOM killer enabled.
Dec 04 21:53:02 Kelly-PC kernel: Restarting tasks: Starting
Dec 04 21:53:02 Kelly-PC kernel: Restarting tasks: Done
Dec 04 21:53:02 Kelly-PC kernel: PM: hibernation: hibernation exit
Dec 04 21:53:02 Kelly-PC systemd[1]: Reached target System Hibernation.
Dec 04 21:53:02 Kelly-PC systemd[1]: Stopped target Sleep.
Dec 04 21:53:02 Kelly-PC systemd-logind[435]: Operation 'hibernate' finished.
Dec 04 21:53:02 Kelly-PC systemd[1]: Stopped target System Hibernation.

This (older) one looks like it succeeded, though?

Erwin Iosef · 2025-12-07 04:38:56

Oh I got the dates messed up! Sorry

Here's the log that underwent seemingly successfully hibernation and is directly before the first log above: https://paste.rs/aJq9X
There's not much there sadly.

Yeah it succeeds at hibernation but it's the resume that fails sometimes at random.

Is it somehow related to how systemd handles ACPI? That's one of the things I came upon while browsing the forums.

Erwin Iosef · 2025-12-07 05:09:16

I disabled hibernate again(via in cmd "powercfg -h off") in Windows despite being sure I've done it already before this issue and there being no C:\hiberfile.sys.

I did find HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power\HibernateEnabledDefault set to 1 though.

Just tested with 5 hibernates or so and it seems to work for now.

But now I wonder: if windows hibernate was the issue all along why did the busybox hibernate work all this time until the switch to systemd?

Last edited by Erwin Iosef (2025-12-07 05:11:24)

Erwin Iosef · 2025-12-07 09:35:30

UPDATE: It happened again.
I should perhaps note that I have the resume hook added despite using systemd as initrd but it doesn't look like a problem since it resumes normally anyway(except when it doesn't that is).

HOOKS=(base systemd autodetect microcode modconf kms keyboard keymap sd-vconsole block filesystems resume fsck)

Last edited by Erwin Iosef (2025-12-07 09:48:23)

seth · 2025-12-07 16:48:33

https://wiki.archlinux.org/title/Mkinit … mmon_hooks
Remove resume and keymap hooks if you want to use systemd - you can btw. also just continue to use busybox if you want.

Erwin Iosef · 2025-12-07 18:00:25

Done! I kept those hooks there for easy convenience if ever I needed to switch back to busybox and nothing really reported a problem.

Erwin Iosef · 2025-12-18 06:07:43

So, update!
The hibernation/resume worked for a long time as you can guess obviously, I thought the issue was resolved finally but the failure happened again yesterday. After reading the logs and some hibernation and resuming tests, I got to two findings:

The resume failure seemed to happen very likely whenever I hibernate with my usb drive plugged and resume with it unplugged or vice versa. The port/the drive itself has got something of a loose contact I think so it could unplug itself rarely from time to time.

The journal reports this on resume from hibernate failure:

archlinux kernel: random: crng reseeded after system resumption

Is this supposed to signify a problem that happened somewhere in boot events?

seth · 2025-12-18 08:15:23

likely whenever I hibernate with my usb drive plugged and resume with it unplugged or vice versa

Generally don't.
Here's the story of a bear: https://bbs.archlinux.org/viewtopic.php … 4#p1960554
Though unless you're referencing the resume location w/ a device node (sda4 or so) I'd expect this to be a bit more resilient wrt usb drives… it's not a dock, is it?

If it wasn't for the "vv" I'd suggest to umount the drive when entering hibernation (maybe the problem is rather a file on the drive being in use)

Erwin Iosef · 2025-12-21 11:41:53

Oh okay.
Yeah I understand.
No I don't have a resume= parameter (if we're thinking of the same thing), maybe I should so it's more resilient to the crng thing.
Dock? It's a desktop PC.

Erwin Iosef · 2026-01-07 15:24:56

So far, no issues with resume since I removed the USB stick, will keep post open till the end of the month.

For readers, I can only summarise thus far:

When using systemd-hibernate, as it saves a complete machine state of your system, make sure it stays that way when resuming, you don't want the system to wake up with surprises even if it's only due to one faulty non-critical device. Check for any loose connections of devices.

You can also use mkinitcpio's busybox-initramfs as a last resort.

Last edited by Erwin Iosef (2026-01-07 15:27:28)

Erwin Iosef · 2026-01-07 15:30:55

Judging by the logs I presented thus far, I believe it's due to the random number generated thing for each hibernation changing due to the loose connectivity of the drive during hibernation-resumption, but people are free to provide correct explanations

Arch Linux

#1 2025-12-06 05:56:13

Resume from hibernate fails sometimes with systemd resume/hibernate

#2 2025-12-06 09:35:08

Re: Resume from hibernate fails sometimes with systemd resume/hibernate

#3 2025-12-06 12:44:24

Re: Resume from hibernate fails sometimes with systemd resume/hibernate

#4 2025-12-06 15:14:57

Re: Resume from hibernate fails sometimes with systemd resume/hibernate

#5 2025-12-07 04:38:56

Re: Resume from hibernate fails sometimes with systemd resume/hibernate

#6 2025-12-07 05:09:16

Re: Resume from hibernate fails sometimes with systemd resume/hibernate

#7 2025-12-07 09:35:30

Re: Resume from hibernate fails sometimes with systemd resume/hibernate

#8 2025-12-07 16:48:33

Re: Resume from hibernate fails sometimes with systemd resume/hibernate

#9 2025-12-07 18:00:25

Re: Resume from hibernate fails sometimes with systemd resume/hibernate

#10 2025-12-18 06:07:43

Re: Resume from hibernate fails sometimes with systemd resume/hibernate

#11 2025-12-18 08:15:23

Re: Resume from hibernate fails sometimes with systemd resume/hibernate

#12 2025-12-21 11:41:53

Re: Resume from hibernate fails sometimes with systemd resume/hibernate

#13 2026-01-07 15:24:56

Re: Resume from hibernate fails sometimes with systemd resume/hibernate

#14 2026-01-07 15:30:55

Re: Resume from hibernate fails sometimes with systemd resume/hibernate

Board footer