http://bugzilla.opensuse.org/show_bug.cgi?id=917221 John Leys <wguy4biz@comcast.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(wguy4biz@comcast. | |net) | --- Comment #17 from John Leys <wguy4biz@comcast.net> --- (In reply to Takashi Iwai from comment #16)
(In reply to John Leys from comment #15)
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.
Well, the openSUSE 13.2 systemd has an integration of pm-utils by the own patch. systemd invokes pm-utils stuff when it's found. If not, systemd tries to write /sys/power/state. In addition, systemd has its own hooks in /usr/lib/systemd/system-sleep/*. This is usually empty as default, though.
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.
3 and 4 are effectively doing the kernel hibernation (/sys/power/state).
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.
Could you try just to remove /usr/lib/pm-utils/sleep.d/99Zgrub? If it's about pm-utils hooks, this one appears most suspicious.
Because of the problems with BTRFS and grub-once, removing 99Zgrub was one of the first things that i did, even before filing this bug, and it was not effective; i also effectively nulled the systemd grub-once and the problem still occurred. Also, as i pointed out, i tried with nothing in /usr/lib/pm-utils/sleep.d and the problem still occurred. But 99Zgrub only targets a particular grub.cfg entry for use on the next startup, it does not modify the hibernate image; hibernate image creation and modification occurs after all of the sleep.d modules have been executed. -- You are receiving this mail because: You are on the CC list for the bug.