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