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(a)redhat.com> escreveu:
De: Daniel J Walsh <dwalsh(a)redhat.com>
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>
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-----