(In reply to John Leys from comment #13) > The problem happens pretty much universally now when using pm-hibernate; i > have not had a successful resume in some time using pm-hibernate. The > pm-suspend works fine. > > In doing some research, i discovered that a way to test is to write directly > to files in the /sys/power directory. When i do this, the hibernate works > every time: > 1. echo "platform" > /sys/power/disk > 2. echo "disk" /sys/power/state > > The hibernate/thaw works correctly and there does not seem to be any problem > finding the snapshotted image on the disk used for resume. The number of the > disk used for snapshotting and restoring is the one stored in > /sys/power/resume file, and is 8:5, reflecting the number for the resume > disk, /dev/sda5: > # ll /dev/sda5 > brw-rw---- 1 root disk 8, 5 Feb 18 16:19 /dev/sda5 > > It is not clear whether s2disk is the problem, but i tried both 'uswsusp' > and 'kernel' methods for hibernate, changing SLEEP_MODULE in > /usr/lib/pm-utils/defaults, but neither seemed to work; both end up not > being able to find the hibernation image. Thanks, it's a good find. This reminds me of a bug in the hooks we had, where fsck is running before thawing. But I thought this was already fixed. In anyway, to be sure, test with "systemctl hibernate", too. This is more official way to perform suspend/resume. With oS13.2 version, this is almost as pm-utils is present, so it should also fail. The rest task would be to drop /usr/lib/pm-utils/sleep.d/* and /etc/pm-utils/sleep.d/* to identify which one triggers the problem.