Failure to resume from hibernate with kernel 6.15

Hello EndeavourOS community!

I recently started to use EndeavourOS. I would like to kindly ask for help for an issue that I’m experiencing: apparently the system is unable to resume from hibernation with kernel 6.15. Is anyone else experiencing this issue?

I tried to install LTS kernel 6.12.37-1-lts, and hibernation is working properly with it. What I see with 6.15 is that the system tries to resume, but the kernel crashes (caps lock is blinking). Last thing I see in the console is “Starting Resume from hibernation”.

I tried to collect logs by increasing kernel verbosity (more logs are actually printed), but apparently I do not see logs from the resume operation (maybe those logs are lost?).

System logs from journalctl -k -b -1 --no-pager ends with:

lug 15 18:18:55 luca-lenovo unknown: hibernating
lug 15 18:18:58 luca-lenovo kernel: wlan0: deauthenticating from b0:39:56:55:9e:ac by local choice (Reason: 3=DEAUTH_LEAVING)
lug 15 18:18:59 luca-lenovo kernel: PM: hibernation: hibernation entry

where the first line is something I wrote immediately before hibernating.

Info about my system: https://0x0.st/8kxh.txt.

I found this bug report: https://bugzilla.kernel.org/show_bug.cgi?id=219998, but I guess the fix should be included in my kernel already.

Anyone else with the same problem?
Thank you.
Best regards.

  1. to hibernate please run in terminal mode :

sudo systemctl hibernate -i

  1. wait till your laptop or computer is completely down !
  2. start your computer
    you should see message

Starting Resume from hibernation …

  1. wait till you see your login screen
  2. login, after login
    try in terminal mode

sudo journalctl -b -u systemd-hibernate

as output you should have something like :

systemd[1]: Starting System Hibernate…
systemd-sleep[11467]: Successfully froze unit ‘user.slice’.
systemd-sleep[11467]: Performing sleep operation ‘hibernate’…
systemd-sleep[11467]: System returned from sleep operation ‘hibernate’.
systemd-sleep[11467]: Successfully thawed unit ‘user.slice’.
systemd[1]: systemd-hibernate.service: Deactivated successfully.
systemd[1]: Finished System Hibernate.
systemd[1]: systemd-hibernate.service: Consumed 2.455s CPU time, 1.7M memory peak.

when problems :

  • check your swap space , swap space must be big enough

  • cat /etc/kernel/cmdline and/or cat /proc/cmdline

For verification, just tried that on my EOS/Cinnamon laptop:

$ sudo systemctl hibernate -i
$ sudo journalctl -b -u systemd-hibernate
Jul 15 21:14:22 toshi-mch systemd[1]: Starting System Hibernate...
Jul 15 21:14:22 toshi-mch systemd-sleep[12279]: Successfully froze unit 'user.slice'.
Jul 15 21:14:22 toshi-mch systemd-sleep[12279]: Performing sleep operation 'hibernate'...
Jul 15 21:24:32 toshi-mch systemd-sleep[12279]: System returned from sleep operation 'hibernate'.
Jul 15 21:24:32 toshi-mch systemd-sleep[12279]: Successfully thawed unit 'user.slice'.
Jul 15 21:24:32 toshi-mch systemd[1]: systemd-hibernate.service: Deactivated successfully.
Jul 15 21:24:32 toshi-mch systemd[1]: Finished System Hibernate.
Jul 15 21:24:32 toshi-mch systemd[1]: systemd-hibernate.service: Consumed 2.825s CPU time, 1.7M memory peak.
$ uname -a
Linux toshi-mch 6.15.6-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 10 Jul 2025 17:10:18 +0000 x86_64 GNU/Linux

Apart from hibernation taking 10 minutes (!), all went smooth.

After sudo systemctl hibernate -i the machine turned off. Resuming results in a kernel crash, as said. I therefore reset the machine and booted again. At this point:

$ sudo journalctl -b -u systemd-hibernate
[sudo] password for luca: 
-- No entries --

Swap should be sufficient (in fact, 6.12 properly works):

               total        used        free      shared  buff/cache   available
Mem:            62Gi       3,8Gi        57Gi       196Mi       2,4Gi        58Gi
Swap:           65Gi          0B        65Gi

kernel params:

cat /proc/cmdline
initrd=\834cf8db02b44f18acef6ffe0d67a409\6.15.6-arch1-1\initrd nvme_load=YES nowatchdog rw root=UUID=a38247ab-b5ce-4cd3-8b02-77f4e0600bf8 resume=UUID=1f32e21e-9fdd-4bf8-ae1f-01d98a36e210 systemd.machine_id=834cf8db02b44f18acef6ffe0d67a409 loglevel=7

Anything else I can test?
Thank you.

your quote ; Apart from hibernation taking 10 minutes (!), all went smooth.
This 10 minutes is not the time it takes to restart your system from hibernation !!!

if you go in hibernate with ‘sudo systemctl hibernate -i’
and you wait 30 minutes to restart your computer then you will see 30 minutes
if you wait 1 day, 2 days, … then it is 1 day, 2 days, …

you have a kernel crash …
i am using : extra/linux-zen 6.15.6.zen1-1
please try with another kernel , install linux-zen
‘sudo pacman -S linux-zen’
restart computer and start with the zen kernel
and retry

Sure, I know :wink: Don’t check the timing in the log, that’s coincidental, since I restarted almost directly after the machine powered off.

Hello,
tested zen kernel and nothing changes. Resuming from hibernation results in a kernel crash.

‘sudo dracut-rebuild’
check : Troubleshooting Steps for Arch Kernel Crashes:

  1. 1. Identify the type of crash:

A blinking Caps Lock LED is a strong indicator of a kernel panic, which is a critical error the kernel cannot recover from.

  1. 2. Check for Firmware and Microcode Issues:

Update your system’s firmware and ensure microcode loading is configured correctly, as these can resolve low-level hardware-related issues.

  1. 3. Attempt to Reproduce the Crash:

Try to replicate the crash in a controlled environment, potentially using a live environment of a different Linux distribution to rule out Arch-specific configurations.

  1. 4. Hardware Diagnostics:

If crashes persist in a live environment, suspect hardware issues like CPU or RAM problems. Running stress tests or memory diagnostics can help pinpoint these. Machine Check Exceptions (MCEs) are a strong indicator of hardware problems.

  1. 5. Analyze Logs:

After a crash, if possible, review system logs like dmesg or /var/log/pacman.log for clues about the error.

  1. 6. Consider kdump:

For advanced debugging of kernel panics, set up kdump to collect a crash dump of the kernel’s memory for later analysis.

  1. 7. Specific Component Checks:
  • NVIDIA Drivers: Users experiencing frequent panics with NVIDIA drivers may need to revert to a specific driver version or ensure proper installation.
  • Power Management: Issues related to power management settings, especially on laptops, can sometimes cause instability; disabling battery conservation modes or other power-saving features might help.
  • Corrupted Filesystems or Drives: A severely corrupted drive can also lead to kernel panics; investigate drive health and consider replacement if necessary.
  1. 8. Kernel Parameters:

Experiment with adding or modifying kernel parameters, such as amdgpu.dcdebugmask=0x12 for AMD graphics or acpi=off if you suspect ACPI-related issues.

  1. 9. Reinstalling Packages:

If a crash occurred during an update, the system might be in a broken state. You may need to reinstall packages, especially those related to critical system components, potentially using a chroot environment if the system won’t boot.

Most of this is difficult for an hibernation issue. Also please consider that lts works properly but all 6.15 versions that I tested are not (at least the last 3 or 4 versions).

I rebuilt the kernel following https://wiki.archlinux.org/title/Kernel/Traditional_compilation. I’m finding however difficult to install the kernel in endeavour which uses systemd-boot. Is there a specific walkthrough for endeavour with systemd-boot? Testing a mainline kernel may be a good test.
Thank you.

Luca,
your problem is inital not a hibernate problem but a problem with rebuilding your kernel !!!
your quote : [quote=“luca, post:11, topic:73551”]
I rebuilt the kernel following https://wiki.archlinux.org/title/Kernel/Traditional_compilation. I’m finding however difficult to install the kernel in endeavour which uses systemd-boot. Is there a specific walkthrough for endeavour with systemd-boot? Testing a mainline kernel may be a good test
[/quote]
Please open a new issue for above problem.

Hello,
could you please elaborate on your statement? The problem I am experiencing regards all official releases of 6.15. While the problem is not there in 6.12, I checked. I am rebuilding the kernel just to try to investigate further.