De: Daniel J Walsh <dwalsh(a)redhat.com&gt; Assunto: Re: Hibernate stopped working. Have no clue why. Para: sergiocmailbox-userlist(a)yahoo.com.br, "Community support for Fedora users" <users(a)lists.fedoraproject.org&gt; 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. > > >