Hibernate stopped working. Have no clue why.

[Sergio]

Thanks, Daniel. I put it in permissive to test.
Anyway, I have no real evidence that selinux would be involved in this (except that it happened after the latest update on Sep 22). I'm just very ignorant and since selinux is at the background I suspected it ;-)
But I guess if it was involved it would give some output.

My hardware is old, I already have to use the AGP driver from the nvidia driver because the kernel driver doesn't work for suspend/hibernate so some other update might have broken it.

--- Em sáb, 29/9/12, Daniel J Walsh <dwalsh at redhat.com> escreveu:

> De: Daniel J Walsh <dwalsh at redhat.com>
> Assunto: Re: Hibernate stopped working. Have no clue why.
> Para: sergiocmailbox-userlist at yahoo.com.br, "Community support for Fedora users" <users at lists.fedoraproject.org>
> Data: Sábado, 29 de Setembro de 2012, 7:57
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> We strive not to break anything in updates.  SELinux
> policy is almost always
> about adding allow rules to make policy looser on a released
> version of
> Fedora.  We might add new containment on a new version
> but even if we add
> policy during a shipping version, it will always be
> permissive.  (Even new
> policy types in the Fedora 18 ships permissive mode.)
> 
> Can't guarantee if SELinux is involved, but if it worked
> before, I don't think
> an selinux-policy update would have broken it. But you could
> always try in
> permissive mode.
> 
> On 09/28/2012 07:19 PM, Sergio wrote:
> > Hello list. Hibernate used to work fine (didn't use it
> much though) but
> > stopped working these last days. Suspend still works
> but while it worked
> > flawlessly, now I have had some times that when it's
> suspended for a longer
> > time it won't come up or won't come up properly (no
> video).
> > 
> > I have no clue except the regular tendentious suspicion
> on the
> > selinux-policy* updates these last days (I always
> suspect them when there's
> > no visible error; don't know if they deserve this or
> not).
> > 
> > Anyway, I'm attaching pm-suspend.log and the relevant
> part of
> > /var/log/messages from the last try to hibernate (it
> was only a few minutes
> > powered down as I was just testing). pm-suspend.log has
> no news; it's just
> > the normal failure that it has the suspend recorded but
> not the awake.
> > 
> > Now the messages look somewhat weird. A normal boot
> up:
> > 
> > Sep 28 19:11:09 f17 kernel: imklog 5.8.10, log source =
> /proc/kmsg
> > started. Sep 28 19:11:09 f17 rsyslogd: [origin
> software="rsyslogd"
> > swVersion="5.8.10" x-pid="588" x-info="http://www.rsyslog.com"] start Sep
> > 28 19:11:09 f17 systemd-cryptsetup[467]: Volume
> > luks-887e89d1-eabf-47ff-9bc7-c879d2ab511a already
> active. Sep 28 19:11:09
> > f17 systemd-cryptsetup[472]: Set cipher aes, mode
> xts-plain64, key size 512
> > bits for device
> /dev/disk/by-uuid/6975cc34-9e46-4507-ae14-20774e5251bd. Sep
> > 28 19:11:09 f17 systemd-fsck[474]: /dev/sda1: clean,
> 347/128016 files,
> > 81320/512000 blocks Sep 28 19:11:09 f17
> systemd-fsck[504]:
> > /dev/mapper/luks-6975cc34-9e46-4507-ae14-20774e5251bd:
> clean, 124217/436320
> > files, 649888/1742080 blocks Sep 28 19:11:09 f17
> jexec[516]: Starting jexec
> > services Sep 28 19:11:09 f17 auditctl[545]: No rules
> Sep 28 19:11:09 f17
> > auditctl[545]: AUDIT_STATUS: enabled=0 flag=1 pid=0
> rate_limit=0
> > backlog_limit=320 lost=0 backlog=0 Sep 28 19:11:09 f17
> auditd[544]: Started
> > dispatcher: /sbin/audispd pid: 553 Sep 28 19:11:09 f17
> audispd: No plugins
> > found, exiting {snip}
> > 
> > Here's after I previously hibernated:
> > 
> > Sep 28 19:23:07 f17 kernel: imklog 5.8.10, log source =
> /proc/kmsg
> > started. Sep 28 19:23:07 f17 rsyslogd: [origin
> software="rsyslogd"
> > swVersion="5.8.10" x-pid="602" x-info="http://www.rsyslog.com"] start Sep
> > 28 19:23:07 f17 swapon[448]: swapon:
> > /dev/mapper/luks-887e89d1-eabf-47ff-9bc7-c879d2ab511a:
> software suspend
> > data detected. Rewriting the swap signature. Sep 28
> 19:23:07 f17
> > systemd-cryptsetup[474]: Volume
> luks-887e89d1-eabf-47ff-9bc7-c879d2ab511a
> > already active. Sep 28 19:23:07 f17
> systemd-cryptsetup[477]: Set cipher
> > aes, mode xts-plain64, key size 512 bits for device
> > /dev/disk/by-uuid/6975cc34-9e46-4507-ae14-20774e5251bd.
> Sep 28 19:23:07 f17
> > systemd-fsck[482]: /dev/sda1: recovering journal Sep 28
> 19:23:07 f17
> > systemd-fsck[482]: /dev/sda1: clean, 347/128016 files,
> 81320/512000 blocks 
> > Sep 28 19:23:07 f17 systemd-fsck[514]:
> > /dev/mapper/luks-6975cc34-9e46-4507-ae14-20774e5251bd:
> recovering journal 
> > Sep 28 19:23:07 f17 systemd-fsck[514]:
> > /dev/mapper/luks-6975cc34-9e46-4507-ae14-20774e5251bd:
> clean, 124216/436320
> > files, 649886/1742080 blocks Sep 28 19:23:07 f17
> jexec[526]: Starting jexec
> > services Sep 28 19:23:07 f17 auditctl[557]: No rules
> Sep 28 19:23:07 f17
> > auditctl[557]: AUDIT_STATUS: enabled=0 flag=1 pid=0
> rate_limit=0
> > backlog_limit=320 lost=0 backlog=0 Sep 28 19:23:07 f17
> auditd[554]: Started
> > dispatcher: /sbin/audispd pid: 568 {snip}
> > 
> > Difference is that swapon line that detects suspend
> data. But then it boots
> > normally instead of loading the desktop and recovers
> the filesystem
> > (sda1=/boot and the encrypted=/home).
> > 
> > Thanks for any clues you may have.
> > 
> > 
> > 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
> 
> iEYEARECAAYFAlBm1AwACgkQrlYvE4MpobPJtQCgqDts6SoCzPtPsAOMv/4VVPY/
> mTIAoNRmfiKiqJkW/faP1Yj54lQUki7V
> =ch+m
> -----END PGP SIGNATURE-----
>