OK so I've run into this also on Fedora 28. (This is with the "sick" battery that Windows says is OK, and HP's battery checker says is OK. And yet at 18% battery and 45 minutes remaining it goes into "hibernation"). So what Fedora is doing is hybrid sleep. Jun 02 15:11:33 f28h.local systemd[1]: Starting Hybrid Suspend+Hibernate... It is really super easy to be less than precise with language when it comes to power management, it's really complicated mostly because the various strategies keep changing by hardware manufacturers and Microsoft. So pretty much just accept that the only people who really grok this are the very serious amateurs, and devs whose expertise this is. And I'm neither, so you can take this with a grain of salt. My understanding of hybrid sleep, is that the kernel will freeze the memory state, write that image to the drive, and then go to suspend-to-RAM (S3) mode. That way if you add power, you can immediately wake up and the written hibernation image can just be ignored. But if you don't add power, and the battery goes below a certain point that suspend collapses into poweroff, the system state is in the hibernation image. The gotcha, at least for my system, is this should not happen because it's UEFI with Secure Boot enabled. I asked the kernel team fairly recently (about a year) and hibernation is not supported. A non-encrypted hibernation image is an injection point to side step the protection offered by Secure Boot. SUSE has a patch to do this, but we aren't using it, and mainline hasn't accepted any of that including a bunch of other Secure Boot related stuff - last I checked. So... bugger. And I'm experiencing the same effect where it immediately wakes up after it suspends following the writing of the hibernation image. But a non-hybrid suspend to RAM with laptop lid, or pressing power button quickly, or holding alt while clicking on the GNOME upper right hand menu power button (which with alt key has a pause symbol instead), all of those work. As for what checks logind does to know whether it can hibernate, it looks like RAM must not be more than 98% of swap. DE's that use Hibernate() bus call when RAM is bigger than free swap (that is, swap could be used for swap and for hibernation image, but typically you hope swap is little used or not used at all; but if a lot is used it can mean Hibernate() fails because there isn't enough room for swap and the hibernate image to be written in the available swap space and that's why to really support hibernation, we need these rather substantially larger swap partitions than we have now, just in case swap is used for swap - haha, get it?) Anyway, if the DE calls Hibernate() and it fails due to lack of space, it's up to the DE to decide what to fallback on. And I haven't tested any of that. So I don't know what happens. There is also CanHibernate() which just does a check, rather than an attempt. https://lists.freedesktop.org/archives/systemd-devel/2016-April/036330.html Anyway, there's a bug here I think. The unprompted write from suspend following the writing of the hibernation image is one bug. And the very fact the system is trying to hibernate sounds like another unless we now support hibernation - which quite frankly would surprise me a lot. Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx/message/MQZO6DIANNLGML4GO43UDC3XHDXEJEI6/
