(In reply to edoubrayrie from comment #0)
> * during installation I used the automatic partition mode with the "free
> some space" option to shrink the windows partition, and it did *not* create
> a swap partition (I don't see one in  `fdisk -l` nor `mount`). IMO hibernate
> should still work without swap (at least it does not complain about it)
> 
How it is supposed to work without swap? Could you provide the output of:
# swapon -s

> * there is no resume=... in the grub line. Not sure if there should be one:
IMHO the resume keyword is not needed. The resume from the hibernation should be managed by dracut/udev (if there is correct hibernation image written in the swap).

We need to sort out whether the hibernation image is written. Could you also provide output of the following two commands (after unsuccessful resume from the hibernation):
# journalctl -b -1
# journalctl -b

> I would love to investigate further, but the generic scripts behind
> pm-hibernate (if that is what is used by the gui button) are a bit
> offputting... what backend is used ? tuxonice ? uswsusp ? systemd (my guess
> goes for systemd as the only one installed).
> `export PM_DEBUG="true" ; pm-suspend-hybrid` did not say anything about
> what/where it was writing.
> 
The suspend/hibernate is by default handled by systemd in Fedora. E.g:
# systemctl hibernate

Or you can also try the lowest level, the kernel way:
# echo disk > /sys/power/state

Does it change anything?

Created attachment 1008472 [details]
Current boot journalctl

Created attachment 1008473 [details]
previous boot journalctl -b -1

Relevant output from the journal:

=========================================================================
Mar 30 13:44:00 ncex2490.amaiisdom NetworkManager[910]: <info>  sleep requested (sleeping: no  enabled: yes)
Mar 30 13:44:00 ncex2490.amaiisdom NetworkManager[910]: <info>  sleeping...
[...]
Mar 30 13:44:00 ncex2490.amaiisdom NetworkManager[910]: <info>  NetworkManager state is now ASLEEP
[...]
Mar 30 13:44:00 ncex2490.amaiisdom dbus[790]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Mar 30 13:44:00 ncex2490.amaiisdom systemd[1]: Starting Network Manager Script Dispatcher Service...
Mar 30 13:44:00 ncex2490.amaiisdom systemd[1]: Reached target Sleep.
Mar 30 13:44:00 ncex2490.amaiisdom systemd[1]: Starting Sleep.
Mar 30 13:44:00 ncex2490.amaiisdom systemd[1]: Starting Hibernate...
Mar 30 13:44:00 ncex2490.amaiisdom systemd-sleep[2424]: Suspending system...
Mar 30 13:44:00 ncex2490.amaiisdom kernel: PM: Hibernation mode set to 'platform'
-- Reboot --
Mar 30 14:44:41 ncex2490.amaiisdom systemd-journal[135]: Runtime journal is using 8.0M (max allowed 394.5M, trying to leave 591.7M free of 3.8G available → current limit 394.5M).
[...]
Mar 30 14:44:43 ncex2490.amaiisdom dracut-initqueue[315]: Scanning devices sda6  for LVM logical volumes fedora/swap fedora/root
Mar 30 14:44:43 ncex2490.amaiisdom dracut-initqueue[315]: inactive '/dev/fedora/swap' [7.75 GiB] inherit
Mar 30 14:44:43 ncex2490.amaiisdom dracut-initqueue[315]: inactive '/dev/fedora/home' [118.41 GiB] inherit
Mar 30 14:44:43 ncex2490.amaiisdom dracut-initqueue[315]: inactive '/dev/fedora/root' [50.00 GiB] inherit
Mar 30 14:44:43 ncex2490.amaiisdom systemd[1]: Found device /dev/mapper/fedora-root.
Mar 30 14:44:43 ncex2490.amaiisdom systemd[1]: Started dracut initqueue hook.
Mar 30 14:44:43 ncex2490.amaiisdom unknown[1]: <audit-1130> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=dracut-initqueue comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 30 14:44:43 ncex2490.amaiisdom systemd[1]: Starting Remote File Systems (Pre).
Mar 30 14:44:43 ncex2490.amaiisdom systemd[1]: Reached target Remote File Systems.
Mar 30 14:44:43 ncex2490.amaiisdom systemd[1]: Starting Remote File Systems.
Mar 30 14:44:43 ncex2490.amaiisdom systemd[1]: Started dracut pre-mount hook.
Mar 30 14:46:11 ncex2490.amaiisdom systemd[1]: Job fedora-swap.device/start timed out.
Mar 30 14:46:11 ncex2490.amaiisdom systemd[1]: Timed out waiting for device fedora-swap.device.
Mar 30 14:46:11 ncex2490.amaiisdom systemd[1]: Dependency failed for Resume from hibernation using device /fedora/swap.
Mar 30 14:46:11 ncex2490.amaiisdom systemd[1]: Job systemd-hibernate-resume/start failed with result 'dependen
cy'.
=========================================================================

So, the issue is definitely linked to the no-swap issue... which also makes the boot last 2 minutes. Questions

1) if the hibernate succeeds without swap, should the dependency should actually exist ?

2) What is the issue with the swap ?
Apparently, the filesystem does exist (I don't know enough about LVM and swap mounting to say more):

======
$ sudo pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda6
  VG Name               fedora
  PV Size               176.16 GiB / not usable 3.00 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              45097
  Free PE               1
  Allocated PE          45096
  PV UUID               4I1QUy-OWCf-UfC3-mVhO-4F6s-nYWL-LGLkYC
   
$ sudo lvdisplay
  --- Logical volume ---
  LV Path                /dev/fedora/swap
  LV Name                swap
  VG Name                fedora
  LV UUID                PRIQMQ-15dI-16Nq-EA0a-deIW-pkMg-M011NM
  LV Write Access        read/write
  LV Creation host, time ncex2490.amaiisdom, 2015-03-28 09:51:51 +0000
  LV Status              available
  # open                 2
  LV Size                7.75 GiB
  Current LE             1984
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

  --- Logical volume ---
  LV Path                /dev/fedora/home
  LV Name                home
  VG Name                fedora
  LV UUID                Zb8Ems-CHTi-9i1X-5VSB-AAKJ-iitO-u2hqeQ
  LV Write Access        read/write
  LV Creation host, time ncex2490.amaiisdom, 2015-03-28 09:51:51 +0000
  LV Status              available
  # open                 1
  LV Size                118.41 GiB
  Current LE             30312
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:2

  --- Logical volume ---
  LV Path                /dev/fedora/root
  LV Name                root
  VG Name                fedora
  LV UUID                vG3fU9-jW0h-z1BS-ZH1A-fT7t-eV0K-IhSWGx
  LV Write Access        read/write
  LV Creation host, time ncex2490.amaiisdom, 2015-03-28 09:51:52 +0000
  LV Status              available
  # open                 1
  LV Size                50.00 GiB
  Current LE             12800
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1
=======================================================================

Could you provide output of:
# swapon -s

$ swapon -s
Filename                                Type            Size    Used    Priority
/dev/dm-0                               partition       8126460 0       -1

(In reply to edoubrayrie from comment #6)
> $ swapon -s
> Filename                                Type            Size    Used   
> Priority
> /dev/dm-0                               partition       8126460 0       -1

So, your system uses swap and that's why hibernation passed. I think that adding "resume" to your grub config may help with the resume. But IIRC this should be handled automatically by dracut, thus reassigning.

There is definitely an issue with the swap service not terminating correctly : maybe it does mount the swap, but it clearly fails to report so, and systemd waits 90 seconds for it (an eternity for a boot from SSD these days).

So, for me, this should go first to the maintainers of this service (whoever that is ?).

what is the output of:

# dracut --print-cmdline

??

$ sudo dracut --print-cmdline
 rd.lvm.lv=fedora/root
 rd.lvm.lv=fedora/swap
 resume=/dev/mapper/fedora-swap root=/dev/mapper/fedora-root rootflags=rw,relatime,seclabel,data=ordered rootfstype=ext4

Why does this not match what I see on grub kernel line ?

IIUC, this include the right resume=..., so the problem is with the swap service ?

More investigation:

* fstab contains this:
/dev/mapper/fedora-swap swap                    swap    defaults        0 0

* according to man systemd.special, IIUC "systemd-fstab-generator" ends up creating the dev-mapper-fedora\x2dswap.swap as a dependency of swap.device

* /usr/lib/systemd/system/systemd-hibernate-resume@.service says it is "After=%i.device" with %i ending up being swap I guess.

* Where it gets tricky is that systemd waits for swap.service and ends up saying:
Mar 30 14:46:11 ncex2490.amaiisdom systemd[1]: Job fedora-swap.device/start timed out.
Mar 30 14:46:11 ncex2490.amaiisdom systemd[1]: Timed out waiting for device fedora-swap.device.
Mar 30 14:46:11 ncex2490.amaiisdom systemd[1]: Dependency failed for Resume from hibernation using device /fedora/swap.

... but then reports everything is fine when asked about it:

$ systemctl list-units | grep swap
dev-mapper-fedora\x2dswap.swap    loaded active active    /dev/mapper/fedora-swap
swap.target                       loaded active active    Swap

$ systemctl status dev-mapper-fedora\x2dswap.swap swap.device
● dev-mapper-fedorax2dswap.swap - /dev/mapper/fedorax2dswap
   Loaded: loaded
   Active: inactive (dead)
     What: /dev/mapper/fedorax2dswap
● swap.device
   Loaded: loaded
   Active: inactive (dead)

The only thing I see amiss here is the name of the service: swap.device vs fedora-swap.device.

Hence I'd really like to know what systemd guys think of this ?

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

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

(In reply to edoubrayrie from comment #10)
> $ sudo dracut --print-cmdline
>  rd.lvm.lv=fedora/root
>  rd.lvm.lv=fedora/swap
>  resume=/dev/mapper/fedora-swap root=/dev/mapper/fedora-root
> rootflags=rw,relatime,seclabel,data=ordered rootfstype=ext4
> 
> Why does this not match what I see on grub kernel line ?
> 
> IIUC, this include the right resume=..., so the problem is with the swap
> service ?

Can you add resume=/dev/mapper/fedora-swap  to the kernel command line in grub?

I made it work at some point with the workaround described in the duplicate:

GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root resume=/dev/dm-0"

I suffer from the same problem. How do I try the fix, which file do I enter what in?

(In reply to A. Folger from comment #16)
> I suffer from the same problem. How do I try the fix, which file do I enter
> what in?

At first you need to find out where your swap is located by:
# swapon -s

Note the /dev..., e.g. /dev/dm-0

Then add it to GRUB_CMDLINE_LINUX in /etc/default/grub, e.g. add the following (replace /dev/dm-0 with your path):

GRUB_CMDLINE_LINUX="resume=/dev/dm-0"

Regenerate your grub.cfg by, on non-UEFI system:

# grub2-mkconfig -o /etc/grub2.cfg

on UEFI system:

# grub2-mkconfig -o /etc/grub2-efi.cfg

You may also need to add rd.lvm.lv to GRUB_CMDLINE_LINUX if LVM is not correctly detected by dracut. In such case check the LVM by:
# lvscan

And add each path (without the /dev/) as "rd.lvm.lv=PATH" to GRUB_CMDLINE_LINUX. You may end with something similar to configuration in comment 15.

OK, I tried this a number of times, tweaking the parameters (or rather, trying to), but got nowhere. Could it be because I use encrypted swap and home partitions (luks)? How do I do this properly, or how do I diagnose why the above solution fails for me?

Please add "systemd.log_level=debug" (without quotes) to the kernel command line, then reproduce the issue and attach the input of "journalctl -b" to this bugzilla.

@Jan Synacek, you mean adding it to GRUB_CMDLINE_LINUX?

You can do that directly from grub. Press 'e' on the entry you wish to boot, then navigate to the line that starts with "linux" and append "systemd.log_level=debug" to the end of that line.

Created attachment 1061537 [details]
Output of `journalctl -b` after wakeup from hibernation problem persists

Attached is the output from `journalctl -b > file.stdout`

This is after I changed GRUB_CMDLINE_LINUX in my /etc/default/grub to the following:

GRUB_CMDLINE_LINUX="rhgb quiet rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/projects rd.lvm.lv=fedora/home resume=/dev/dm-5 system.log_level=debug"
.

Do note that I did not forget to run `grub2-mkconfig -o /etc/grub2-efi.cfg`.

What now?

I also have an encrypted LVM and it works fine for me ( i.e hibernate and resume works) by adding resume=/dev/dm-1 to the cmdline

Can you post what does swapon -s output?

or

As a workaround you can try resume=/dev/mapper/fedora-swap

So, I just tried hibernating and restoring from hibernate, but again, it simply rebooted.

Here is some output as per Sohny Thomas' request:

# swapon -s
Filename                                Type            Size    Used    Priority
/dev/dm-3                               partition       8333308 0       -1

As to your other suggestion, to use resume=/dev/mapper/fedora-swap, well, that was indeed the key! I had resume=/dev/dm-5 in the GRUB_CMDLINE_LINUX in /etc/default/grub, however,as can be seen in the output I posted in my previous reply, /dev/maper/fedora-swap is actually linked to dm-3 and not dm-5. After fixing that, hibernate once again works.

THANK YOU!

I had the same problem, but works now thanks to the fix suggested. I'm running on a Fedora 22 system with LVM and full-disk encryption.

# swapon --show
NAME      TYPE      SIZE USED PRIO
/dev/dm-2 partition 7.7G   0B   -1

$ lvscan
ACTIVE            '/dev/fedora_laptop-0/swap' [7.69 GiB] inherit
ACTIVE            '/dev/fedora_laptop-0/home' [165.39 GiB] inherit
ACTIVE            '/dev/fedora_laptop-0/root' [50.00 GiB] inherit

So I added the following text-snippet to the end of GRUB_CMDLINE_LINUX in "/etc/default/grub":

resume=/dev/dm-2

so it now reads

GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora_laptop-0/root rd.luks.uuid=luks-33547c11-4905-4fac-8d0e-7cb37a20e0cc rd.lvm.lv=fedora_laptop-0/swap rhgb quiet resume=/dev/dm-2"

I'm observing this behaviour on Fedora 23 x86_64 on my laptop so updating the release to match. 

Also the assignee was left with dracut maintainers even through the component was changed.

Note that dracut --print-cmdline showed resume=/dev/mapper/luks-fe.... however resume would never work and /proc/cmdline did not line up with this.

Upon adding resume=/dev/mapper/luks-fe... to the grub kernel args myself testing hibernate and resume works correctly so it looks like either:

1) The systemd hibernate generator happens before dracut could initialise provide the cmdline like that
2) The cmdline doesn't really get modified like dracuut implies
3) The cmdline gets modified by dracut in a way the systemd hibernation generator doesn't pick up.

Note that I've trivially reproduced this in an F24 VM - and it works in a consistent manner so updating to F24 for the release version.

I'll get logs here in a moment - this is a default F24 workstation install in the VM.

On a failed hibernate/resume:
[root@localhost ~]# dracut --print-cmdline
 rd.lvm.lv=fedora/swap 
 rd.lvm.lv=fedora/root 
 resume=/dev/mapper/fedora-swap root=/dev/mapper/fedora-root rootfstype=ext4 rootflags=rw,relatime,seclabel,data=ordered
[root@localhost ~]# cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-4.5.0-302.fc24.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet LANG=en_GB.UTF-8 systemd.log_level=debug

On a working hibernate/resume:
[root@localhost ~]# dracut --print-cmdline
 rd.lvm.lv=fedora/swap 
 rd.lvm.lv=fedora/root 
 resume=/dev/mapper/fedora-swap root=/dev/mapper/fedora-root rootfstype=ext4 rootflags=rw,relatime,seclabel,data=ordered
[root@localhost ~]# cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-4.5.0-302.fc24.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet LANG=en_GB.UTF-8 systemd.log_level=debug resume=/dev/mapper/fedora-swap

Created attachment 1146651 [details]
log of normal boot with systemd debug level

Created attachment 1146652 [details]
log of failed hibernate boot with systemd debug level

Created attachment 1146653 [details]
log of successful hibernate boot with systemd debug level

Proposed as a Blocker for 24-final by Fedora user jhogarth using the blocker tracking app because:

 Although this has been broken for multiple releases now it's only more recently been apparent why.

This appears to fail "Default application functionality" as the ability to hibernate is entirely broken on all installs at present.

Hibernation is commonly required in laptop scenarios and indeed the default power management on critical battery is to HybridSleep which  will attempt to hibernate, and since hibernate fails if anything is open and not saved it will be lost rather than recovered on resume as expected.

This bug was always reproduced!No matter Fedora 23 or 24.

Discussed at today's blocker review meeting [1]. Voted as punt (delay decision) - we're inclined to reject this as we explicitly don't cover hibernation in the criteria and have always considered it too unreliable to block release, but we will delay the decision for a week for more discussion and input from all parties

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-04-18

After discussion with the Fedora Gnome team it appears that the config of /etc/Upower/Upower.conf applies and that upower notifies logind that it wants $action to happen (default being HybridSleep on Fedora at present) which presumably logind passes to systemd to execute as appropriate.

The gsettings and power UI in gnome is purely about the idle behaviour and the call to upower to carry out the critical action is by design to avoid the battery reaching a totally drained state.

Upower itself notifies logind of what the critical action that has been defined is, as mentioned the default we ship is HybridSleep, and then systemd acts on this (see man systemd-sleep).

With regards to the "we explicitly don't cover hibernation in the criteria and have always considered it too unreliable to block release" side of things, note this is not a firmware/hardware/driver issue that has an edge case causing a failed resume from hibernate. This is all Fedora Workstation (I've not checked Server as generally those systems will have less in the way of power issues compared to laptops running workstation) installations on a default configuration with no changes to power management.

To replicate this in a VM to demonstrate the hardware agnostic side of things:

1) Install Fedora 24 Workstation
2) systemctl hibernate
3) Power back up VM - notice the fresh login
4) Look up swap partition device mapper target: swapon -s (default in fedora would be /dev/mapper/fedora-swap)
5) grubby -args=resume=/path/to/swap --update-kernel=$(grubby --default-kernel) 
6) Reboot
7) Login to VM
8) systemctl hibernate
9) Power back up VM - notice the resumed session

The low battery notification explicitly states it will hibernate so $user would not be expecting to lose data if not saved and the system shutdown. 

The hibernate actually successfully happens.

The generator doesn't see resume= so it never triggers the attempt to load the hibernation image.

So based on this I'd strongly suggest it fails the criteria "Default application functionality" given the currently shipped packages. In principle we could avoid this with upower changing the default to shutdown rather than hybridsleep but then the user would be confused on how to enable hibernation on low batter since /etc/Upower/Upower.conf explicitly states it is not for user configuration.

I'd suggest to a lesser extent the "Data corruption" also being impacted due to the loss of data should a user not save work and expect hibernation to happen as prompted in the notification.

I have posted on systemd-devel@ to get feedback on if the generator may be improved to not need resume= at all.

Depending on the feedback there it could remain with systemd and a fixed generator, or anaconda should add the resume= argument for the configured swap on install as it already has to for things like the root partition. I'm not sure how we can could deal with existing installs in that situation other than document on CommonBugs (done) and expect users to fix systems they want to hibernate on.

Okay passing back the feedback from the systemd-devel@ list  ...

They just rely on the kernel suspend-to-disk support framework and don't do anything special outside of this.

The kernel documentation explicitly states to use resume= on the kernel command line which is why it triggers off of this:

https://www.kernel.org/doc/Documentation/power/swsusp.txt

Trying to parse fstab and attempt to poke swap partitions (if more than one exist) will be fragile at best and potentially crash worthy at worst.

On a GPT system it wouldn't be such a problem as a GPT type could be used to identify the hibernate target to resume from, this doesn't help in MBR world though.

As such it would appear systemd is not the appropriate target for this bug and given the kernel documentation the correct answer is to add resume= to point to the swap created at install, so anaconda.

There is an alternative way to handle the blocker condition of this bug and that's to have upower have the critical action point to shutdown, rather than hybridsleep. At least the user would be notified of a shutdown event occurring, rather than a hibernate event, and the implication to save now asap ready for a shutdown would be seen.

That would take care of the "default application behaviour" or potential "data loss" criteria, it would still leave a non-working resume for anyone that did systemctl hibernate or added the gnome-shell extension to expose hibernate.

Changing the assignment to anaconda as that would appear, from the discussion in #fedora-desktop, systemd-devel@ and the kernel docs, to be the correct place to fix the underlying issue.

(In reply to James Hogarth from comment #36)
> There is an alternative way to handle the blocker condition of this bug and
> that's to have upower have the critical action point to shutdown, rather
> than hybridsleep. At least the user would be notified of a shutdown event
> occurring, rather than a hibernate event, and the implication to save now
> asap ready for a shutdown would be seen.

This is obviously not an option.

(In reply to Jóhann B. Guðmundsson from comment #37)
> (In reply to James Hogarth from comment #36)
> > There is an alternative way to handle the blocker condition of this bug and
> > that's to have upower have the critical action point to shutdown, rather
> > than hybridsleep. At least the user would be notified of a shutdown event
> > occurring, rather than a hibernate event, and the implication to save now
> > asap ready for a shutdown would be seen.
> 
> This is obviously not an option.

Naturally I'd strongly disagree with such an approach, but it is potentially something that might be discussed amongst the fedora-qa team so thought it worth highlighting now.

But indeed fixing the root issue would be the best way forward I have no doubt.

(In reply to James Hogarth from comment #38)
> (In reply to Jóhann B. Guðmundsson from comment #37)
> > (In reply to James Hogarth from comment #36)
> > > There is an alternative way to handle the blocker condition of this bug and
> > > that's to have upower have the critical action point to shutdown, rather
> > > than hybridsleep. At least the user would be notified of a shutdown event
> > > occurring, rather than a hibernate event, and the implication to save now
> > > asap ready for a shutdown would be seen.
> > 
> > This is obviously not an option.
> 
> Naturally I'd strongly disagree with such an approach, but it is potentially
> something that might be discussed amongst the fedora-qa team so thought it
> worth highlighting now.

If the change you proposed should be made it needs to be implemented only by the workstation product or what you proposed to have been ensured that it works on all the other desktop environment as well since there are other desktop environment and sub community involved in Fedora not just Red Hat and it's "products"

Then there is the issue with hibernation on system with UEFI Secure Boot enabled which does not work unless the images are signed and as far as I know the generic mechanism to deal with that has not yet been implemented in the kernel.

On top of that it's getting more and more common that people with ssd and enough ram either have swap completely disabled and or are just mounting the swap partition just before they hibernate.

In the end of the day this not a release blocking bug and never has been due to the reason Kamil explains in comment 34.

> One top of that...

those conditions you mentioned should already be handled by systemd (ie, if sufficient swap is not available, hibernation won't be offered as being available either).

(In reply to Rex Dieter from comment #40)
> > One top of that...
> 
> those conditions you mentioned should already be handled by systemd (ie, if
> sufficient swap is not available, hibernation won't be offered as being
> available either).

I would think the DE is what offers what is and is not available and those DE'( GNOME,LXDE,KDE,XFCE etc ) may or may not query systemd for that information ( via CanHibernate() bus call or even check if secure boot is enabled or not and not offer it if it is ), They can even fallback differently if it's not available or to small or simply not fallback at all and as far as I know there is no built in functionality to mount swap partition before they hibernate in systemd so users are alternating or implementing the relevant service to achieve that.

> I would think the DE is what offers

Right, I was talking about logind's CanHibernate specifically.  (and mounting swap for the sole purpose of supporting hibernate is a use-case outside the scope of this bug)

No it's not that intelligent on the DE side ...

It is slightly more intelligent on the systemd side but not to the extent the user will be notified if hibernate is possible or not.

So there's two effective issues here as I see it - one which is potentially final blocking due to the two criteria outlined above:

1) upower has a critical action config that is not possible on any fedora system at present and gives the illusion of data being safe at critical battery levels

2) hibernate is broken on fedora due to missing resume= in /etc/default/grub (well the kernel command line which is semi-related to the config file) 

......

1) This can be solved, and avoid the criteria outlined above, by being defaulted to shutdown (not hibernate or hybridsleep) on critical battery levels. This is the issue I'd consider final release blocking based on the above.

2) Can /etc/default/grub (and the related kernel arguments) be fixed via an update after release? If not then I'd argue it'd be release blocking with anaconda needing to fix, if not then I'd argue it wouldn't be release blocking.

(In reply to James Hogarth from comment #43)
> 1) This can be solved, and avoid the criteria outlined above, by being
> defaulted to shutdown (not hibernate or hybridsleep) on critical battery
> levels. This is the issue I'd consider final release blocking based on the
> above.

Again this is not an option unless you intend to break end user setup who upgrades. 

> 2) Can /etc/default/grub (and the related kernel arguments) be fixed via an
> update after release? If not then I'd argue it'd be release blocking with
> anaconda needing to fix, if not then I'd argue it wouldn't be release
> blocking.

Even if this got fixed ( anaconda adds the resume= line ) hybernation will not work reliably if secure boot is enabled and any PC sold with a Windows 8 logo sticker on it ( sold in ca since Q1/2013 ) has secure boot enabled by default do they not.

The above is probably the reason why the Anaconda team never added ( or they remove that functionality in what F18/F19 timeframe ) that line in the first place since the installer will need to check if secure boot is enabled and if it's enabled not add that line. 

That said Hypernation should not be part of or fall under any release blocking criteria since it cannot be reliably implemented nor is there infrastructure to do so and you cannot block the release of the distribution over something that the distribution has no control over ( upstream ) or resources to fix themselves downstream.

I must be misunderstanding you her as the below isn't making sense to me.

(In reply to Jóhann B. Guðmundsson from comment #44)
> (In reply to James Hogarth from comment #43)
> > 1) This can be solved, and avoid the criteria outlined above, by being
> > defaulted to shutdown (not hibernate or hybridsleep) on critical battery
> > levels. This is the issue I'd consider final release blocking based on the
> > above.
> 
> Again this is not an option unless you intend to break end user setup who
> upgrades. 
> 

How is this breaking upgrades? 

It already does not work. The effect as it stands today for any Fedora user on any product/spin is that upon reaching a critical battery threshold hibernate gets called and if it's permitted (no SB, enough swap available, etc) completes successfully, if not permitted shutdown happens.

With that as successful suspend-to-disk already having happened on start of the system the hibernation image is never seen due to the missing resume= ... The system then effectively starts as if the power cord had been pulled, albeit with a sync first but no processes were sent TERM to carry out any cleanup tasks, data sync etc before this.

By changing from the present default to shutdown processes get sent a TERM and the users know they will lose anything not saved, rather than being notified a hibernate is about to happen that can never resume.

According to /etc/Upower/Upower.conf users are not meant to edit that file anyway despite the ℅config status with a sane critical level being chosen for the  distribution.

Again please explain how this is breaking a user who upgrades given the present situation with resume= ?

> > 2) Can /etc/default/grub (and the related kernel arguments) be fixed via an
> > update after release? If not then I'd argue it'd be release blocking with
> > anaconda needing to fix, if not then I'd argue it wouldn't be release
> > blocking.
> 
> Even if this got fixed ( anaconda adds the resume= line ) hybernation will
> not work reliably if secure boot is enabled and any PC sold with a Windows 8
> logo sticker on it ( sold in ca since Q1/2013 ) has secure boot enabled by
> default do they not.
> 
> The above is probably the reason why the Anaconda team never added ( or they
> remove that functionality in what F18/F19 timeframe ) that line in the first
> place since the installer will need to check if secure boot is enabled and
> if it's enabled not add that line. 
> 

If SB is enabled (and I've encountered more that disable it than leave it) then the kernel forbids a power management change to suspend-to-disk. Try it and see if you have a SB laptop. As such the resume image will never be written to the swap partition in the first place. 

In that scenario shutdown at critical already happens, no change from altering the upower or grub config.

Adding resume= has no affect on SB users and their experience of Fedora.


> That said Hypernation should not be part of or fall under any release
> blocking criteria since it cannot be reliably implemented nor is there
> infrastructure to do so and you cannot block the release of the distribution
> over something that the distribution has no control over ( upstream ) or
> resources to fix themselves downstream.


Normally I'd agree with you about hibernation and the Fedora QA release criteria when it's "X hardware doesn't work" but as I explained above this is outside of that particular issue. This is trivially reproducible on a default workstation install in a KVM instance. This issue is completely hardware agnostic. I'm not sure where you're going with your last statement as we block releases all the time due to bug X in a critical package which affects the default configuration, particularly where user data risk is concerned. 

If the Fedora Project were to decide "we don't want to support hibernation" then fine, we should patch suspend-to-disk out of the kernel and/or prevent systemd from initiating it. But until such time as that happens (and I'll point out here that with a correct grub config it works more often than it doesn't and would be extremely disappointed at such a FESCO decision) we should at least have defaults that don't expressly tell the user a hibernation event is about to happen, and then promptly throw away the image without ever attempting a resume from it.

If a hibernation image exists, it should be resumed. While resume= doesn't guarantee hibernation will work, the lack of resume= guarantees it won't work.

resume= doesn't belong in the initramfs, which should be as generic as possible; and in particular can't work with either --no-hostonly or --reproducible initramfs's.

resume= can't reliably be determined by systemd except on GPT with a new partition type GUID or an attribute setting. This discovery would be nice 

Therefore resume= needs to go in /etc/default/grub; it hurts nothing if it's there.

Whether the lack of resume= by default is release blocking is something of a judgment call. In the present situation it probably is more strongly argued that it is, if the default behavior of any release blocking desktop makes hibernation default or easily discoverable to enable (one time or persistently). I'd argue they shouldn't, but if they are, and hibernation images are created, there needs to be a good faith attempt to resume.

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

All the investigation and discussion had been here.

Let's mark the other duplicate of this so the recent history can be properly followed.

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

Yeah this bug is proposed as a blocker and shouldn't be closed at least until that's resolved.

I need to better qualify c46 due to this comment by Harold on the systemd-devel list:

"To resume from a swap disk means, that you must not change any data on disk
while doing so, because that change would go unnoticed by the kernel, which we
want to resume. So basically assembling raid or LVM, which changes metadata on
disk is a no go."
https://lists.freedesktop.org/archives/systemd-devel/2016-April/036320.html

That means anaconda would actually need to do some logic:
plain partition = OK
dmcrypt = OK
LVM = not OK
mdadm raid = not OK

to conditionally add resume= to /etc/default/grub. And that's because resuming always may actually cause more problems than it solves. And I think asking for such a change is more like an RFE rather than fixing a bug.

(In reply to Chris Murphy from comment #51)
> I need to better qualify c46 due to this comment by Harold on the
> systemd-devel list:
> 
> "To resume from a swap disk means, that you must not change any data on disk
> while doing so, because that change would go unnoticed by the kernel, which
> we
> want to resume. So basically assembling raid or LVM, which changes metadata
> on
> disk is a no go."
> https://lists.freedesktop.org/archives/systemd-devel/2016-April/036320.html
> 
> That means anaconda would actually need to do some logic:
> plain partition = OK
> dmcrypt = OK
> LVM = not OK
> mdadm raid = not OK
> 
> to conditionally add resume= to /etc/default/grub. And that's because
> resuming always may actually cause more problems than it solves. And I think
> asking for such a change is more like an RFE rather than fixing a bug.

Based on testing this bug I'm not convinced he's correct entirely, and indeed in the dupe 1224151#c18 he mentions that assembling LUKS/lvm does not cause a change that would be bad. I'd expect that mdadm raid would be fine too - following the sane caveat that you don't change hardware etc on suspend/resume which you should always follow.

The test case I described and followed in c35 to demonstrate the hardware agnostic issue in a VM (which is why I believe this matches the blocker criteria unlike usual hibernate issues) uses a default workstation install, which is swap on lvm.

As for RAID? How many laptops (which is what this bug is primarily concerned with given the default critical battery level behaviour) have RAID? Will be interesting to test and quick to do so at least.

Anaconda guys, what's the hesitation with having resume= in grub just like we do the other disk directives needed for boot? Especially in light of the kernel docs and the systemd-devel@ discussion?

Just tested F24 and the install definitely has swap on lvm, which works with the resume= pointed to the devmapper target

At any case I'd argue that those conditions would be a) out of scope of this bug which is focused on the laptop lack of resume on successful hibernate case and b) not anaconda's problem.

If it is an issue then a separate systemd bug should be added to improve the tests before telling the kernel to suspend-to-disk.

Let's avoid the scope creep and keep to the core issue here of resume= missing meaning no attempt to resume from a successful hibernate at all, and if we don't want to have a hibernation event in Fedora potentially require upower to have a critical action of shutdown instead of hybridsleep/hibernate.

(In reply to James Hogarth from comment #52)

> Based on testing this bug I'm not convinced he's correct entirely, and
> indeed in the dupe 1224151#c18 he mentions that assembling LUKS/lvm does not
> cause a change that would be bad.

No he says luks/dmcrypt. That's different than LVM.

I do not think this bug can be a blocker against anaconda without appealing to mdadm and LVM folks about whether on-disk metadata changes happen during assembly prior to hibernation resumption. Only then do we know if resume= is unconditionally safe to add in all cases; or if Anaconda would be saddled with a test to make sure only supportable configurations get resume= and if so it's up to anaconda folks to say whether such a change is acceptable and maintainable.

(In reply to Chris Murphy from comment #54)
> (In reply to James Hogarth from comment #52)
> 
> > Based on testing this bug I'm not convinced he's correct entirely, and
> > indeed in the dupe 1224151#c18 he mentions that assembling LUKS/lvm does not
> > cause a change that would be bad.
> 
> No he says luks/dmcrypt. That's different than LVM.
> 
> I do not think this bug can be a blocker against anaconda without appealing
> to mdadm and LVM folks about whether on-disk metadata changes happen during
> assembly prior to hibernation resumption. Only then do we know if resume= is
> unconditionally safe to add in all cases; or if Anaconda would be saddled
> with a test to make sure only supportable configurations get resume= and if
> so it's up to anaconda folks to say whether such a change is acceptable and
> maintainable.

Well LVM swap works fine for hibernation in my testing. And having resume= there is certainly no worse than the present case of discarding data.

To get the info you want we'd need this pointed at the kernel maintainers. If we start pointing and asking info from every maintainer that could possibly have any information this is going to go nowhere.

Frankly if that's the route you'd want to go down I'd rather go the route of requiring upower to change the critical battery action to shutdown which would satisfy the blocker criteria, rather than an indefinite pointing of fingers at each other which would be the wrong thing to have on a final blocker.

Discussed at the 2016-05-02 blocker review meeting.

This is a worrying issue, but we do not find that it violates the release criteria, which have always been held specifically not to cover hibernation, thus it is rejected as a release blocker.

Following the discussion in the QA blocker meeting bug logged against Upower to have a configuration that does not notify the user of a hibernation event, and then promptly discards any data.

Once this resume issue is rectified then such a change in Upower could be reverted.

(In reply to Jóhann B. Guðmundsson from comment #39)
[...]
> Then there is the issue with hibernation on system with UEFI Secure Boot
> enabled which does not work unless the images are signed and as far as I
> know the generic mechanism to deal with that has not yet been implemented in
> the kernel.
> 

You still need to drop:

"hibernate: Disable in a signed modules environment"
https://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/hibernate-Disable-in-a-signed-modules-environment.patch

whether "the images are signed" or not, so S4 can start to work, again.

"mechanism to deal with that" exists, although not yet in the mainline - Bug 1330335
"Support for generating and verifying the signature of a hibernate image"

systemd-229-8.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-5f8a34340d

So it seems that systemd will understand the resume option now, but how it will get to my kernel command line?

Systemd always understood that.

This bug was erroneously referred to in the bodhi submission.

This remains with anaconda for the time being and still exists as per the F24 common bugs entry.

systemd-229-8.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-5f8a34340d

Fixing status as, as mentioned in c61, the bodhi submission got the wrong bugid.

Hi,

I am having same problem on XPS 13 9350 (dev edition).

In F24 Beta resume/suspends was workign correctly, now each time I close the lid it doesn't resume (notice I am not hibernating).

Anyway I tried the workaround mentioned here, but still not working.

My systemd version is: Version     : 229 Release     : 8.fc24

More info,

It does works when power plug is in (suspend/resume) but it fails to resume if I suspend the laptop while on battery.

It is Fedora default to hibernate when on battery?

(In reply to JAlberto from comment #65)
> It does works when power plug is in (suspend/resume) but it fails to resume
> if I suspend the laptop while on battery.

I think you need to open a new bug for this problem and include logs. After the reboot from the failed resume, you should include the current boot: 'journalctl -b' and also the previous boot 'journalctl -b-1' as attachments.

 > It is Fedora default to hibernate when on battery?

In Fedora 24 the default is to poweroff when battery goes critical. This is because by default nothing properly configures the kernel command line to include resume= hint for the hibernation image location. If resume= is manually added to /etc/default/grub and a new grub.cfg is written out, then systemd will pick this up and report hibernation is supported to the DE, assuming you have enough swap space.

Also note that the XPS 13 by default has UEFI secure boot enabled, and the Fedora kernel does not support hibernation when secure boot is enabled because it's an attack vector until we get encrypted hibernation image support.

I am surprised because the guys at openSUSE got it right, somehow. I had the same setting : LVM + Dmcrypt for the swap + secure boot, and its worked flawlessly.

On Fedora 24, after a fresh install, I cannot get it to work, even after editing grub properly.

Maybe now the issue is with systemd:

% systemctl hibernate     
Failed to hibernate system via logind: Sleep verb not supported

FWIW, 

I am running Fedora 24 (latest everything):

Dell released BIOS 1.4.4 for the XPS 13" 2016 last month, and once I updated the isssue with laptop rebooted when unplugged from hibernation went away.

More info on how to install it at: https://wiki.archlinux.org/index.php/Dell_XPS_13_(2016)#BIOS_updates

(In reply to Jaroslav Škarvada from comment #17)
> (In reply to A. Folger from comment #16)
> > I suffer from the same problem. How do I try the fix, which file do I enter
> > what in?
> 
> At first you need to find out where your swap is located by:
> # swapon -s
> 
> Note the /dev..., e.g. /dev/dm-0
> 
> Then add it to GRUB_CMDLINE_LINUX in /etc/default/grub, e.g. add the
> following (replace /dev/dm-0 with your path):
> 
> GRUB_CMDLINE_LINUX="resume=/dev/dm-0"
> 
> Regenerate your grub.cfg by, on non-UEFI system:
> 
> # grub2-mkconfig -o /etc/grub2.cfg
> 
> on UEFI system:
> 
> # grub2-mkconfig -o /etc/grub2-efi.cfg
> 
> You may also need to add rd.lvm.lv to GRUB_CMDLINE_LINUX if LVM is not
> correctly detected by dracut. In such case check the LVM by:
> # lvscan
> 
> And add each path (without the /dev/) as "rd.lvm.lv=PATH" to
> GRUB_CMDLINE_LINUX. You may end with something similar to configuration in
> comment 15.

Running Fedora 24, an upgrade of previous Fedora 23 installation from Fedora Live.

That gave me a BIOS boot with Grub2. (I had a hard time to find out THAT!)

Than the regeneration of grub.cfg was correctly

     sudo grub2-mkconfig -o /boot/grub2/grub.cfg

That deviates from comment 17. It is also a bit different from the work around at the bottom of https://fedoraproject.org/wiki/Common_F24_bugs#Hibernation_doesn.27t_work_from_a_standard_install page, where the nonexisting /boot/grub/grub.cfg is still used! 

THE ABOVE IS A DOCUMETATION ERROR THAT COULD BE CORRECTED EASILY!

I also used Gnome Tweak Tool before it worked.

         Power -> When Power Button is Pressed -> Hybernate

I wonder why that option is in the tweak tool because it's in the power section of Gnome settings.

This started to happen to me recently (within last 3-4 days) as well when just suspending. If I close my laptop for a few minutes and open up, no problems, if I close it overnight though and open, it looks like it is trying to recover from the suspend but then after about a minute it reboots. My settings do not specify any hibernation after 30 minutes (or similar), still set to suspend but maybe there is some sort of pseudo hibernation if in suspend after 30 minutes.

Happy to provide any diagnostic info, just let me know what. I am running a Dell Precision 7510

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

Not sure if this concerns the same area or is a separate bug (let me know if so):
Using Fedora 24 I keep the kernel up-to-date, hd uses dm-crypt, hibernation uses swap partition within it, resume is correctly set as part of the kernel parameters.

kernel 4.7.2-201 works flawless resuming from hibernation
kernel 4.7.3-200 had the "KASLR disabled" message (see bug 1350174), resume worked seldom
kernel 4.7.4-200 never resumes successfully anymore, always rebooting after discarding the resume file and booting up normally

Hardware is a Braswell based laptop that works flawless otherwise.

Update to my previous post, with the new kernel 4.7.5-200 resuming appears to work smoothly again so far.

I don't have any issues either after 4.7.5-200

I updated to kernel 4.7.5-200 and it made a new startup boot instead of resumes from hibernation this morning.

Happened to me as well after some time without issues. Went back to 4.7.2-201 for the time being as that is still resuming flawlessly.

From the beginning the new kernel 4.7.6-200 failed to resume correctly, so still sticking with 4.7.2-201.

Please don't comment on every resume failure here. There are 100 different causes for resume failures. This bug is about one single issue, which is a missing resume= kernel argument after a default install. Everything else should be reported separately. Thanks.

Alright sorry for the hassle, it's why I asked, seeing all related bugs being closed. Moved on to bug 1380957 "resume from hibernate randomly fails (silent reboot)".

Why is this still a problem in F25?

Anaconda should either try to pick correct partition and add resume parameter automatically or user should be somehow notified. Why not add some notification during installation like "to enable hibernation, you need to create swap partition of min. size x and ..."? Or maybe add checkbox during swap partition creation "use this swap partition for hibernation" - then anaconda would know what add to default grub config.

Having to find solution on Google and add resume to grub config manually is bad for user experience.

(In reply to Jaroslav Škarvada from comment #17)
> (In reply to A. Folger from comment #16)
> > I suffer from the same problem. How do I try the fix, which file do I enter
> > what in?
> 
> At first you need to find out where your swap is located by:
> # swapon -s
> 
> Note the /dev..., e.g. /dev/dm-0
> 
> Then add it to GRUB_CMDLINE_LINUX in /etc/default/grub, e.g. add the
> following (replace /dev/dm-0 with your path):
> 
> GRUB_CMDLINE_LINUX="resume=/dev/dm-0"
> 
> Regenerate your grub.cfg by, on non-UEFI system:
> 
> # grub2-mkconfig -o /etc/grub2.cfg
> 
> on UEFI system:
> 
> # grub2-mkconfig -o /etc/grub2-efi.cfg
> 
> You may also need to add rd.lvm.lv to GRUB_CMDLINE_LINUX if LVM is not
> correctly detected by dracut. In such case check the LVM by:
> # lvscan
> 
> And add each path (without the /dev/) as "rd.lvm.lv=PATH" to
> GRUB_CMDLINE_LINUX. You may end with something similar to configuration in
> comment 15.

Awesome thank you for this, this fixed my hibernation issue in Fedora. My GRUB_CMDLINE_LINUX looks like this:

GRUB_CMDLINE_LINUX="resume=/dev/dm-1 rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet"

my Swap partition is only 4 Gigabytes.

thanks for sharing.

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

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

Fixed in a pull request: https://github.com/rhinstaller/anaconda/pull/1360

Thanks, Vendula! \o/

Did this make the F28 release? I see anaconda-28.22.10-1.fc28.x86_64.rpm, and 28.23.1 > 28.22.10

(In reply to Matthew Miller from comment #86)
> Did this make the F28 release? I see anaconda-28.22.10-1.fc28.x86_64.rpm,
> and 28.23.1 > 28.22.10

The Anaconda side changes are definitely long in place in 28.22.10:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1075135

In the changelog entry:
* Mon Mar 05 2018 Martin Kolman <mkolman> - 28.22.2-1

There is:
- Add the kernel option resume= by default (#1206936) (vponcova)

Soooo this bug should probably be closed, not just "modified", right?

I quickly tested this and while anaconda adds the correct kernel argument, this still seems broken somewhere down the line (dracut?). I haven't had much time to test this, will try to do that next week. We can close this bug if you prefer, since the required feature has been implemented in anaconda, and we can then open up a new bug if this turns out to be still broken due to something else.

Thanks for testing Kamil. I'm closing this bug now.

Created attachment 1430626 [details]
Hibernation tests

I have tested various combinations of set-ups (see attachment) and I can confirm that hibernation worked without any problems on a freshly installed Fedora 28. It not only worked out-of-the-box, but I could also use different methods of addressing the swap partition and it worked anyway.

(In reply to Lukas Ruzicka from comment #91)
> Created attachment 1430626 [details]
> Hibernation tests
> 
> I have tested various combinations of set-ups (see attachment) and I can
> confirm that hibernation worked without any problems on a freshly installed
> Fedora 28. It not only worked out-of-the-box, but I could also use different
> methods of addressing the swap partition and it worked anyway.

What hardware did you test this on? I've been trying to get hibernate working on a fresh Fedora 28 install on a thinkpad x1 carbon 6th gen with no luck for a few days -- more info about my failed attempts at https://ask.fedoraproject.org/en/question/120359/fedora28-hibernate-problem/

I think hibernate is actually pretty much working now for me also except that my gvim windows seem to be lost when I resume. My terminal and firefox windows are intact though, so I imagine it's probably a separate issue.

Thanks to everyone who pitched in to get hibernate working!

Fedora 28: It is important to remake the initramfs (via mkinitrd command) AFTER setting up a swap space of the proper size. Before recreating it, resume would just ignore the suspend signature on the partition

I am still seeing this on Fedora 27 with the changes to the kernel command line to resume from swap partition.  So it might need to be reopened.

Here's my /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=fedora/root rd.lvm.lv=fedora/00 rhgb quiet resume=/dev/mapper/fedora-00"
GRUB_DISABLE_RECOVERY="true"

and I set log level of systemd to debug by sending it a RTMIN+22:
kill -s 56 1
got 56 by adding 22 to RTMIN from 'kill -l'

I then hibernated the system and rebooted and added systemd log level kernel command line param:
systemd.log_level=debug

The system did not boot properly for some reason and just hung.  It also seems to have messed up the clock (if you notice its off by exactly 5:30 hours which is my timezone diff with GMT).  I booted it again without log level set to debug and it booted but could not find swap image in /dev/mapper/fedora-00.  I can't find a way to attach logs so I haven't attached this journalctl log but I can send it if you tell me how.

Here's the journalctl log that shows that log level was set to debug:
===============================================================================
Jun 18 15:53:09 localhost.localdomain systemd[1]: Setting log level to debug.
Jun 18 15:53:34 localhost.localdomain systemd[1]: systemd-udevd.service: Got notification message from PID 572 (WATCHDOG=1)
Jun 18 15:54:34 localhost.localdomain systemd[1]: systemd-journald.service: Got notification message from PID 542 (WATCHDOG=1)
Jun 18 15:54:34 localhost.localdomain systemd[1]: systemd-logind.service: Got notification message from PID 805 (WATCHDOG=1)
Jun 18 15:55:34 localhost.localdomain systemd[1]: systemd-journald.service: Got notification message from PID 542 (WATCHDOG=1)
Jun 18 15:55:34 localhost.localdomain systemd[1]: systemd-udevd.service: Got notification message from PID 572 (WATCHDOG=1)
Jun 18 15:55:36 localhost.localdomain smartd[722]: Device: /dev/sdb [SAT], 1 Currently unreadable (pending) sectors
Jun 18 15:55:36 localhost.localdomain smartd[722]: Device: /dev/sdb [SAT], 1 Offline uncorrectable sectors
Jun 18 15:55:43 localhost.localdomain systemd[1]: systemd-logind.service: Got notification message from PID 805 (WATCHDOG=1)
Jun 18 15:55:43 localhost.localdomain NetworkManager[815]: <info>  [1529317543.2559] manager: sleep requested (sleeping: no  enabled: yes)
Jun 18 15:55:43 localhost.localdomain NetworkManager[815]: <info>  [1529317543.2713] manager: sleeping...
Jun 18 15:55:43 localhost.localdomain NetworkManager[815]: <info>  [1529317543.3217] manager: NetworkManager state is now ASLEEP
Jun 18 15:55:43 localhost.localdomain systemd[1]: SELinux access check scon=system_u:system_r:systemd_logind_t:s0 tcon=system_u:object_r:power_unit_file_t:s0 tclass=service perm=start path=/usr/lib/systemd/system/hibernate.target cmdline=/usr/lib/systemd/systemd-logind: 0
Jun 18 15:55:44 localhost.localdomain systemd[1]: SELinux access check scon=system_u:system_r:systemd_logind_t:s0 tcon=system_u:object_r:power_unit_file_t:s0 tclass=service perm=start path=/usr/lib/systemd/system/hibernate.target cmdline=/usr/lib/systemd/systemd-logind: 0
Jun 18 15:55:44 localhost.localdomain systemd[1]: hibernate.target: Trying to enqueue job hibernate.target/start/replace-irreversibly
Jun 18 15:55:44 localhost.localdomain systemd[1]: sleep.target: Installed new job sleep.target/start as 1969
Jun 18 15:55:44 localhost.localdomain systemd[1]: hibernate.target: Installed new job hibernate.target/start as 1967
Jun 18 15:55:44 localhost.localdomain systemd[1]: systemd-hibernate.service: Installed new job systemd-hibernate.service/start as 1968
Jun 18 15:55:44 localhost.localdomain systemd[1]: hibernate.target: Enqueued job hibernate.target/start as 1967
Jun 18 15:55:44 localhost.localdomain systemd[1]: sleep.target changed dead -> active
Jun 18 15:55:44 localhost.localdomain systemd[1]: sleep.target: Job sleep.target/start finished, result=done
Jun 18 15:55:44 localhost.localdomain systemd[1]: Reached target Sleep.
Jun 18 15:55:44 localhost.localdomain systemd[1]: systemd-hibernate.service: Passing 0 fds to service
Jun 18 15:55:44 localhost.localdomain systemd[1]: systemd-hibernate.service: About to execute: /usr/lib/systemd/systemd-sleep hibernate
Jun 18 15:55:44 localhost.localdomain systemd[1]: systemd-hibernate.service: Forked /usr/lib/systemd/systemd-sleep as 7863
Jun 18 15:55:44 localhost.localdomain systemd[1]: systemd-hibernate.service: Changed dead -> start
Jun 18 15:55:44 localhost.localdomain systemd[1]: Starting Hibernate...
Jun 18 15:55:44 localhost.localdomain systemd[7863]: systemd-hibernate.service: Executing: /usr/lib/systemd/systemd-sleep hibernate
Jun 18 15:55:44 localhost.localdomain systemd[1]: systemd-journald.service: Got notification message from PID 542 (FDSTORE=1)
Jun 18 15:55:44 localhost.localdomain systemd[1]: systemd-journald.service: Added fd 86 (n/a) to fd store.
Jun 18 15:55:44 localhost.localdomain kernel: PM: hibernation entry
Jun 18 15:55:44 localhost.localdomain kernel: PM: Syncing filesystems ... 
Jun 18 15:55:44 localhost.localdomain systemd-sleep[7863]: Suspending system...
===============================================================================

(In reply to asrivaths from comment #95)

[root@localhost asrivaths]# swapon -s
Filename				Type		Size	Used	Priority
/dev/dm-1                              	partition	4194300	0	-2

and a portion of the journal log from after reboot:

Jun 18 23:03:27 localhost.localdomain dracut-initqueue[307]: inactive '/dev/fedora-server/swap' [<3.03 GiB] inherit
Jun 18 23:03:27 localhost.localdomain systemd[1]: Found device /dev/mapper/fedora-root.
Jun 18 23:03:27 localhost.localdomain systemd[1]: Reached target Initrd Root Device.
Jun 18 23:03:28 localhost.localdomain systemd[1]: Found device /dev/mapper/fedora-00.
Jun 18 23:03:28 localhost.localdomain systemd[1]: Starting Resume from hibernation using device /dev/mapper/fedora-00...
Jun 18 23:03:28 localhost.localdomain systemd-hibernate-resume[432]: Could not resume from '/dev/mapper/fedora-00' (253:1).
Jun 18 23:03:28 localhost.localdomain kernel: PM: Starting manual resume from disk
Jun 18 23:03:28 localhost.localdomain kernel: PM: Image not found (code -22)
J

(In reply to asrivaths from comment #95)
> I am still seeing this on Fedora 27 with the changes to the kernel command
> line to resume from swap partition.  So it might need to be reopened.

This bug is about missing resume= option. New F28 installations now get it (upgrades don't). If you've added it manually and it doesn't work, then it's a different bug.

With the migration to F29, the default suspend (from the hardware key) seems to be some kind of hybrid suspend where after 3 hours sleep your PC will boot annd go back to hibernate. And I did not find how to change this (new systemd default? logind.conf is not modified on my system).

... and my resume= setting got lost somewhere in the various upgrades
... and the correct setting for me is now resume=/dev/mapper/vg01-swap_1

Not trying to reopen, but it may help someone searching for Fedora 29 hybrid suspend resume or something ;-)