http://bugzilla.opensuse.org/show_bug.cgi?id=917221 --- Comment #15 from John Leys <wguy4biz@comcast.net> --- (In reply to Takashi Iwai from comment #14)
(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.
I noticed that a few things in the pm-hibernate execution path and the 'systemctl hibernate' execution path were duplicative, e.g. 'grub-once', which likely needs to be addressed. It seems that the new hibernation strategy implementation, i.e using systemd, did not adequately address conflicts with the old hibernation strategy implemenation, i.e. using pm-utils. I tried various things: 1. systemctl hibernate 2. Removing all files in the /var/lib/pm-utils/sleep.d (/etc/pm-utils/sleep.d was empty) 3. Removal of the pm-utils package 4. Revert to kernel 3.16.7-7-desktop (not OBS kernel) with no pm-utils With 3 and 4 i only used 'systemctl hibernate' to effect hibernation. Of these both 3 and 4 are very successful, but 3 still has intermittent problems. With 3 the hibernation occasionally fails to power off the machine at the end of the hibernation and occasionally fails to restore the display on resume, though it successfully restores teh image. With 4 the process has not had any problems so far, though i have not tested this configuration for a long period of time; i will update the bug if it appears to still have problems. With options 1 and 2 there was occasional success, but often failures of the same kind as before, i.e. failue in the process of restoring the image. I noticed that the pm-utils attempted to lock out concurrent hibernation by using 'flock'; i wonder if teh systemd approach did the same thing. While executing grub-once is idempotent, other actions performed in the processing of hibernation are not necessarily idempotent, so if there are 2 threads performing the same processing, even successively, it could be problematic. For now, the problem seems to be resolved by just removing the pm-utils package, though YAST keeps on trying to re-install it whenever i go into the software management dialog. If i continue to have problems, i will update the bug accordingly. -- You are receiving this mail because: You are on the CC list for the bug.