Bug 1224151 - Resume from Hibernated System not working on Fedora Workstation 22 RC
Summary: Resume from Hibernated System not working on Fedora Workstation 22 RC
Keywords:
Status: CLOSED DUPLICATE of bug 1206936
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 22
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: dracut-maint-list
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1236355 1310416 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-22 09:22 UTC by Sumit Bhardwaj
Modified: 2016-04-30 07:06 UTC (History)
26 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1310416 (view as bug list)
Environment:
Last Closed: 2016-04-29 17:16:35 UTC
Type: Bug


Attachments (Terms of Use)

Description Sumit Bhardwaj 2015-05-22 09:22:54 UTC
Description of problem:
On Fedora Workstation 22 x86_64 RC1 (possibly on RC2 and RC3 as well), hibernation using "systemctl hibernate" works out of the box, however resuming from hibernated image not happening. The system warm boots instead and starts fresh session after running fsck.

Version-Release number of selected component (if applicable):
2.02 beta2

How reproducible:
By hibernating the system using standard systemd commands.

Steps to Reproduce:
1. Hibernate the system
2. Reboot into Fedora again

Actual results:
System boots into a new session after running fsck on all filesystems

Expected results:
System resumes the previous hibernated user session.

Additional info:
Adding resume=UUID=<UUID> parameter in GRUB_CMDLINE_LINUX variable inside /etc/default/grub and doing grub2-mkconfig -o /boot/grub2/grub.cfg resolves the issue. Try to regenerate initrd using dracut -fv shows that "resume" module is already included, only the kernel command line parameter is missing.

Comment 1 Fedora Blocker Bugs Application 2015-05-22 09:47:46 UTC
Proposed as a Freeze Exception for 22-final by Fedora user krazyabouttechnology using the blocker tracking app because:

 If system is hibernated as part of power management policy or if user manually hibernates the system (using Gnome Shell extension or via command "systemctl hibernate" , on reboot, all the unsaved work is lost as system is not resumed to hibernated state . fsck also runs assuming the partitions are marked dirty.

If hibernate works properly, resume should also work...otherwise system should deny hibernation altogether.

Comment 2 Adam Williamson 2015-06-10 22:20:32 UTC
Clearing F22 accepted / nominated freeze exception status as F22 has shipped, per https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers . You may nominate as an Alpha, Beta or Final freeze exception for F23 if desired using the web application - https://qa.fedoraproject.org/blockerbugs/propose_bug (though it is not currently set up for F23) - or by marking the bug as blocking AlphaFreezeException, BetaFreezeException, or FinalFreezeException.

Comment 3 Andreas Reschke 2015-06-24 11:59:28 UTC
(In reply to Sumit Bhardwaj from comment #0)
> Description of problem:
> On Fedora Workstation 22 x86_64 RC1 (possibly on RC2 and RC3 as well),
> hibernation using "systemctl hibernate" works out of the box, however
> resuming from hibernated image not happening. The system warm boots instead
> and starts fresh session after running fsck.
> 
> Version-Release number of selected component (if applicable):
> 2.02 beta2
> 
> How reproducible:
> By hibernating the system using standard systemd commands.
> 
> Steps to Reproduce:
> 1. Hibernate the system
> 2. Reboot into Fedora again
> 
> Actual results:
> System boots into a new session after running fsck on all filesystems
> 
> Expected results:
> System resumes the previous hibernated user session.
> 
> Additional info:
> Adding resume=UUID=<UUID> parameter in GRUB_CMDLINE_LINUX variable inside
> /etc/default/grub and doing grub2-mkconfig -o /boot/grub2/grub.cfg resolves
> the issue. Try to regenerate initrd using dracut -fv shows that "resume"
> module is already included, only the kernel command line parameter is
> missing.

On my Laptop (HP Revolve 810) hibernate with luks-encrypted SSD didn't work even with this information. Fresh installation with F22 (x86_64) KDE and up2date packages.

cat /etc/default/grub 
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.lvm.lv=destnadml00_vg/root_lv rd.luks.uuid=luks-9927c3a0-13dd-4a34-ac0f-984d37cd7803 rd.lvm.lv=destnadml00_vg/swap_lv resume=UUID=luks-9927c3a0-13dd-4a34-ac0f-984d37cd7803 rhgb quiet"
GRUB_DISABLE_RECOVERY="true"

cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-4.0.5-300.fc22.x86_64 root=/dev/mapper/destnadml00_vg-root_lv ro rd.lvm.lv=destnadml00_vg/root_lv rd.luks.uuid=luks-9927c3a0-13dd-4a34-ac0f-984d37cd7803 rd.lvm.lv=destnadml00_vg/swap_lv rhgb quiet LANG=de_DE.UTF-8

Comment 4 Neil 2015-07-06 04:04:39 UTC
*** Bug 1236355 has been marked as a duplicate of this bug. ***

Comment 5 Neil 2015-11-06 14:47:19 UTC
Present also in Fedora 23.

I think this bug should be rawhide.

Comment 6 Francesco Frassinelli (frafra) 2015-12-28 10:01:31 UTC
Same here: luks-encrypted SSD with F23 Workstation x86_64.

Comment 7 Alex 2015-12-30 01:52:50 UTC
I experience similar problem.
Upgraded from Fedora 21 to 22 through # dnf upgrade, I cannot find buttons "Suspend to RAM" and "Hibernate to disk" anymore when I want to turn it off.
Both commands via CLI seem working, but it finds out that only # pm-suspend really accomplishes what it is expected to do, whereas # pm-hibernate shuts down the machine without saving anything.
Very strange, I used them in Fedora 21 without any hassle or glitch, ever!

Comment 8 AlbinLOtterhaell 2016-01-28 22:04:47 UTC
This is the bug report for F22, but the solution works for F23. Same problem.

Bug 1206936

Comment 9 Jan Chaloupka 2016-02-06 21:03:52 UTC
Confirming the issue is still occurring on the fresh F23. The solution works.

ISO downloaded just today: Fedora-Live-Workstation-x86_64-23-10.iso

Comment 10 AlbinLOtterhaell 2016-02-09 05:45:33 UTC
Apparently the fix doesn't work for me any longer. My laptop reboots or wakes up from hibernation at random after manual hibernation. My F23 installation is about a month old, and the fix worked in the beginning.

Comment 11 Brian Lane 2016-02-10 00:28:59 UTC
Anaconda needs to add the resume cmdline argument when the system is installed.

Comment 12 Neil 2016-02-14 23:11:21 UTC
Another confirmation of the simple (but user unfriendly) fix working on an FC23 clean install.

Does the 'Version' on this bug need to be updated for it to be considered for FC24?


Related: the installer automatically gave me an 8GB swap but I have 16GB RAM, if it intends swap to be used for hibernate then it needs to be at least as big as the RAM.

Comment 13 David Shea 2016-02-22 18:05:51 UTC
*** Bug 1310416 has been marked as a duplicate of this bug. ***

Comment 14 Mike McCune 2016-03-28 22:15:42 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions

Comment 15 David Shea 2016-03-31 18:41:01 UTC
On further consideration, we don't see why anaconda should need to add resume=, since it didn't have to in the past. Anaconda adds the appropriate dracut paramters (rd.lvm.*, rd.luks) to activate swap in the initramfs, and in F21 this was enough to resume from a variety of swap devices.

Comment 16 Harald Hoyer 2016-04-14 14:53:05 UTC
(In reply to David Shea from comment #15)
> On further consideration, we don't see why anaconda should need to add
> resume=, since it didn't have to in the past. Anaconda adds the appropriate
> dracut paramters (rd.lvm.*, rd.luks) to activate swap in the initramfs, and
> in F21 this was enough to resume from a variety of swap devices.

dracut should not hardcode the resume device in the initramfs, because, if the disk configuration changes, the admin cannot change the contents of the initramfs upon booting.

On the other hand, dracut really needs specific information about the resume device, because it has to make sure, that _nothing_ is mounted or changed on disk, in case the resume device is found and has the "suspend|swsuspend|swsupend" filesystem signature.

Therefore _something_ has to add the "resume=" parameter to the kernel command line.

And this should be initially anaconda.

And it should only do that, if the swap device is _not_ on any assembled device, because assembling something usually means, that it changes some metadata, which would result in inconsistent state after resuming the old kernel state.

Please reconsider.

Comment 17 David Shea 2016-04-14 17:08:57 UTC
Are you saying that resume from hibernate can only happen from standard, unencrypted partitions? That's ridiculous. About 90% of the reason that swap is included in the set of partitions to encrypt, and 100% of the reason it is encrypted with a passphrase instead of a random boot-time key, is so that it can be used for hibernate. If assembling the volume is going to change the partition in a way that it can not be used for hibernate, dracut should recognize that and refuse to use the resume volume. Or, more likely, the kernel will realize during the thaw and handle it.

This also ignores the point that all of this was working fine two releases ago.

Comment 18 Harald Hoyer 2016-04-21 12:08:49 UTC
(In reply to David Shea from comment #17)
> Are you saying that resume from hibernate can only happen from standard,
> unencrypted partitions? That's ridiculous. About 90% of the reason that swap
> is included in the set of partitions to encrypt, and 100% of the reason it
> is encrypted with a passphrase instead of a random boot-time key, is so that
> it can be used for hibernate. If assembling the volume is going to change
> the partition in a way that it can not be used for hibernate, dracut should
> recognize that and refuse to use the resume volume. Or, more likely, the
> kernel will realize during the thaw and handle it.
> 
> This also ignores the point that all of this was working fine two releases
> ago.

Yeah, luks/dm-crypt does not change metadata on disk IIRC, so it should be safe to use.

Comment 19 David Shea 2016-04-29 17:10:11 UTC
*** Bug 1206936 has been marked as a duplicate of this bug. ***

Comment 20 James Hogarth 2016-04-29 17:16:35 UTC

*** This bug has been marked as a duplicate of bug 1206936 ***


Note You need to log in before you can comment on or make changes to this bug.