----- Original Message -----
Hi,
On Thu, Sep 13, 2018 at 1:21 PM, Matthias Clasen mclasen@redhat.com wrote:
On Thu, Sep 13, 2018 at 1:10 PM Justin Forbes jmforbes@linuxtx.org wrote:
The thing is, hibernate does work for some users. And eventually will be made to work with secure boot as well. But it is very difficult for us to "support" a feature when the fixes are often blacklist x driver or edit your DSDT table. There is a large variety of hardware and some of it just doesn't work.
Well, everything worked for somebody at some point. But the answer can't be to just add another toggle to the control-center so people can experimentally find out if it works for them at this time, choose-your-own-adventure style.
Either we commit to supporting it. Then we need to invest the time to make it actually work. At the minimum, we need to be able to detect reliably when it will not work, so we can turn it off.
Or we don't. In which case we should just remove it.
Right, the kernel should stop advertising "disk" in /sys/power/state unless it can reliably hibernate. If users want to opt-in to some hibernate tech-preview, they should have to add something to the kernel command line or so, imo.
The kernel shouldn't be exposing features it can't reliably provide. Again, as I understand it, it's not even a hardware-supported situation, it can potentially fail on *any system* if the swap partition is filled up the wrong way, if i'm not mistaken.
There's multiple levels of "support". The kernel doesn't know if it has enough swap, this is checked by user-space, systemd in this case. Any additional checks we'd want to make would probably be implemented in systemd, so it can answer "CanHibernate" with a better degree of certainty.
until, at least that is fixed, we really should stop exposing the feature without some sort of kernel command line opt-in situation.
I think that the kernel doesn't have enough information about the system to be able to make the decision in a lot of cases, or it would cross subsystem boundaries. For example, knowing if Secure Boot is enabled, whether there's data encryption enabled, whether grub is correctly setup.
Having more checks in systemd might help. As for when the hardware drivers need fixing, well, it's the same situation as for any other driver bug would be, and hopefully fixed.