Bug 1224151

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.

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.

(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

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

Present also in Fedora 23.

I think this bug should be rawhide.

Same here: luks-encrypted SSD with F23 Workstation x86_64.

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!

This is the bug report for F22, but the solution works for F23. Same problem.

Bug 1206936

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

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.

Anaconda needs to add the resume cmdline argument when the system is installed.

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.

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

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

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.

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

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.

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

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

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