Comment # 15 on bug 917221 from John Leys

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