http://bugzilla.opensuse.org/show_bug.cgi?id=917221 Takashi Iwai <tiwai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Other |Basesystem Flags| |needinfo?(wguy4biz@comcast. | |net) --- Comment #16 from Takashi Iwai <tiwai@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.