Disabling kernel's hibernate support by default, allow re-enabling it with a kernel cmdline option
Hello Fedora kernel team,
On the Fedora desktop list there has been a discussion about systemd now offering a new suspend-then-hibernate option and gnome-settings-daemon's media-keys plugin using this when the power-button gets pressed and systemd saying this is available on the system.
What this does is suspend the system normally and set a RTC wakeup 3 hours in the future, then when the RTC wake happens it hibernates the system.
As discussed on the desktop list this is not really desirable as default behavior for F29 (and later) since the hibernate code is not really something which gets used enough to be well tested and is really not something which we can support.
So after that the discussion has gone in the direction of how to disable the new suspend-then-hibernate behavior.
Lennart made a really interesting observation here, systemd is just proxying if "cat /sys/power/disk" indicates that hibernate is supported.
So if we really don't want to support hibernation as a normal option, while still allowing adventurous user to use it, what really should happen is for the kernel to stop advertising hibernate support. Thinking about this I agree, if we say that we cannot support it, the kernel really should not be advertising support for it by default.
So Bastien suggested to change the nohibernate setting in kernel/power/hibernate.c which can be set from the kernel commandline to default to 1, and allow setting it back to 0 by adding "hibernate=yes" to the kernel commandline.
I kinda like this idea and I'm willing to spend some time to write a patch for this and submit it upstream, which allows selecting nohibernate=1 as the default through Kconfig.
But before I spend (some) time on this, I wonder what the kernel team's opinion on this is ?
My own 2 cents on this are:
Pro:
Not advertising hibernate by default means users will not accidentally try to use it (through e.g gnome-tweaks) and if they do use it by specifying the kernel commandline option we can easily explain that using that commandline option is not supported by Fedora and kindly request them to file bugs upstream. TL;DR: less kernel issues for Fedora to deal with, good.
Against:
Currently we do have some users using hibernation without adding any options to the kernel commandline. These users will have to now add "hibernate=yes" to their kernel commandline.
I'm thinking that yes we want this, but maybe this needs to go through the change process for proper communication, so for F29 we need another fix, and we can do this for F30?
Regards,
Hans
On Sun, Sep 30, 2018 at 1:52 PM, Hans de Goede hdegoede@redhat.com wrote:
Hello Fedora kernel team,
On the Fedora desktop list there has been a discussion about systemd now offering a new suspend-then-hibernate option and gnome-settings-daemon's media-keys plugin using this when the power-button gets pressed and systemd saying this is available on the system.
What this does is suspend the system normally and set a RTC wakeup 3 hours in the future, then when the RTC wake happens it hibernates the system.
As discussed on the desktop list this is not really desirable as default behavior for F29 (and later) since the hibernate code is not really something which gets used enough to be well tested and is really not something which we can support.
So after that the discussion has gone in the direction of how to disable the new suspend-then-hibernate behavior.
Lennart made a really interesting observation here, systemd is just proxying if "cat /sys/power/disk" indicates that hibernate is supported.
No, that is not what systemd is doing. The kernel provides a mechanism, it does absolutely nothing with that mechanism unless told to do so. What systemd is actually doing is creating a policy around that mechanism.
So if we really don't want to support hibernation as a normal option, while still allowing adventurous user to use it, what really should happen is for the kernel to stop advertising hibernate support. Thinking about this I agree, if we say that we cannot support it, the kernel really should not be advertising support for it by default.
"We have decided that the policy created is not desirable, so we want to disable the mechanism"
So Bastien suggested to change the nohibernate setting in kernel/power/hibernate.c which can be set from the kernel commandline to default to 1, and allow setting it back to 0 by adding "hibernate=yes" to the kernel commandline.
I kinda like this idea and I'm willing to spend some time to write a patch for this and submit it upstream, which allows selecting nohibernate=1 as the default through Kconfig.
But before I spend (some) time on this, I wonder what the kernel team's opinion on this is ?
My own 2 cents on this are:
Pro:
Not advertising hibernate by default means users will not accidentally try to use it (through e.g gnome-tweaks) and if they do use it by specifying the kernel commandline option we can easily explain that using that commandline option is not supported by Fedora and kindly request them to file bugs upstream. TL;DR: less kernel issues for Fedora to deal with, good.
Against:
Currently we do have some users using hibernation without adding any options to the kernel commandline. These users will have to now add "hibernate=yes" to their kernel commandline.
I'm thinking that yes we want this, but maybe this needs to go through the change process for proper communication, so for F29 we need another fix, and we can do this for F30?
While this change would "solve" the problem, I do not believe it is the correct place to do so. As mentioned above, the mechanism is not flawed. Some hardware does not support the mechanism, and has no way of reporting as such, which is why policy has always been leave it off unless the user knowingly triggers it. Now we have changed the policy, in a way that seems pretty much universally undesirable, the solution is the revert the policy, not cripple the mechanism.
Justin
On Mo, 01.10.18 09:14, Justin Forbes (jmforbes@linuxtx.org) wrote:
Lennart made a really interesting observation here, systemd is just proxying if "cat /sys/power/disk" indicates that hibernate is supported.
No, that is not what systemd is doing. The kernel provides a mechanism, it does absolutely nothing with that mechanism unless told to do so. What systemd is actually doing is creating a policy around that mechanism.
Well, we do provide a way to disallow hibernation in systemd, that's not the point.
The thing though is: the hibernation subsystem in the Fedora kernel is in a relatively unique situation: it's enabled and installed on all installations by default, and adds a substantial, relatively invasive, non-trivial subsystem to the kernel — all while (as I understand) the Fedora kernel maintainers are not really willing to maintain it with the greatest love, and show no interest in turning this into a universally supported mechanism. Is there any other subsystem that is equally invasive which is enabled on all systems but where the maintainers are equally conservative in their will to support/fix it? I don't think so...
To compare this with other cases: usually code that the package maintainers don't want to maintain with the highest priority and greatest love is split into separate RPMs, and not installed by default. But in this case that's not really possible...
Also, while of course I personally think that people should use systemd's APIs to hibernate the system this is not really how the world works. There are plenty of howtos on the internet that suggest people to use the /sys interface directly to hibrenate the system from their scripts. And hence that's how people often do it. Turning off hibrenation in levels high up in the stack hence kinda is less than ideal, as all those scripts don't care a tiny bit about that if they use the API advertised by the kernel itself...
While this change would "solve" the problem, I do not believe it is the correct place to do so. As mentioned above, the mechanism is not flawed. Some hardware does not support the mechanism, and has no way of reporting as such, which is why policy has always been leave it off unless the user knowingly triggers it. Now we have changed the policy, in a way that seems pretty much universally undesirable, the solution is the revert the policy, not cripple the mechanism.
I think it would be wise to generally only enable and advertise features in the Fedora kernel that the kernel maintainers are actually willing to support. To me it appears this is generally followed in all cases, but in this case the kernel advertises that hibernation is available, even though it is known to be broken in plenty cases with noone actually caring about it.
Also: I am sure there's a lot of disagreement of what the responsibility of systemd is and what not, but I personally don't think it's our job to decide whether a specific kernel subsystem is high quality enough to override the kernel's own advertisement of it, or even to judge whether the Fedora kernel team's willingness to maintain said subsystem is big enough or not. I'd much rather if the kernel team would decide on their own, and advertise on their own what they think is good enough and supportable enough to be used by everybody.
Or to say this differently: own the thing or turn it off.
Lennart
On Mon, Oct 1, 2018 at 3:42 PM Lennart Poettering mzerqung@0pointer.de wrote:
On Mo, 01.10.18 09:14, Justin Forbes (jmforbes@linuxtx.org) wrote:
Lennart made a really interesting observation here, systemd is just proxying if "cat /sys/power/disk" indicates that hibernate is supported.
No, that is not what systemd is doing. The kernel provides a mechanism, it does absolutely nothing with that mechanism unless told to do so. What systemd is actually doing is creating a policy around that mechanism.
Well, we do provide a way to disallow hibernation in systemd, that's not the point.
The thing though is: the hibernation subsystem in the Fedora kernel is in a relatively unique situation: it's enabled and installed on all installations by default, and adds a substantial, relatively invasive, non-trivial subsystem to the kernel — all while (as I understand) the Fedora kernel maintainers are not really willing to maintain it with the greatest love, and show no interest in turning this into a universally supported mechanism. Is there any other subsystem that is equally invasive which is enabled on all systems but where the maintainers are equally conservative in their will to support/fix it? I don't think so...
I also don't think your statement above is fair or correct. Firstly the kernel is large, and the combination of hardware is vast and the kernel team comprises ~3 people. So it's not that they don't maintain, fix, engage with upstream to deal with problems it's just that is limited with the resources available, especially when the bug reports can be as vast as "feature X stopped working" without details of the hardware or anything useful. I've seen numerous occasions when something has regressed and there's useful report various hibernate related issues be fixed, it's just hard with the limited resources, both people's time and actual HW to test on, to be able to be sure the functionality is good in all usecases.
To compare this with other cases: usually code that the package maintainers don't want to maintain with the highest priority and greatest love is split into separate RPMs, and not installed by default. But in this case that's not really possible...
Yes, that might be the case for some distros, for enterprise distros the functionality might even be provided via a different repository that you need to explicitly have to enable. Unfortunately for a hibernation it's not really a feature that can be split into a kernel sub package called kernel-hibernation-if-you-install-it-and-it-breaks-you-keep-both-pieces with the appropriate blinking lights.
Also, while of course I personally think that people should use systemd's APIs to hibernate the system this is not really how the world works. There are plenty of howtos on the internet that suggest people to use the /sys interface directly to hibrenate the system from their scripts. And hence that's how people often do it. Turning off hibrenation in levels high up in the stack hence kinda is less than ideal, as all those scripts don't care a tiny bit about that if they use the API advertised by the kernel itself...
While this change would "solve" the problem, I do not believe it is the correct place to do so. As mentioned above, the mechanism is not flawed. Some hardware does not support the mechanism, and has no way of reporting as such, which is why policy has always been leave it off unless the user knowingly triggers it. Now we have changed the policy, in a way that seems pretty much universally undesirable, the solution is the revert the policy, not cripple the mechanism.
I think it would be wise to generally only enable and advertise features in the Fedora kernel that the kernel maintainers are actually willing to support. To me it appears this is generally followed in all cases, but in this case the kernel advertises that hibernation is available, even though it is known to be broken in plenty cases with noone actually caring about it.
Also: I am sure there's a lot of disagreement of what the responsibility of systemd is and what not, but I personally don't think it's our job to decide whether a specific kernel subsystem is high quality enough to override the kernel's own advertisement of it, or even to judge whether the Fedora kernel team's willingness to maintain said subsystem is big enough or not. I'd much rather if the kernel team would decide on their own, and advertise on their own what they think is good enough and supportable enough to be used by everybody.
Or to say this differently: own the thing or turn it off.
Lennart
-- Lennart Poettering, Red Hat _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org 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/desktop@lists.fedoraproject.or...
On Mo, 01.10.18 15:59, Peter Robinson (pbrobinson@gmail.com) wrote:
The thing though is: the hibernation subsystem in the Fedora kernel is in a relatively unique situation: it's enabled and installed on all installations by default, and adds a substantial, relatively invasive, non-trivial subsystem to the kernel — all while (as I understand) the Fedora kernel maintainers are not really willing to maintain it with the greatest love, and show no interest in turning this into a universally supported mechanism. Is there any other subsystem that is equally invasive which is enabled on all systems but where the maintainers are equally conservative in their will to support/fix it? I don't think so...
I also don't think your statement above is fair or correct. Firstly the kernel is large, and the combination of hardware is vast and the kernel team comprises ~3 people. So it's not that they don't maintain, fix, engage with upstream to deal with problems it's just that is limited with the resources available, especially when the bug reports can be as vast as "feature X stopped working" without details of the hardware or anything useful. I've seen numerous occasions when something has regressed and there's useful report various hibernate related issues be fixed, it's just hard with the limited resources, both people's time and actual HW to test on, to be able to be sure the functionality is good in all usecases.
Please don't misunderstand me on this. I am explicitly *not* criticizing the kernel people for not wanting to give hibernation their love. I don't expect them to, and as an upstream maintainer I know exactly how important it is to make choices on what you want and what you don't want to support. Hence: it's entirely fine by me if hibernation is considered not supportable. I am just saying given that things are the way they are I think it would be better to not advertise it to userspace as working. Because currently to the layers further up in the stack it looks like hibernation was perfectly well supported even though it apparently is not.
To compare this with other cases: usually code that the package maintainers don't want to maintain with the highest priority and greatest love is split into separate RPMs, and not installed by default. But in this case that's not really possible...
Yes, that might be the case for some distros, for enterprise distros the functionality might even be provided via a different repository that you need to explicitly have to enable. Unfortunately for a hibernation it's not really a feature that can be split into a kernel sub package called kernel-hibernation-if-you-install-it-and-it-breaks-you-keep-both-pieces with the appropriate blinking lights.
Yes, precisely, and the suggestion is to turn it off hence in the kernel in a way that allows people who understand the uncertainty around this subsystem to then enable it anyway if they like.
i.e. make this subsystem opt-in instead of opt-out, in the package that actually implements the subsystem (i.e. the kernel rpm), and under control of the people who made the decision not to support it with all their love (i.e. the kernel team).
I don't think systemd should be in the business of second-guessing the kernel team's choices on code quality and their desire to support code. Because if the kernel doesn't turn this subsystem off, then we have to…
Lennart
On Mon, Oct 1, 2018 at 10:14 AM, Lennart Poettering mzerqung@0pointer.de wrote:
On Mo, 01.10.18 15:59, Peter Robinson (pbrobinson@gmail.com) wrote:
The thing though is: the hibernation subsystem in the Fedora kernel is in a relatively unique situation: it's enabled and installed on all installations by default, and adds a substantial, relatively invasive, non-trivial subsystem to the kernel — all while (as I understand) the Fedora kernel maintainers are not really willing to maintain it with the greatest love, and show no interest in turning this into a universally supported mechanism. Is there any other subsystem that is equally invasive which is enabled on all systems but where the maintainers are equally conservative in their will to support/fix it? I don't think so...
I also don't think your statement above is fair or correct. Firstly the kernel is large, and the combination of hardware is vast and the kernel team comprises ~3 people. So it's not that they don't maintain, fix, engage with upstream to deal with problems it's just that is limited with the resources available, especially when the bug reports can be as vast as "feature X stopped working" without details of the hardware or anything useful. I've seen numerous occasions when something has regressed and there's useful report various hibernate related issues be fixed, it's just hard with the limited resources, both people's time and actual HW to test on, to be able to be sure the functionality is good in all usecases.
Please don't misunderstand me on this. I am explicitly *not* criticizing the kernel people for not wanting to give hibernation their love. I don't expect them to, and as an upstream maintainer I know exactly how important it is to make choices on what you want and what you don't want to support. Hence: it's entirely fine by me if hibernation is considered not supportable. I am just saying given that things are the way they are I think it would be better to not advertise it to userspace as working. Because currently to the layers further up in the stack it looks like hibernation was perfectly well supported even though it apparently is not.
If this were some new feature, I might agree with you, but hibernation has been in this state for literally a decade at this point. It seems odd to change policy around it after so long. It isn't just the code that has to change to support everything, it is system firmware which causes a lot of the issues, maintaining a massive blacklist is not worth the time or effort. Code issues in hibernation may not have the same priority kvm issues or graphics issues, but they aren't ignored either. Realistically we are dealing with legacy users here as new systems tend to support secure boot, which we enable by default, and disables hibernation already. Users falling outside of that category are either on legacy hardware, and why force them to change behavior, or advanced enough to turn off secure boot, and deal with said risks, in which case they could probably also make their own decisions on userspace hibernation policy and implement them if given a mechanism to do so.
To compare this with other cases: usually code that the package maintainers don't want to maintain with the highest priority and greatest love is split into separate RPMs, and not installed by default. But in this case that's not really possible...
Yes, that might be the case for some distros, for enterprise distros the functionality might even be provided via a different repository that you need to explicitly have to enable. Unfortunately for a hibernation it's not really a feature that can be split into a kernel sub package called kernel-hibernation-if-you-install-it-and-it-breaks-you-keep-both-pieces with the appropriate blinking lights.
Yes, precisely, and the suggestion is to turn it off hence in the kernel in a way that allows people who understand the uncertainty around this subsystem to then enable it anyway if they like.
i.e. make this subsystem opt-in instead of opt-out, in the package that actually implements the subsystem (i.e. the kernel rpm), and under control of the people who made the decision not to support it with all their love (i.e. the kernel team).
I don't think systemd should be in the business of second-guessing the kernel team's choices on code quality and their desire to support code. Because if the kernel doesn't turn this subsystem off, then we have to…
Again, the kernel is simply providing a mechanism, we did not create a policy around this (except in the case of secure boot where the mechanism breaks a trust policy). The kernel at no point has said you *should* use this, only that it is available. There are a lot of things that the kernel makes available which may or may not be useful in your specific case, and we don't put policy around it. One of the advantages of a community distro such as Fedora, is that we *can* enable features that aren't guaranteed to work, but the community can use if it suits them. This is something that cannot be done as easily on enterprise distributions with service contracts and SLAs. We have a lot of modules and subsystems with few users, or where they are not reliable on *all* hardware. If we turned them all off, it might reduce our bug count a bit, but it would also do the community a disservice.
I completely agree that hibernation should be opt-in instead of opt-out, but it should be done at the policy level, not the mechanism level. This is a policy decision. The policy level is not in the kernel.
Justin
Hi Justin,
On 01-10-18 16:14, Justin Forbes wrote:
On Sun, Sep 30, 2018 at 1:52 PM, Hans de Goede hdegoede@redhat.com wrote:
Hello Fedora kernel team,
On the Fedora desktop list there has been a discussion about systemd now offering a new suspend-then-hibernate option and gnome-settings-daemon's media-keys plugin using this when the power-button gets pressed and systemd saying this is available on the system.
What this does is suspend the system normally and set a RTC wakeup 3 hours in the future, then when the RTC wake happens it hibernates the system.
As discussed on the desktop list this is not really desirable as default behavior for F29 (and later) since the hibernate code is not really something which gets used enough to be well tested and is really not something which we can support.
So after that the discussion has gone in the direction of how to disable the new suspend-then-hibernate behavior.
Lennart made a really interesting observation here, systemd is just proxying if "cat /sys/power/disk" indicates that hibernate is supported.
No, that is not what systemd is doing. The kernel provides a mechanism, it does absolutely nothing with that mechanism unless told to do so. What systemd is actually doing is creating a policy around that mechanism.
systemd is really *not* creating policy here, it has a DBUS API call called CanHibernate which really just proxies what the kernel advertises.
What is new is that GNOME (g-s-d) now uses it be default through by choosing suspend-then-hibernate as suspend action when hibernation is available.
So if we really don't want to support hibernation as a normal option, while still allowing adventurous user to use it, what really should happen is for the kernel to stop advertising hibernate support. Thinking about this I agree, if we say that we cannot support it, the kernel really should not be advertising support for it by default.
"We have decided that the policy created is not desirable, so we want to disable the mechanism"
Default to off is a different thing then disabling this.
TBH I'm a bit surprised about your objections against this:
1) We all seem to agree that this is something which may or may not work, but is not something which we want to advertise as a "supported" Fedora feature
2) Given 1) we also all agree that we should not use it by default
3) If we should not use it by default then shouldn't the feature default to off ? That is all what is being suggested, basically the equivalent of adding "nohibernate" to the kernel commandline by default.
I expect the kernel changes for this to be about 3 lines of actual code (+a 15 lines or so Kconfig addition) and I expect this to go upstream without much issues as this seems like an entirely reasonable thing to do.
Reading further along the discussion you say that if this were a new feature you would likely agree to defaulting it to off. But since this has been there for years we should not change it ? That seems like a weak argument to me, we have always been doing this in a sub-optimal way so lets continue doing this in a sub-optimal way ?
I agree that we should not change it in the middle of a Fedora cycle. Hence I wrote:
Against:
Currently we do have some users using hibernation without adding any options to the kernel commandline. These users will have to now add "hibernate=yes" to their kernel commandline.
I'm thinking that yes we want this, but maybe this needs to go through the change process for proper communication, so for F29 we need another fix, and we can do this for F30?
I believe that if we put this through the change process, we can make sure that we properly communicate the need to add "hinernate=yes" to the kernel commandline for people who use it and want to keep using it.
I also expect this to, if anything, lower the load for the Fedora kernel team, since it avoids users enabling hibernation without really knowing what they are doing and then filing bugs as a result of this. E.g.: * ATM in F28 hibernation is a simple click in gnome-tweaks away. * Even if we revert the GNOME change which triggered this discussion many other DEs will still advertise hibernate support in some way.
Can you please elaborate a bit on your objections against this?
Regards,
Hans
On Tue, Oct 2, 2018 at 5:53 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi Justin,
On 01-10-18 16:14, Justin Forbes wrote:
On Sun, Sep 30, 2018 at 1:52 PM, Hans de Goede hdegoede@redhat.com wrote:
Hello Fedora kernel team,
On the Fedora desktop list there has been a discussion about systemd now offering a new suspend-then-hibernate option and gnome-settings-daemon's media-keys plugin using this when the power-button gets pressed and systemd saying this is available on the system.
What this does is suspend the system normally and set a RTC wakeup 3 hours in the future, then when the RTC wake happens it hibernates the system.
As discussed on the desktop list this is not really desirable as default behavior for F29 (and later) since the hibernate code is not really something which gets used enough to be well tested and is really not something which we can support.
So after that the discussion has gone in the direction of how to disable the new suspend-then-hibernate behavior.
Lennart made a really interesting observation here, systemd is just proxying if "cat /sys/power/disk" indicates that hibernate is supported.
No, that is not what systemd is doing. The kernel provides a mechanism, it does absolutely nothing with that mechanism unless told to do so. What systemd is actually doing is creating a policy around that mechanism.
systemd is really *not* creating policy here, it has a DBUS API call called CanHibernate which really just proxies what the kernel advertises.
What is new is that GNOME (g-s-d) now uses it be default through by choosing suspend-then-hibernate as suspend action when hibernation is available.
Right, so systemd really is just proxying, and Gnome is now creating a policy. It does not change the underlying issue, we shouldn't cripple a mechanism because someone wants to introduce a new undesirable policy on top of it. Especially when the thing introducing that policy is not the only user of the mechanism.
So if we really don't want to support hibernation as a normal option, while still allowing adventurous user to use it, what really should happen is for the kernel to stop advertising hibernate support. Thinking about this I agree, if we say that we cannot support it, the kernel really should not be advertising support for it by default.
"We have decided that the policy created is not desirable, so we want to disable the mechanism"
Default to off is a different thing then disabling this.
There is a difference between a "policy default to off", and "turning off the mechanism". I would expect a new policy defaulting to off would actually default to whatever is currently there. When a user upgrades from F28 to F30, it seems wrong that their power configuration would change in a way that is unexpected, and frankly more difficult to manage. A regular user can run gnome-tweaks and decide on lid behavior. A regular user cannot edit the kernel command line once a system is booted. Now, it requires root. And we are making it harder for people to edit it as a system boots with other planned changes.
TBH I'm a bit surprised about your objections against this:
- We all seem to agree that this is something which may or
may not work, but is not something which we want to advertise as a "supported" Fedora feature
- Given 1) we also all agree that we should not use it
by default
- If we should not use it by default then shouldn't the
feature default to off ? That is all what is being suggested, basically the equivalent of adding "nohibernate" to the kernel commandline by default.
And this is the problem, there is no reason anyone should have to edit the kernel command line for choosing a power policy setting. Gnome is certainly not the only desktop in use, practically all of the documentation out there explains how to enable or disable hibernate with common tools. We are invalidating all of that documentation just so that gnome can implement a bad default policy. Agreeing that we should not use it by default doesn't mean we should make it any harder to use than it already is. We certainly have no motivation to discourage people for giving it a try, they just have to know that they are hibernating, and have chosen to do so. I would be just fine with it being easier to access in gnome than installing gnome-tweaks, hibernate, if supported by the system, could be easily selected under the power menu in settings.
I expect the kernel changes for this to be about 3 lines of actual code (+a 15 lines or so Kconfig addition) and I expect this to go upstream without much issues as this seems like an entirely reasonable thing to do.
Reading further along the discussion you say that if this were a new feature you would likely agree to defaulting it to off. But since this has been there for years we should not change it ? That seems like a weak argument to me, we have always been doing this in a sub-optimal way so lets continue doing this in a sub-optimal way ?
I don't agree that the way we have been doing this is sub-optimal at all. In fact, I think this proposed patch is the sub-optimal way. My point is, new features, particularly with possible undesirable results, are often defaulted to off under a "tech preview" model. The mechanism in the kernel is not new. it may not work for everyone, but it has been working fairly well for those who it does work for. Why would we change them when a piece of userspace (that some of them might never even use) wants to create a poor default policy?
I agree that we should not change it in the middle of a Fedora cycle. Hence I wrote:
Against:
Currently we do have some users using hibernation without adding any options to the kernel commandline. These users will have to now add "hibernate=yes" to their kernel commandline.
I'm thinking that yes we want this, but maybe this needs to go through the change process for proper communication, so for F29 we need another fix, and we can do this for F30?
I believe that if we put this through the change process, we can make sure that we properly communicate the need to add "hinernate=yes" to the kernel commandline for people who use it and want to keep using it.
I also expect this to, if anything, lower the load for the Fedora kernel team, since it avoids users enabling hibernation without really knowing what they are doing and then filing bugs as a result of this. E.g.:
- ATM in F28 hibernation is a simple click in gnome-tweaks away.
- Even if we revert the GNOME change which triggered this discussion many other DEs will still advertise hibernate support in some way.
Can you please elaborate a bit on your objections against this?
It really is simple. You don't cripple a mechanism so that you can install a bad default policy. The kernel is providing a plain and neutral mechanism here. If people agree that the default policy is wrong, it is the policy that should change. While I strongly feel that the default power behavior should not be hibernate, I also fee pretty strongly that it should be very easy to people to change.
Justin
Hi,
On 02-10-18 14:26, Justin Forbes wrote:
On Tue, Oct 2, 2018 at 5:53 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi Justin,
On 01-10-18 16:14, Justin Forbes wrote:
On Sun, Sep 30, 2018 at 1:52 PM, Hans de Goede hdegoede@redhat.com wrote:
Hello Fedora kernel team,
On the Fedora desktop list there has been a discussion about systemd now offering a new suspend-then-hibernate option and gnome-settings-daemon's media-keys plugin using this when the power-button gets pressed and systemd saying this is available on the system.
What this does is suspend the system normally and set a RTC wakeup 3 hours in the future, then when the RTC wake happens it hibernates the system.
As discussed on the desktop list this is not really desirable as default behavior for F29 (and later) since the hibernate code is not really something which gets used enough to be well tested and is really not something which we can support.
So after that the discussion has gone in the direction of how to disable the new suspend-then-hibernate behavior.
Lennart made a really interesting observation here, systemd is just proxying if "cat /sys/power/disk" indicates that hibernate is supported.
No, that is not what systemd is doing. The kernel provides a mechanism, it does absolutely nothing with that mechanism unless told to do so. What systemd is actually doing is creating a policy around that mechanism.
systemd is really *not* creating policy here, it has a DBUS API call called CanHibernate which really just proxies what the kernel advertises.
What is new is that GNOME (g-s-d) now uses it be default through by choosing suspend-then-hibernate as suspend action when hibernation is available.
Right, so systemd really is just proxying, and Gnome is now creating a policy. It does not change the underlying issue, we shouldn't cripple a mechanism because someone wants to introduce a new undesirable policy on top of it. Especially when the thing introducing that policy is not the only user of the mechanism.
So if we really don't want to support hibernation as a normal option, while still allowing adventurous user to use it, what really should happen is for the kernel to stop advertising hibernate support. Thinking about this I agree, if we say that we cannot support it, the kernel really should not be advertising support for it by default.
"We have decided that the policy created is not desirable, so we want to disable the mechanism"
Default to off is a different thing then disabling this.
There is a difference between a "policy default to off", and "turning off the mechanism". I would expect a new policy defaulting to off would actually default to whatever is currently there. When a user upgrades from F28 to F30, it seems wrong that their power configuration would change in a way that is unexpected, and frankly more difficult to manage. A regular user can run gnome-tweaks and decide on lid behavior. A regular user cannot edit the kernel command line once a system is booted. Now, it requires root. And we are making it harder for people to edit it as a system boots with other planned changes.
TBH I'm a bit surprised about your objections against this:
- We all seem to agree that this is something which may or
may not work, but is not something which we want to advertise as a "supported" Fedora feature
- Given 1) we also all agree that we should not use it
by default
- If we should not use it by default then shouldn't the
feature default to off ? That is all what is being suggested, basically the equivalent of adding "nohibernate" to the kernel commandline by default.
And this is the problem, there is no reason anyone should have to edit the kernel command line for choosing a power policy setting. Gnome is certainly not the only desktop in use, practically all of the documentation out there explains how to enable or disable hibernate with common tools. We are invalidating all of that documentation just so that gnome can implement a bad default policy. Agreeing that we should not use it by default doesn't mean we should make it any harder to use than it already is. We certainly have no motivation to discourage people for giving it a try, they just have to know that they are hibernating, and have chosen to do so. I would be just fine with it being easier to access in gnome than installing gnome-tweaks, hibernate, if supported by the system, could be easily selected under the power menu in settings.
I expect the kernel changes for this to be about 3 lines of actual code (+a 15 lines or so Kconfig addition) and I expect this to go upstream without much issues as this seems like an entirely reasonable thing to do.
Reading further along the discussion you say that if this were a new feature you would likely agree to defaulting it to off. But since this has been there for years we should not change it ? That seems like a weak argument to me, we have always been doing this in a sub-optimal way so lets continue doing this in a sub-optimal way ?
I don't agree that the way we have been doing this is sub-optimal at all. In fact, I think this proposed patch is the sub-optimal way. My point is, new features, particularly with possible undesirable results, are often defaulted to off under a "tech preview" model. The mechanism in the kernel is not new. it may not work for everyone, but it has been working fairly well for those who it does work for. Why would we change them when a piece of userspace (that some of them might never even use) wants to create a poor default policy?
I agree that we should not change it in the middle of a Fedora cycle. Hence I wrote:
Against:
Currently we do have some users using hibernation without adding any options to the kernel commandline. These users will have to now add "hibernate=yes" to their kernel commandline.
I'm thinking that yes we want this, but maybe this needs to go through the change process for proper communication, so for F29 we need another fix, and we can do this for F30?
I believe that if we put this through the change process, we can make sure that we properly communicate the need to add "hinernate=yes" to the kernel commandline for people who use it and want to keep using it.
I also expect this to, if anything, lower the load for the Fedora kernel team, since it avoids users enabling hibernation without really knowing what they are doing and then filing bugs as a result of this. E.g.:
- ATM in F28 hibernation is a simple click in gnome-tweaks away.
- Even if we revert the GNOME change which triggered this discussion many other DEs will still advertise hibernate support in some way.
Can you please elaborate a bit on your objections against this?
It really is simple. You don't cripple a mechanism so that you can install a bad default policy. The kernel is providing a plain and neutral mechanism here. If people agree that the default policy is wrong, it is the policy that should change. While I strongly feel that the default power behavior should not be hibernate, I also fee pretty strongly that it should be very easy to people to change.
Ok fair enough. Keeping it easy for users to try out hibernate is a valid argument.
So that puts the ball back into the court of the GNOME devs, adding Benjamin (g-s-d co-maintainer) to the Cc and I'll also ping him on IRC about this.
Regards,
Hans
On Di, 02.10.18 14:34, Hans de Goede (hdegoede@redhat.com) wrote:
Ok fair enough. Keeping it easy for users to try out hibernate is a valid argument.
This is just weird. Why would GNOME expose a button to regular user that reads "hey, press me, please use this feature, but it's not going to work, and nobody is going to help you with it or fix bugs, kthxbye". That's just awful UI.
Quite frankly, this is quite ridiculous. GNOME is not the only user of this, we shouldn't expose crap that doesn't work in the UI, regardless what the UI looks like. GNOME has every right to assume that what the underlying layers advertise works. And when it doesn't then the underlying layers should stop advertising this.
If the kernel folks apprently are not willing to clean this up, nor stop advertising its availability, then I guess we can mask this out in the systemd RPM, but what a mess, now systemd.rpm suddenly becomes the dumping ground for policy decisions when kernel code is good enough and when it isn't, and when the kernel maintainers want to support something or not.
Lennart
On Tue, Oct 2, 2018 at 10:18 AM, Lennart Poettering mzerqung@0pointer.de wrote:
On Di, 02.10.18 14:34, Hans de Goede (hdegoede@redhat.com) wrote:
Ok fair enough. Keeping it easy for users to try out hibernate is a valid argument.
This is just weird. Why would GNOME expose a button to regular user that reads "hey, press me, please use this feature, but it's not going to work, and nobody is going to help you with it or fix bugs, kthxbye". That's just awful UI.
Quite frankly, this is quite ridiculous. GNOME is not the only user of this, we shouldn't expose crap that doesn't work in the UI, regardless what the UI looks like. GNOME has every right to assume that what the underlying layers advertise works. And when it doesn't then the underlying layers should stop advertising this.
Exactly, gnome is not the only user of this. Why make everyone else change to accommodate gnome? The advertisement that the kernel supports (and the hardware claims to support) hibernate are based on the best available knowledge. If you don't want to expose it in the typical gnome UI, fine, leave it in tweak. People know to look there anyway. I am personally not a fan of how much configuration information gnome hides from the default UI, but it has been that way for years, and it is well known how to work around it. TBH, there are plenty of reasons to not want a fully capable system to hibernate. Whether it be not wanting your memory content written out to disk automatically, wanting faster resume when you know you have enough battery to handle the expected suspend time, etc. The policy should be configurable somewhere.
If the kernel folks apprently are not willing to clean this up, nor stop advertising its availability, then I guess we can mask this out in the systemd RPM, but what a mess, now systemd.rpm suddenly becomes the dumping ground for policy decisions when kernel code is good enough and when it isn't, and when the kernel maintainers want to support something or not.
If systemd is truly just a proxy for the mechanism, there is no actual policy there, why would systemd bother filtering it out at all?
Justin
On Tue, Oct 02, 2018 at 11:12:44AM -0500, Justin Forbes wrote:
On Tue, Oct 2, 2018 at 10:18 AM, Lennart Poettering mzerqung@0pointer.de wrote:
On Di, 02.10.18 14:34, Hans de Goede (hdegoede@redhat.com) wrote:
Ok fair enough. Keeping it easy for users to try out hibernate is a valid argument.
This is just weird. Why would GNOME expose a button to regular user that reads "hey, press me, please use this feature, but it's not going to work, and nobody is going to help you with it or fix bugs, kthxbye". That's just awful UI.
Quite frankly, this is quite ridiculous. GNOME is not the only user of this, we shouldn't expose crap that doesn't work in the UI, regardless what the UI looks like. GNOME has every right to assume that what the underlying layers advertise works. And when it doesn't then the underlying layers should stop advertising this.
I have to say I agree with Justin on this. The main reason is that I think hibernate "mostly works", as long as the configuration is correct (resume= is present, swap is not encrypted with an ephemeral key, etc). I'll start a separate thread asking people about their experiences so that we can gather some more anecdata.
If systemd is truly just a proxy for the mechanism, there is no actual policy there, why would systemd bother filtering it out at all?
I have been working on (simple) patches [1] to both improve detection when we should disable hibernation (e.g. resume= is missing) and to make it easy to do this through configuration (set AllowHibernation= in /etc/systemd/sleep.conf).
Behaviour of systemd should improve a bit once those are merged. But this argument is convincing for me: before, I wanted to set the policy in systemd rpm, e.g. by setting AllowHibernation=no once that's possible. But it is clear that g-s-d is making the policy choice here, so the policy change should be reverted there.
[1] https://github.com/systemd/systemd/pull/10262
Zbyszek
On Tue, Oct 02, 2018 at 05:18:49PM +0200, Lennart Poettering wrote:
On Di, 02.10.18 14:34, Hans de Goede (hdegoede@redhat.com) wrote:
Ok fair enough. Keeping it easy for users to try out hibernate is a valid argument.
This is just weird. Why would GNOME expose a button to regular user that reads "hey, press me, please use this feature, but it's not going to work, and nobody is going to help you with it or fix bugs, kthxbye". That's just awful UI.
you are right. So GNOME should change to old bevavior.
Quite frankly, this is quite ridiculous. GNOME is not the only user of this, we shouldn't expose crap that doesn't work in the UI, regardless what the UI looks like. GNOME has every right to assume that what the underlying layers advertise works. And when it doesn't then the underlying layers should stop advertising this.
Iirc on the kernel side it has been for nearly two decades or so like it is now. Every other "user" did learn how to deal with it. Why the sudden drama? Because GNOME decided to change something without considering to ask the user?
Richard
On 10/02/2018 08:18 AM, Lennart Poettering wrote:
On Di, 02.10.18 14:34, Hans de Goede (hdegoede@redhat.com) wrote:
Ok fair enough. Keeping it easy for users to try out hibernate is a valid argument.
This is just weird. Why would GNOME expose a button to regular user that reads "hey, press me, please use this feature, but it's not going to work, and nobody is going to help you with it or fix bugs, kthxbye". That's just awful UI.
Quite frankly, this is quite ridiculous. GNOME is not the only user of this, we shouldn't expose crap that doesn't work in the UI, regardless what the UI looks like. GNOME has every right to assume that what the underlying layers advertise works. And when it doesn't then the underlying layers should stop advertising this.
If the kernel folks apprently are not willing to clean this up, nor stop advertising its availability, then I guess we can mask this out in the systemd RPM, but what a mess, now systemd.rpm suddenly becomes the dumping ground for policy decisions when kernel code is good enough and when it isn't, and when the kernel maintainers want to support something or not.
I think we're stuck between two competing goals of Fedora: give users as many features as possible vs. having those features be stable. In the kernel we've tended to err on the side of allowing as many options as possible and just not giving support.
The big hammer of disabling hibernation doesn't differentiate between cases where hibernate is fundamentally broken and may never work (hardware or firmware issues) vs. might just need some quirks. Is there more information the kernel could expose to allow a more informed decision about whether we should allow hibernate as an option to the user?
Thanks, Laura
----- Original Message -----
It really is simple. You don't cripple a mechanism so that you can install a bad default policy. The kernel is providing a plain and neutral mechanism here. If people agree that the default policy is wrong, it is the policy that should change. While I strongly feel that the default power behavior should not be hibernate, I also fee pretty strongly that it should be very easy to people to change.
Given the circumstances under which hibernation does not work, and which can be enabled unwittingly in our installer, and the side effects of it being used, I feel that a kernel command-line is a low enough bar to jump.
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 a side note, UPower also uses systemd's Can* methods to check for the availability of power saving methods, and to activate them)
On Di, 02.10.18 10:16, Bastien Nocera (bnocera@redhat.com) 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...
Lennart
----- Original Message -----
On Di, 02.10.18 10:16, Bastien Nocera (bnocera@redhat.com) 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...
There's problems with: - not having enough swap space available at a particular instant - swap being encrypted and not allowing restore because the keys aren't there anymore - swap not being encrypted, which could leak information down the line - resume= not being there in the default parameters, so dracut needing to rewrite the initrd before hibernation is considered done (?)
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.
On Tue, Oct 02, 2018 at 12:16:02PM -0400, Bastien Nocera wrote:
There's problems with:
- not having enough swap space available at a particular instant
- swap being encrypted and not allowing restore because the keys aren't there anymore
In my experience, encrypted swap works fine. During hibernation the kernel writes to the encrypted swap and shuts the system down. On power up, the system starts booting up normally, the initramfs asks the user for the passphrase, sees the resume information, and initiates the resume from the encrypted swap.
On 10/02/2018 09:16 AM, Bastien Nocera wrote:
----- Original Message -----
On Di, 02.10.18 10:16, Bastien Nocera (bnocera@redhat.com) 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...
There's problems with:
- not having enough swap space available at a particular instant
- swap being encrypted and not allowing restore because the keys aren't there anymore
- swap not being encrypted, which could leak information down the line
- resume= not being there in the default parameters, so dracut needing to rewrite the initrd before hibernation is considered done (?)
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.
This is the real objection I have: hibernation ultimately has many different parts and just disabling at the kernel level misses some important pieces. It's not clear to me if just allowing users to enable kernel support on the command line will be enough to have a good end user experience.
Thanks, Laura
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@redhat.com) 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
----- Original Message -----
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@redhat.com) 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.
Simple. Boot machine, swap is empty. You'd setup hibernation because at that moment in time, your swap is empty, and you have enough room to dump your whole RAM. Then work on something, and fill up the swap. And hibernation now fails because the swap is full up.
- 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.
There's bits of data that will never be swapped to disk under normal operations, such as passwords, under normal circumstances. Those would end up on disk, in the swap, when hibernating.
- 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.
We'll still need to fix the installer to take that into account.
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.
But we still need to get away from using swap for saving that data, and until we do, hibernation will be flaky.
(I can't hibernate on any of my machines as I never set up big enough swap partitions, because I know that my machine will be unusable if the swap is actually used as swap).
On Thu, Oct 04, 2018 at 05:11:12AM -0400, Bastien Nocera wrote:
----- Original Message -----
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@redhat.com) 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.
Simple. Boot machine, swap is empty. You'd setup hibernation because at that moment in time, your swap is empty, and you have enough room to dump your whole RAM. Then work on something, and fill up the swap. And hibernation now fails because the swap is full up.
Well, "hibernation is possible" is a dynamic state. Hibernation does not "fail", it just stops being advertised.
I was explicitly talking about the case where it is *advertised* as available, it starts, but then actually fails mid-way.
- 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.
There's bits of data that will never be swapped to disk under normal operations, such as passwords, under normal circumstances. Those would end up on disk, in the swap, when hibernating.
True, that is valid point. If applications use mlock(2), they can protect some pages against being swapped out. gnome-keyring-daemon, goa-daemon, some WebKit stuff is doing that on F29.
But it seems many applications don't actually do that. E.g. firefox ($ for i in $(pidof firefox); do grep VmLck /proc/$i/status;done|uniq -c 5 VmLck: 0 kB)
One simply has to assume that all applications cannot get it right all of the time, so if one does not trust physical security of the machine, the only reliable way to protect against such attacks is to encrypt swap.
- 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.
We'll still need to fix the installer to take that into account.
The installer has already been fixed to add resume=, but that is irrelevant. What is discussed here is the opposite: other parts of userspace detecting if the setup is correct.
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.
But we still need to get away from using swap for saving that data, and until we do, hibernation will be flaky.
Yes, it seems we really want to do this. It'd be so nice if kernel could allow memory.swap.current to be set on the root cgroup. We could set it to something like ~10% RAM but still have a bigger swap to support hibernation.
(The kernel does not allow limits on the root cgroup with the justification that those limits are already settable in other places. But this one isn't.)
(I can't hibernate on any of my machines as I never set up big enough swap partitions, because I know that my machine will be unusable if the swap is actually used as swap).
Zbyszek
On Di, 02.10.18 07:26, Justin Forbes (jmforbes@linuxtx.org) wrote:
What is new is that GNOME (g-s-d) now uses it be default through by choosing suspend-then-hibernate as suspend action when hibernation is available.
Right, so systemd really is just proxying, and Gnome is now creating a policy. It does not change the underlying issue, we shouldn't cripple a mechanism because someone wants to introduce a new undesirable
Uh, the mechanism is already "crippled", I mean, that's the key of the issue: the hibernation mechanism apparently doesn't have the quality and does not receive the love it needs for the Fedora community to support it properly.
There is a difference between a "policy default to off", and "turning off the mechanism". I would expect a new policy defaulting to off would actually default to whatever is currently there. When a user upgrades from F28 to F30, it seems wrong that their power configuration would change in a way that is unexpected, and frankly more difficult to manage. A regular user can run gnome-tweaks and decide on lid behavior. A regular user cannot edit the kernel command line once a system is booted. Now, it requires root. And we are making it harder for people to edit it as a system boots with other planned changes.
So let me ask then: is it the Fedora kernel team's intention to support hibernation well enough that it can work for "regular users"? With the above you suggest the code quality and will to support is good enough for "regular users" to be exposed to it.
It was my assumption that everybody agreed that precisely that was not the case and that hibernation is at best a "tech preview" that only users who know what they do should enable, i.e. those which know how to edit the kernel cmdline...
I don't agree that the way we have been doing this is sub-optimal at all. In fact, I think this proposed patch is the sub-optimal way. My point is, new features, particularly with possible undesirable results, are often defaulted to off under a "tech preview" model. The mechanism in the kernel is not new. it may not work for everyone, but it has been working fairly well for those who it does work for. Why would we change them when a piece of userspace (that some of them might never even use) wants to create a poor default policy?
Can you give examples of other kernel subsystems that are also advertised as available by the Fedora kernel, and part of the core kernel RPM but are of this "tech preview" kind?
It really is simple. You don't cripple a mechanism so that you can install a bad default policy. The kernel is providing a plain and neutral mechanism here. If people agree that the default policy is
Well, it's not a "neutral mechanism" if you don't intend to properly support it and if you know it's known to be buggy, and you apparently suggest that people not use it?
Lennart
On Tue, Oct 2, 2018 at 10:12 AM, Lennart Poettering mzerqung@0pointer.de wrote:
On Di, 02.10.18 07:26, Justin Forbes (jmforbes@linuxtx.org) wrote:
What is new is that GNOME (g-s-d) now uses it be default through by choosing suspend-then-hibernate as suspend action when hibernation is available.
Right, so systemd really is just proxying, and Gnome is now creating a policy. It does not change the underlying issue, we shouldn't cripple a mechanism because someone wants to introduce a new undesirable
Uh, the mechanism is already "crippled", I mean, that's the key of the issue: the hibernation mechanism apparently doesn't have the quality and does not receive the love it needs for the Fedora community to support it properly.
There is a difference between a "policy default to off", and "turning off the mechanism". I would expect a new policy defaulting to off would actually default to whatever is currently there. When a user upgrades from F28 to F30, it seems wrong that their power configuration would change in a way that is unexpected, and frankly more difficult to manage. A regular user can run gnome-tweaks and decide on lid behavior. A regular user cannot edit the kernel command line once a system is booted. Now, it requires root. And we are making it harder for people to edit it as a system boots with other planned changes.
So let me ask then: is it the Fedora kernel team's intention to support hibernation well enough that it can work for "regular users"? With the above you suggest the code quality and will to support is good enough for "regular users" to be exposed to it.
It was my assumption that everybody agreed that precisely that was not the case and that hibernation is at best a "tech preview" that only users who know what they do should enable, i.e. those which know how to edit the kernel cmdline...
We support it as best we can. We can't fix broken firmware or binary drivers, but yes, in cases where the kernel itself is at fault, it is just as supported as anything else we enable. The exception is secure boot, where it is completely disabled. There has been some talk of trying to find a solution that will not break the trust model, but I have not seen any patches there. There is plenty of documentation as to how to enable hibernation. For people who want that functionality, I am happy to have them test it. If there is an actual kernel problem around it, we handle that with about the same priority as an alsa bug or suspend bug. If it is a non kernel problem, there is nothing we can do.
I don't agree that the way we have been doing this is sub-optimal at all. In fact, I think this proposed patch is the sub-optimal way. My point is, new features, particularly with possible undesirable results, are often defaulted to off under a "tech preview" model. The mechanism in the kernel is not new. it may not work for everyone, but it has been working fairly well for those who it does work for. Why would we change them when a piece of userspace (that some of them might never even use) wants to create a poor default policy?
Can you give examples of other kernel subsystems that are also advertised as available by the Fedora kernel, and part of the core kernel RPM but are of this "tech preview" kind?
You want things that are potentially buggy and can eat data? How long have we had btrfs enabled now? Things which are known to not work on a sizeable percentage of hardware that the driver claims to support? nouveau would top the list Things which a small subset of users actually care about and usually work for them, but most people don't care? CAN, various obscure network protocols, filesystems, we have a ton of them.
I do not think that we should disable any of these by default. One of the advantages of Fedora is the ability to experiment, develop, test, or work with things which just cannot be supported under a contract/SLA type environment.
It really is simple. You don't cripple a mechanism so that you can install a bad default policy. The kernel is providing a plain and neutral mechanism here. If people agree that the default policy is
Well, it's not a "neutral mechanism" if you don't intend to properly support it and if you know it's known to be buggy, and you apparently suggest that people not use it?
It is known to be buggy on some hardware, and yes, it is a neutral mechanism. There are plenty of mechanisms in the kernel which can completely destroy a system with bad policy. We trust userspace to have a sane policy around them. We tend to not make recommendations as to what people choose to use on their own systems, but we absolutely suggest that desktop environments with a large number of users not write a bad policy around them. Now people are asking to cripple the mechanism so that Gnome users can default to poor policy. Why should non gnome users have to change their systems at all to accommodate a gnome desktop policy?
Lennart
-- Lennart Poettering, Red Hat _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org 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/desktop@lists.fedoraproject.or...
On Tue, Oct 2, 2018 at 10:02 AM, Justin Forbes jmforbes@linuxtx.org wrote:
On Tue, Oct 2, 2018 at 10:12 AM, Lennart Poettering mzerqung@0pointer.de wrote:
Can you give examples of other kernel subsystems that are also advertised as available by the Fedora kernel, and part of the core kernel RPM but are of this "tech preview" kind?
You want things that are potentially buggy and can eat data? How long have we had btrfs enabled now?
That's silly to the point of nonsense. There's quite a lot of evidence of hardware bugs as a result of both ZFS and Btrfs catching such things in the act. That fully checksumming file systems intentionally face plant by design because they're immediately aware of inconsistency isn't a bug. I've had zero data eaten on Btrfs, I can't say the same due to bugs on other file systems or volume managers - on the same hardware where I know for sure it wasn't hardware instigating the problem. And this has been confirmed as XFS moved to metadata checksumming, just how silly some hardware behaves. It's basically the same dilemma as what's under discussion with hibernation.
We tend to not make recommendations as to what people choose to use on their own systems, but we absolutely suggest that desktop environments with a large number of users not write a bad policy around them. Now people are asking to cripple the mechanism so that Gnome users can default to poor policy. Why should non gnome users have to change their systems at all to accommodate a gnome desktop policy?
I agree with this logic. The user space policy change is premature given the known state of things, and it's an open question what effort is being put into this by manufacturers of hardware and at Microsoft - which is relevant because that's bulk of the hardware market we're supporting. I guarantee you hibernation isn't working on Macs - whatever they're doing is not standard ACPI, 100% of the time on every Mac I've ever tried suspend on, the kernel detects the hibernation file is corrupt. Whether it's corrupted at the time it's written out or read in, I have no idea. But Apple's hibernation is not foolproof either. I see maybe 1 in 10 restore from hibernation fail.
Application state saving on iOS and Android is about as fool proof as I've ever experienced. And if that's not the way forward, that's fine, but I don't see how looking backward at suspend to disk is really that helpful, as a policy. I'd say it's a net failure because it's not consistent, or reliable enough even on hardware it does often work on.
Both suspend and hibernation have a much higher risk of failure to complete the cycle: leaving the laptop closed, running, discharging, and getting hot. Poweroff has almost none of that risk.
On Tue, Oct 2, 2018 at 9:12 AM, Lennart Poettering mzerqung@0pointer.de wrote:
On Di, 02.10.18 07:26, Justin Forbes (jmforbes@linuxtx.org) wrote:
What is new is that GNOME (g-s-d) now uses it be default through by choosing suspend-then-hibernate as suspend action when hibernation is available.
Right, so systemd really is just proxying, and Gnome is now creating a policy. It does not change the underlying issue, we shouldn't cripple a mechanism because someone wants to introduce a new undesirable
Uh, the mechanism is already "crippled", I mean, that's the key of the issue: the hibernation mechanism apparently doesn't have the quality and does not receive the love it needs for the Fedora community to support it properly.
I don't think it's a community issue or Fedora kernel team issue at all. It's strictly maintained, warts and all, by upstream kernel developers. There's also some complicating factors as to which ACPI version is used by Windows (I think it's insisting the hardware fallback to a much older ACPI revision, where Linux has at least until recently (?) supported the latest version of ACPI the hardware supports). Even Windows 10 doesn't always get hibernation right/reliable. And so we end up in a much bigger pit of potential bugs than even Windows does on the same hardware - and it affects the reliability of suspend to RAM not just suspend to disk. On very common HP hardware, I see a wake from suspend to RAM hard fail about 1 in 5 times and there's nothing in the logs because it's crashing during the wake up phase, not even video has been initialized yet so there's literally nothing to do about some of these problems.
I suggest that the original question of this thread needs to go upstream, and supplement it with more questions there, just exactly what the state of S4/S5 support really is; and what it's going to look like in the future.
Again, the Windows 10 case is, they're basically bailing out on saving user state in the hibernation file. Instead, upon hibernation being needed, they're basically logging the user out, expecting applications save their own state, and then create a hibernation file based on all users being logged out. That way all a restore from hibernation is merely a faster arrival at the login window than booting. If the hibernation restore works, it's fast, if not, you have to do a full boot. Either way the experience for the user is the same, you still have to log back into your user, and launch apps.
Also, I'd consider the kernel hibernation mechanism itself broken because a) we don't have a Secure Boot implementation for hibernation upstream and b) we don't have a Secure Boot implementation upstream either. I think upstream kernel devs need to bite the bullet on how they're going to support Secure Boot, before they're supporting hibernation. Arguably both things are busted (or vapor) right now. That it's working with some legacy computers is neat but even if that were 51% of computers, it's not good enough to say it's working or supportable.
On 10/02/2018 08:12 AM, Lennart Poettering wrote:
Can you give examples of other kernel subsystems that are also advertised as available by the Fedora kernel, and part of the core kernel RPM but are of this "tech preview" kind?
Another example would be kexec. The Fedora kernel nominally supports this feature but it requires some setup and tends to be finicky to set up. We'd certainly take patches to fix it and we've started to get more engaged with the kexec team to make sure it works but ultimately it's best effort.
We also have the various wireless drivers which get a good amount of support from various developers but ultimately if some particular hardware configuration doesn't work quite right there's not a lot we can do.
Thanks, Laura
On Tue, Oct 02, 2018 at 11:10:16AM -0700, Laura Abbott wrote:
On 10/02/2018 08:12 AM, Lennart Poettering wrote:
Can you give examples of other kernel subsystems that are also advertised as available by the Fedora kernel, and part of the core kernel RPM but are of this "tech preview" kind?
Another example would be kexec. The Fedora kernel nominally supports this feature but it requires some setup and tends to be finicky to set up. We'd certainly take patches to fix it and we've started to get more engaged with the kexec team to make sure it works but ultimately it's best effort.
FWIW, recent systemd does kexec "setup" automatically if sd-boot is used, i.e. no setup is required, and 'systemctl kexec' should boot the same kernel with the same options that a full reboot would.
If sd-boot is not used, some setup is necessary, alas.
Zbyszek
kernel@lists.fedoraproject.org
-
Anderson, Charles R -
Bastien Nocera -
Chris Murphy -
Hans de Goede -
Justin Forbes -
Laura Abbott -
Lennart Poettering -
Peter Robinson -
Richard Z -
Zbigniew Jędrzejewski-Szmek