Am Mittwoch, 15. Februar 2017, 13:24:58 CET schrieb Oliver Neukum:
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.
Same as before, hibernation and no proper wake-up
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.
the point to start is probably the list of loaded modules (lsmod) then match against PCI and USB hardware, and make a guess what is not needed, correct? Thanks Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org