Description of problem: Hibernating and resuming usually works. But sometimes, when resuming, after I enter the main password for my luks-encrypted disk, the computer silently reboots (so I get back to grub, re-enter the password for the luks-encrypted disk, and get into a fresh boot of F24; hibernated image is lost). This happens randomly (typically I get one bad resume if I try hibernating and resuming five times in a row). Version-Release number of selected component (if applicable): dracut 20.fc24 (but I am not sure this is a problem with dracut) How reproducible: On my computer (a Dell E6320), quite reproducible: I hibernate and resume a few times, until this happens. Steps to Reproduce: 1. Hibernate 2. Resume 3. If resume works, go back to step 1. Actual results: Silent reboot Expected results: Resume from suspended state Additional info: This happens when I hibernate with "systemctl hibernate" or with "echo disk >/sys/power/state". Also I have tried passing the systemd.log_level=debug option when resuming, but it seems that the failed resume does not produce any output at all in the syslog. I will be happy to provide more info but am not sure what, since I could not obtain any debug info.
I would like to add that hibernation on this computer worked 100% reliably with F24 using kernel versions up to 4.6.7 (included). This bug report is about a problem which occurs only with later kernels. If it can be useful to obtain more info, I can easily temporarily downgrade the kernel version for testing purposes.
On second thought, reassigning component to kernel since the problem appeared when kernel was updated from 4.6.7-300 to 4.7.2-201.
I'm seeing similar behavior after kernel updates. I've been tracking it as part of bug 1206936 where it was misplaced. This is my experience with the recent kernel versions: kernel 4.7.2-201 works flawless resuming from hibernation kernel 4.7.3-200 resume worked seldom kernel 4.7.4-200 never resumes successfully, always rebooting after discarding the resume file and booting up normally kernel 4.7.5-200 worked for some time, the never worked again kernel 4.7.6-200 never resumes I keep running 4.7.2-201 as that still runs flawlessly on my fully supported Braswell laptop.
kernel 4.7.7-200 shows similar symptoms to 4.7.5-200 (i.e. I was able to use it for a couple resumes until it failed for inexplicable reasons). Accordingly still sticking with 4.7.2-201.
It looks like that vanilla kernel 4.8.4 works fine with Debian 8. Can confirm that vanilla kernel 4.7.2 works flawless. Debian kernel images 4.7.5 / 4.7.8 show same symptoms as kernel 4.7.5-200.
Thanks for the comparison. Now that it's in Fedora as well I can confirm 4.8.4-200 appears to work fine here too.