Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora User (http://www.linux-archive.org/fedora-user/)
-   -   Hibernate stopped working. Have no clue why. (http://www.linux-archive.org/fedora-user/708235-hibernate-stopped-working-have-no-clue-why.html)

Sergio 09-28-2012 11:19 PM

Hibernate stopped working. Have no clue why.
 
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.Sep 28 19:20:18 f17 NetworkManager[569]: <info> sleep requested (sleeping: no enabled: yes)
Sep 28 19:20:18 f17 NetworkManager[569]: <info> sleeping or disabling...
Sep 28 19:20:18 f17 NetworkManager[569]: <info> (em1): now unmanaged
Sep 28 19:20:18 f17 NetworkManager[569]: <info> (em1): device state change: activated -> unmanaged (reason 'sleeping') [100 10 37]
Sep 28 19:20:18 f17 NetworkManager[569]: <info> (em1): deactivating device (reason 'sleeping') [37]
Sep 28 19:20:18 f17 NetworkManager[569]: <info> (em1): canceled DHCP transaction, DHCP client pid 677
Sep 28 19:20:18 f17 avahi-daemon[586]: Withdrawing address record for 192.168.1.2 on em1.
Sep 28 19:20:18 f17 avahi-daemon[586]: Leaving mDNS multicast group on interface em1.IPv4 with address 192.168.1.2.
Sep 28 19:20:18 f17 avahi-daemon[586]: Interface em1.IPv4 no longer relevant for mDNS.
Sep 28 19:20:18 f17 NetworkManager[569]: <info> (em1): cleaning up...
Sep 28 19:20:18 f17 NetworkManager[569]: <info> (em1): taking down device.
Sep 28 19:20:18 f17 avahi-daemon[586]: Withdrawing address record for fe80::207:95ff:fee7:4ce on em1.
Sep 28 19:20:18 f17 dbus[612]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
Sep 28 19:20:18 f17 dbus-daemon[612]: dbus[612]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
Sep 28 19:20:18 f17 dbus-daemon[612]: dbus[612]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Sep 28 19:20:18 f17 dbus[612]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Sep 28 19:20:19 f17 chronyd[617]: Source 150.162.55.3 offline
Sep 28 19:20:19 f17 chronyd[617]: Source 146.164.53.65 offline
Sep 28 19:20:19 f17 chronyd[617]: Source 187.49.33.14 offline
Sep 28 19:20:19 f17 chronyd[617]: Source 200.192.112.8 offline
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
etc. (goes on booting normally)
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Daniel J Walsh 09-29-2012 10:57 AM

Hibernate stopped working. Have no clue why.
 
-----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/

iEYEARECAAYFAlBm1AwACgkQrlYvE4MpobPJtQCgqDts6SoCzP tPsAOMv/4VVPY/
mTIAoNRmfiKiqJkW/faP1Yj54lQUki7V
=ch+m
-----END PGP SIGNATURE-----
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Sergio 09-29-2012 01:35 PM

Hibernate stopped working. Have no clue why.
 
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@redhat.com> escreveu:

> De: Daniel J Walsh <dwalsh@redhat.com>
> Assunto: Re: Hibernate stopped working. Have no clue why.
> Para: sergiocmailbox-userlist@yahoo.com.br, "Community support for Fedora users" <users@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/
>
> iEYEARECAAYFAlBm1AwACgkQrlYvE4MpobPJtQCgqDts6SoCzP tPsAOMv/4VVPY/
> mTIAoNRmfiKiqJkW/faP1Yj54lQUki7V
> =ch+m
> -----END PGP SIGNATURE-----
>
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


All times are GMT. The time now is 06:28 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.