Comment # 14 on bug 917221 from
(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.


You are receiving this mail because: