Re: Disabling kernel's hibernate support by default, allow re-enabling it with a kernel cmdline option

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 02, 2018 at 12:16:02PM -0400, Bastien Nocera wrote:
> 
> 
> ----- Original Message -----
> > On Di, 02.10.18 10:16, Bastien Nocera (bnocera@xxxxxxxxxx) wrote:
> > 
> > > Until the kernel can use a dedicated partition for hibernation, which
> > > would fix the majority of problems users can encounter, we're just
> > > offering more sharp edges with which to cut themselves.
> > 
> > As I understand the problems have more to do with hardware
> > combinations, and driver code not getting things right, the actual
> > serialization of stuff is fine and unproblematic...

This is mixing two things — userspace configuration and autodetection,
and kernel driver issues. The first is an easy problem (relatively), the
second is much harder.

Specifically:

> There's problems with:
> - not having enough swap space available at a particular instant
as you know, systemd looks at the current memory usage, and does not
advertise hibernation when not enough memory. So users might be
unhappy that hibernation sometimes stops being available, but otherwise
this is not a problem.

There's some heuristics here. I haven't seen reports where hibernation
would fail because systemd misdetected the amount of memory, but if you
see this, please report, and we'll try to adjust.

> - swap being encrypted and not allowing restore because the keys aren't
>   there anymore
This particular case is not detected, but we certainly should do this.
I'll put it on the todo list.

> - swap not being encrypted, which could leak information down the line
But that case also affect normal usage: if I have physical access to the
machine, I can just press reset, and after reboot extract anything from
swap. Hibernation doesn't change much here.

> - resume= not being there in the default parameters, so dracut needing
>   to rewrite the initrd before hibernation is considered done (?)
This is also solvable. Pull request [1] is upstream to check for resume=
presence, and I plan to backport this to F29.

[1] https://github.com/systemd/systemd/pull/10262

> If the drivers being broken were the only problem, then reporting bugs upstream
> for those drivers would help, just in the same way it helped for suspend
> 10 years ago.
> 
> In my experience, the problem isn't so much with specific drivers, and
> more with the whole infrastructure, whether in the kernel, user-space,
> or a combination of both.
Yes, hibernation gets a lot of flak for non-kernel issues, like those
listed above. But those we can actually fix relatively easy.

Zbyszek
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-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/kernel@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [USB]     [Asterisk PBX]

  Powered by Linux