Bug 965814

can you attach the contents of:

/proc/swaps
/etc/fstab
/etc/crypttab
/proc/cmdline

and the output of:

# rpm -q dracut
# lsinitrd

I do have the same problem, but am on i686:
3.9.4-300.fc19.i686.PAE

klaus@acer:/etc/systemd$ cat /proc/swaps 
Filename				Type		Size	Used	Priority
/dev/sda6                               partition	2097148	164	-1
klaus@acer:/etc/systemd$ cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Sat May 25 15:47:08 2013
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=49f00f1e-6ea9-4f2d-be79-23aeddc365b8 /                       ext4    defaults        1 1
UUID=fc6868d9-cde4-45ec-82bb-430bff93e74b /boot                   ext3    defaults        1 2
UUID=2c5d7815-8d4f-420a-b175-d626bb5097f4 /home                   ext4    defaults        1 2
UUID=609cd110-13ec-44ac-9769-13930f7c03bc swap                    swap    defaults        0 0
klaus@acer:/etc/systemd$ sudo cat /etc/crypttab 
klaus@acer:/etc/systemd$ cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-3.9.4-300.fc19.i686.PAE root=UUID=49f00f1e-6ea9-4f2d-be79-23aeddc365b8 ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 vconsole.keymap=de rhgb quiet LANG=de_DE.UTF-8
klaus@acer:/etc/systemd$  rpm -q dracut
dracut-027-46.git20130430.fc19.i686
klaus@acer:/etc/systemd$ 


lsinitrd will be attached

Created attachment 753974 [details]
Output of lsinitrd

(In reply to Klaus Lichtenwalder from comment #2)
Does it work, if you add
resume=UUID=609cd110-13ec-44ac-9769-13930f7c03bc
to the kernel command line?

Harald,

yes, adding this option helps getting thawing from hibernation to work

Klaus

*** Bug 953305 has been marked as a duplicate of this bug. ***

I will add auto resume in dracut host-only mode.

Created attachment 781889 [details]
Output of lsinitrd

Hello,
I've the same problem with hibernate.

My data:
[root@st00ni0029 ~]# cat /proc/swaps
Filename                                Type            Size    Used    Priority
/dev/dm-5                               partition       4192252 0       -1
[root@st00ni0029 ~]# cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Tue Jul 30 12:14:18 2013
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/luks-e5b03e50-4652-482a-960f-2975eff5e02b /                       ext4    defaults,x-systemd.device-timeout=0 1 1
UUID=ee2bc52a-d88d-4cc3-920d-caca9d225a37 /boot                   ext4    defaults        1 2
/dev/mapper/luks-a195076a-ac71-4756-8d15-ad1ed5582207 /home                   ext4    defaults,x-systemd.device-timeout=0 1 2
/dev/mapper/luks-22ad6af8-9394-481e-9c80-871ddad68360 swap                    swap    defaults,x-systemd.device-timeout=0 0 0
tmpfs                                                 /tmp     tmpfs   defaults,noatime,mode=1777,size=256M  0 0
[root@st00ni0029 ~]# cat /etc/crypttab
luks-22ad6af8-9394-481e-9c80-871ddad68360 UUID=22ad6af8-9394-481e-9c80-871ddad68360 none 
luks-e5b03e50-4652-482a-960f-2975eff5e02b UUID=e5b03e50-4652-482a-960f-2975eff5e02b none 
luks-786f54c2-bce9-499d-b32b-045111dc5b4f UUID=786f54c2-bce9-499d-b32b-045111dc5b4f none 
luks-a195076a-ac71-4756-8d15-ad1ed5582207 UUID=a195076a-ac71-4756-8d15-ad1ed5582207 none 
[root@st00ni0029 ~]# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.10.3-300.fc19.x86_64 root=/dev/mapper/luks-e5b03e50-4652-482a-960f-2975eff5e02b ro rd.md=0 rd.dm=0 rd.lvm.lv=vg_st00ni0029/swap_lv rd.luks.uuid=luks-e5b03e50-4652-482a-960f-2975eff5e02b rd.luks.uuid=luks-22ad6af8-9394-481e-9c80-871ddad68360 rd.luks.uuid=luks-786f54c2-bce9-499d-b32b-045111dc5b4f rd.lvm.lv=vg_st00ni0029/root_lv vconsole.font=latarcyrheb-sun16 vconsole.keymap=de rhgb quiet
[root@st00ni0029 ~]# 
[root@st00ni0029 ~]# 
[root@st00ni0029 ~]# rpm -q dracut
dracut-029-2.fc19.x86_64
[root@st00ni0029 ~]#

(In reply to Andreas Reschke from comment #9)
> Hello,
> I've the same problem with hibernate.

Hmm, that "should" work.

Does it help, if you add "resume=/dev/mapper/luks-22ad6af8-9394-481e-9c80-871ddad68360" to the kernel command line?

(In reply to Harald Hoyer from comment #10)
> (In reply to Andreas Reschke from comment #9)
> > Hello,
> > I've the same problem with hibernate.
> 
> Hmm, that "should" work.
> 
> Does it help, if you add
> "resume=/dev/mapper/luks-22ad6af8-9394-481e-9c80-871ddad68360" to the kernel
> command line?

Bingo!!

Thank you Harald, that works.
How can I add this permanent? When I set this to /boot/grub2/grub.cfg then next kernel-update removes this.

Thanks
Andreas

(In reply to Andreas Reschke from comment #11)
> (In reply to Harald Hoyer from comment #10)
> > (In reply to Andreas Reschke from comment #9)
> > > Hello,
> > > I've the same problem with hibernate.
> > 
> > Hmm, that "should" work.
> > 
> > Does it help, if you add
> > "resume=/dev/mapper/luks-22ad6af8-9394-481e-9c80-871ddad68360" to the kernel
> > command line?
> 
> Bingo!!
> 
> Thank you Harald, that works.
> How can I add this permanent? When I set this to /boot/grub2/grub.cfg then
> next kernel-update removes this.
> 
> Thanks
> Andreas

Theoretically that line should not be needed.. I have to debug it more.
A kernel update should really preserve the options of the last kernel.

(In reply to Harald Hoyer from comment #12)
> (In reply to Andreas Reschke from comment #11)
> > (In reply to Harald Hoyer from comment #10)
> > > (In reply to Andreas Reschke from comment #9)
> > > > Hello,
> > > > I've the same problem with hibernate.
> > > 
> > > Hmm, that "should" work.
> > > 
> > > Does it help, if you add
> > > "resume=/dev/mapper/luks-22ad6af8-9394-481e-9c80-871ddad68360" to the kernel
> > > command line?
> > 
> > Bingo!!
> > 
> > Thank you Harald, that works.
> > How can I add this permanent? When I set this to /boot/grub2/grub.cfg then
> > next kernel-update removes this.
> > 
> > Thanks
> > Andreas
> 
> Theoretically that line should not be needed.. I have to debug it more.
> A kernel update should really preserve the options of the last kernel.

Hello,
I've update my Laptop to 3.10.6-200.fc19.x86_64 and pm-hibernate doesnt work anymore:
---snip---
Fri Aug 16 10:29:39 CEST 2013: performing hibernate
/usr/lib64/pm-utils/pm-functions: line 323: echo: write error: No such device
Fri Aug 16 10:29:47 CEST 2013: Awake.
---snip---
I've added the output of pm-utils-bugreport-info.sh

Created attachment 787205 [details]
output of pm-utils-bugreport-info.sh

try:

# systemctl hibernate

(In reply to Andreas Reschke from comment #14)
> Created attachment 787205 [details]
> output of pm-utils-bugreport-info.sh

This is not a dracut issue, btw

Created attachment 796187 [details]
pm-utils-bugreport-info.sh output

pm-utils-bugreport-info.sh output

Having same problem as Andreas Reschke: pm-hibernate doesnt work anymore. I'm  running 3.10.10-200.fc19.x86_64 and pm-utils-1.4.1-24.fc19.x86_64.

From pm-utils-bugreport-info.sh you can see:
...
...
Running hook /usr/lib64/pm-utils/sleep.d/99video hibernate hibernate:
/usr/lib64/pm-utils/sleep.d/99video hibernate hibernate: success.

Tue Sep 10 19:25:42 BRT 2013: performing hibernate
/usr/lib64/pm-utils/pm-functions: line 323: echo: write error: No such device
Tue Sep 10 19:25:54 BRT 2013: Awake.
Tue Sep 10 19:25:54 BRT 2013: Running hooks for thaw
Running hook /usr/lib64/pm-utils/sleep.d/99video thaw hibernate:
/usr/lib64/pm-utils/sleep.d/99video thaw hibernate: success.
...
...

In my specific case, looking the logs, it seems pm-hibernate runs most of the script but lets a blank screen and cursor blinking at the upper left corner, but itś not able to power off the computer.

(In reply to Valmir Parisi from comment #18)
> Having same problem as Andreas Reschke: pm-hibernate doesnt work anymore.
> I'm  running 3.10.10-200.fc19.x86_64 and pm-utils-1.4.1-24.fc19.x86_64.
> 
> From pm-utils-bugreport-info.sh you can see

Then file a new bugzilla with component pm-hibernate

Created attachment 813519 [details]
contents of /proc/swaps

Created attachment 813520 [details]
contents of /etc/fstab

Created attachment 813521 [details]
contents of /proc/cmdline

Created attachment 813522 [details]
output of "rpm -q dracut"

Created attachment 813523 [details]
output of "lsinitrd"

I'm experiencing the same problem on a Lenovo T420 Thinkpad with Intel graphics running Fedora 20. Upon running "systemctl hibernate" the system shuts down however at the next boot it starts gdm instead of resuming. I'm running a testing version of Fedora 20.

I've attached the information requested by Harald Hoyer with the exception of /etc/crypttab since that file is empty on my system.

I can confirm that on a F20 install. The system starts "normally" after having hibernated, i.e. does NOT resume.

(In reply to Jonathon Conte from comment #21)
> Created attachment 813520 [details]
> contents of /etc/fstab

add 
resume=UUID=d2d44d6d-da9f-4950-a158-2c4939e24078
to the kernel command line.

Will fix.

Adding that kernel option worked for me too, Harald. Thank you very much!

Adding that kernel option worked for me.

For next kernel release update, can be solve by editing /etc/default/grub
change line
GRUB_CMDLINE_LINUX="vconsole.font=latarcyrheb-sun16 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rhgb quiet"
to
GRUB_CMDLINE_LINUX="vconsole.font=latarcyrheb-sun16 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rhgb quiet resume=$(grep swap /etc/fstab | awk '{ print $1 }')"

Fedora20 to have this problem too, but other than that kernel does not understand the option resume=UUID=d2d44d6d-da9f-4950-a158-2c4939e24078 understands only explicit partition resume=/dev/sdb6, for example.
If I set resume=UUID=d2d44d6d-da9f-4950-a158-2c4939e24078 system boot not from hibernate, in dmesg 
PM: Hibernation image not present or could not be loaded.

(In reply to Kornienko Sergey from comment #29)
> Adding that kernel option worked for me.
> 
> For next kernel release update, can be solve by editing /etc/default/grub
> change line
> GRUB_CMDLINE_LINUX="vconsole.font=latarcyrheb-sun16 $([ -x
> /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rhgb
> quiet"
> to
> GRUB_CMDLINE_LINUX="vconsole.font=latarcyrheb-sun16 $([ -x
> /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rhgb
> quiet resume=$(grep swap /etc/fstab | awk '{ print $1 }')"
> 
> Fedora20 to have this problem too, but other than that kernel does not
> understand the option resume=UUID=d2d44d6d-da9f-4950-a158-2c4939e24078
> understands only explicit partition resume=/dev/sdb6, for example.
> If I set resume=UUID=d2d44d6d-da9f-4950-a158-2c4939e24078 system boot not
> from hibernate, in dmesg 
> PM: Hibernation image not present or could not be loaded.

use PARTUUID instead of UUID, if you have GPT partitioning To find out about the PARTUUID, run:

# blkid /dev/sdb6

Thanks Harold!
I do not use the TGV, but your advice helped me.
I propose the following fix for /etc/default/grub

GRUB_CMDLINE_LINUX="vconsole.font=latarcyrheb-sun16 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rhgb quiet resume=$(SWAPUUID=`grep swap /etc/fstab | awk '{ print $1 }' | cut -d'=' -f2`; SWAPDEV=`blkid -U $SWAPUUID`; PARTUUID=`blkid $SWAPDEV | egrep -o  'PARTUUID=".*?"'`; echo $PARTUUID)

(In reply to Kornienko Sergey from comment #31)
> Thanks Harold!
> I do not use the TGV, but your advice helped me.
> I propose the following fix for /etc/default/grub
> 
> GRUB_CMDLINE_LINUX="vconsole.font=latarcyrheb-sun16 $([ -x
> /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rhgb
> quiet resume=$(SWAPUUID=`grep swap /etc/fstab | awk '{ print $1 }' | cut
> -d'=' -f2`; SWAPDEV=`blkid -U $SWAPUUID`; PARTUUID=`blkid $SWAPDEV | egrep
> -o  'PARTUUID=".*?"'`; echo $PARTUUID)

Please file a new bug against the component, which provides this file or reassign this bug.

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.