Comment # 16 on bug 917221 from Takashi Iwai

(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.