Am Sonntag, den 12.02.2017, 19:42 +0100 schrieb Axel Braun:
Feb 12 19:20:33 eeePC kernel: PM: Image not found (code -22) Feb 12 19:20:33 eeePC kernel: PM: Hibernation image not present or could not be loaded. Feb 12 19:20:33 eeePC systemd[1]: Started Resume from hibernation using device /dev/sda1. Feb 12 19:20:33 eeePC systemd[1]: Reached target Local File Systems (Pre). Feb 12 19:20:33 eeePC systemd[1]: Reached target Local File Systems. Feb 12 19:20:33 eeePC systemd[1]: Reached target System Initialization. Feb 12 19:20:33 eeePC systemd[1]: Reached target Basic System. Feb 12 19:20:33 eeePC systemd[1]: Starting File System Check on /dev/disk/by-uuid/efb6a106-11a1-4537-baac-2d2
Obviously the image file was not written properly? Any idea what I could try?
You are running into a safety feature. The "sacrificial" kernel clears the hibernation signature on the swap partition. This is necessary because if the resumption fails you'd be in an eternal boot loop. Essentially a driver crashes when it needs to resume. Debugging this is usually cumbersome, but straight forward. 1. You determine whether the the user space resumption code is faulty. To do so you do a brute force suspension echo "disk" > /sys/power/state This will make the kernel do a brute force suspension with an uncompressed image. 2. If that also fails you need to identify the failing driver. As tedious as it sounds, blacklist more and more drivers until your system survives a cycle. HTH Oliver -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org