Description of problem:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Nothing, prompt returns. Nothing written to /var/log/pm-hibernate.log
Hibernation to start and machine shuts down.
This was working as far as I recall with the previous pm-utils. I have also
switched to kernels that had hibernate/resume working and they no longer work
either, so it seems very likely that pm-utils is the culprit as it is the only
thing that has recently changed.
Also trying the gnome-power management applet or the "Shut Down" button and
selecting "Hibernate" has the same effect: no attempt at hibernation is made.
Seems it was only just recently updated to 1.1.0, a major release just before
the f9 freeze on April 8 2008:
Is it possible this may have introduced regressions with respect to the way
suspend/hibernation is setup in Fedora?
from http://pm-utils.freedesktop.org/wiki/ :
"1.1.0 Release announcement"
There have been several changes to the way hooks are detected and invoked. If
you have a custom-written hook that breaks upon installation of this package,
you may have to perform some minor fixups to make it work again. All the hooks
that are supplied with pm-utils have been updated to take full advantage of
these changes, so use them as examples. For more detailed information, see
Can you attach the output of:
(run it as root pls).
Created attachment 302222 [details]
pm bug report output
Note that the kernel I've booted into: -121 was the kernel that previously
worked for me. I do get exactly the same issue on the latest kernel.
Did you run pm-hibernate as root or as user?
Do you perhaps have a stale lock file in /var/run/pm-utils/locks? I noticed the
lock in that directory does not get deleted by /etc/rc.d/rc.sysinit. Maybe it
removing from PR blocker. Does not block tier 1 or 2 testcases, nor
(In reply to comment #6)
> Did you run pm-hibernate as root or as user?
(In reply to comment #7)
> Do you perhaps have a stale lock file in /var/run/pm-utils/locks? I noticed the
> lock in that directory does not get deleted by /etc/rc.d/rc.sysinit. Maybe it
> should be.
Hmm, I did look around for a such a file, but I was looking in /var/lock and
/var/tmp/ and other places. I'll check now and see if that was it (don't have
access to my rawhide machine just now).
If this turns out to be the problem, this must be a behaviour change in pm-utils
because previously a failed hibernate/resume cycle didn't prevent a subsequent
(In reply to comment #9)
> (In reply to comment #6)
> > Did you run pm-hibernate as root or as user?
To clarify, the command that generated the attachment was done as root.
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #6)
> > > Did you run pm-hibernate as root or as user?
> > Both.
> To clarify, the command that generated the attachment was done as root.
Now I am confused, did you run "pm-hibernate" as root to try to hibernate.
(In reply to comment #11)
> > To clarify, the command that generated the attachment was done as root.
> Now I am confused, did you run "pm-hibernate" as root to try to hibernate.
I ran the following
1) pm-hibernate as root and as user
2) /usr/bin/pm-utils-bugreport-info.sh as root (output attached)
In any case it appears that the problem is the stale lock file
/var/run/pm-utils/locks/pm-hibernate.log (or somesuch). Once I removed that,
pm-hibernate works fine, so changing bug summary.
I did notice that upon a fresh startup, I do see something like the following in
the initscripts output:
"cannot remove /var/run/pm-utils/locks it is a directory"
so it does seem to be attempting to cleanup the lock files, but fails because it
may be looking in the wrong place.
(In reply to comment #12)
> "cannot remove /var/run/pm-utils/locks it is a directory"
> so it does seem to be attempting to cleanup the lock files, but fails because it
> may be looking in the wrong place.
This seems to be consistent with comment #7
rc.sysinit needs to clean /var/run/pm-utils/locks/* on bootup and maybe
/var/run/pm-utils/storage/*, too. (it would not hurt ;-)). Maybe it should even
remove every file below /var/run on bootup. Directories may be an issue, because
of selinux, but I may be wrong here.
Fixed in initscripts-8.70-1.
*** Bug 270841 has been marked as a duplicate of this bug. ***