1:52 p.m.
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
9:14 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Sun, Sep 30, 2018 at 1:52 PM, Hans de Goede <hdegoede(a)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
9:41 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Mo, 01.10.18 09:14, Justin Forbes (jmforbes(a)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
--
Lennart Poettering, Red Hat
9:59 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Mon, Oct 1, 2018 at 3:42 PM Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Mo, 01.10.18 09:14, Justin Forbes (jmforbes(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to desktop-leave(a)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...
10:14 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Mo, 01.10.18 15:59, Peter Robinson (pbrobinson(a)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
--
Lennart Poettering, Red Hat
10:54 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Mon, Oct 1, 2018 at 10:14 AM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
On Mo, 01.10.18 15:59, Peter Robinson (pbrobinson(a)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
5:53 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
Hi Justin,
On 01-10-18 16:14, Justin Forbes wrote:
On Sun, Sep 30, 2018 at 1:52 PM, Hans de Goede
<hdegoede(a)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
7:26 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Tue, Oct 2, 2018 at 5:53 AM, Hans de Goede <hdegoede(a)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(a)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:
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.
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
7:34 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
Hi,
On 02-10-18 14:26, Justin Forbes wrote:
On Tue, Oct 2, 2018 at 5:53 AM, Hans de Goede
<hdegoede(a)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(a)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:
>
> 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.
>
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
10:18 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Di, 02.10.18 14:34, Hans de Goede (hdegoede(a)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
--
Lennart Poettering, Red Hat
11:12 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Tue, Oct 2, 2018 at 10:18 AM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
On Di, 02.10.18 14:34, Hans de Goede (hdegoede(a)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
8:40 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
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(a)0pointer.de> wrote:
> On Di, 02.10.18 14:34, Hans de Goede (hdegoede(a)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
12:05 p.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
Hi
On Tue, 2018-10-02 at 14:34 +0200, Hans de Goede wrote:
On 02-10-18 14:26, Justin Forbes wrote:
> On Tue, Oct 2, 2018 at 5:53 AM, Hans de Goede <hdegoede(a)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(a)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:
> >
> > 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.
> >
>
> 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.
So, it still looks like we are at a bit of a dead end with this
discussion. We know we need to disable the use of hibernation by
default but where depends on how you look at the issue (is it a policy
issue or are features falsely advertised).
From a GNOME Settings Daemon perspective I am tempted to simply remove
the feature again. There are two main reasons for considering this:
1. It would solve the pressing issue for F29.
2. The current implementation is incomplete and causes
inconsistencies for users.
I only realised the issue with 2. when looking into it more because of
this discussion. We currently have at least 6 reasons to suspend with
different components creating the policy:
* lid action:
- systemd-logind
- gsd-power inhibits in some cases
* power button:
- gsd-media-keys: power-button-action
gsd-power settings keys
* soft button:
- gnome-shell: hardcoded to suspend (logind call)
* user is idle
- gsd-power: sleep-inactive-ac-type, sleep-inactive-battery-type
gsd-power settings keys
* battery critical:
- upower: /etc/UPower/UPower.conf (defaults to hybrid suspend)
* screen blanking:
- gsd-power: hardcoded to suspend on tablets
The patches that introduced the policy only made the change for the
"power button" and "user is idle" cases (and "screen
blanking"). In
particular the "soft button" and "lid" cases are not covered, meaning
that in many cases users will not actually suspend-then-hibernate[1].
So, my proposal from the g-s-d side is:
1. For the *stable* release cycle, hide the new "feature" behind a
compile time switch, disable it by default and announce properly
in the release notes.
2. For the unstable release cycle plan on finding a more consistent
solution to control the policy.
Whether this is user configurable or not could still be something
to discuss.
I would be happy if the underlying CanSuspendThenHibernate and
CanSuspend calls would not be advertising features that are unusable.
My personal view is that it would be good if these calls were only
advertising the feature if it actually works, but I also see how this
can be hard or impossible to detect.
If systemd (or the kernel) is adjusted, then g-s-d may not need a
change. But even then it may still make sense to allow disabling the
new behaviour just to avoid the policy inconsistencies in the short
term.
Regards,
Benjamin
[1] Which probably explains why I have not personally run into this
issue yet as I personally use the two unaffected methods.
5:59 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Tue, Oct 2, 2018 at 7:06 PM Benjamin Berg <bberg(a)redhat.com> wrote:
So, my proposal from the g-s-d side is:
1. For the *stable* release cycle, hide the new "feature" behind a
compile time switch, disable it by default and announce properly
in the release notes.
Is there a good reason why this can't simply be an option in gsettings
that's not visible in the control-center UI? For those of us which have
hibernation working reliably and would love to use suspend-then-hibernate,
why make it completely inaccessible with a compile time option?
10:50 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Wed, 2018-10-03 at 12:59 +0200, Kamil Paral wrote:
On Tue, Oct 2, 2018 at 7:06 PM Benjamin Berg
<bberg(a)redhat.com>
wrote:
> So, my proposal from the g-s-d side is:
> 1. For the *stable* release cycle, hide the new "feature" behind a
> compile time switch, disable it by default and announce
> properly
> in the release notes.
Is there a good reason why this can't simply be an option in
gsettings that's not visible in the control-center UI? For those of
us which have hibernation working reliably and would love to use
suspend-then-hibernate, why make it completely inaccessible with a
compile time option?
The reason I am proposing this is because there is no clean way of
adding an option currently. If I could easily add an option to fix
those policy decisions, than I would happily do so. But adding a
runtime option that has to be removed again later seems too invasive to
me considering the feature has been broken all along.
Benjamin
_______________________________________________
desktop mailing list -- desktop(a)lists.fedoraproject.org
To unsubscribe send an email to desktop-leave(a)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...
8:52 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Tue, Oct 02, 2018 at 07:05:45PM +0200, Benjamin Berg wrote:
Hi
On Tue, 2018-10-02 at 14:34 +0200, Hans de Goede wrote:
> On 02-10-18 14:26, Justin Forbes wrote:
> > On Tue, Oct 2, 2018 at 5:53 AM, Hans de Goede <hdegoede(a)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(a)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:
> > >
> > > 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.
> > >
> >
> > 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.
So, it still looks like we are at a bit of a dead end with this
discussion. We know we need to disable the use of hibernation by
default but where depends on how you look at the issue (is it a policy
issue or are features falsely advertised).
From a GNOME Settings Daemon perspective I am tempted to simply remove
the feature again. There are two main reasons for considering this:
1. It would solve the pressing issue for F29.
2. The current implementation is incomplete and causes
inconsistencies for users.
I only realised the issue with 2. when looking into it more because of
this discussion. We currently have at least 6 reasons to suspend with
different components creating the policy:
* lid action:
- systemd-logind
- gsd-power inhibits in some cases
* power button:
- gsd-media-keys: power-button-action
gsd-power settings keys
* soft button:
- gnome-shell: hardcoded to suspend (logind call)
* user is idle
- gsd-power: sleep-inactive-ac-type, sleep-inactive-battery-type
gsd-power settings keys
* battery critical:
- upower: /etc/UPower/UPower.conf (defaults to hybrid suspend)
* screen blanking:
- gsd-power: hardcoded to suspend on tablets
The patches that introduced the policy only made the change for the
"power button" and "user is idle" cases (and "screen
blanking"). In
particular the "soft button" and "lid" cases are not covered,
meaning
that in many cases users will not actually suspend-then-hibernate[1].
Yeah, that
seems quite inconsistent. I'd say "power button" > "lid" >
"user is idle",
in the sense that events on the right should use lighter suspend modes.
So, my proposal from the g-s-d side is:
1. For the *stable* release cycle, hide the new "feature" behind a
compile time switch, disable it by default and announce properly
in the release notes.
+1, even though a hidden setting key would be even nicer
2. For the unstable release cycle plan on finding a more consistent
solution to control the policy.
Whether this is user configurable or not could still be something
to discuss.
That'd be great too.
I would be happy if the underlying CanSuspendThenHibernate and
CanSuspend calls would not be advertising features that are unusable.
Working on it
;)
My personal view is that it would be good if these calls were only
advertising the feature if it actually works, but I also see how this
can be hard or impossible to detect.
Yes, this is impossible in the general case.
If systemd (or the kernel) is adjusted, then g-s-d may not need a
change. But even then it may still make sense to allow disabling the
new behaviour just to avoid the policy inconsistencies in the short
term.
Yes, I think g-s-d should change too, even if systemd improves, since
it's g-s-d and/or user that sets the policy.
Zbyszek
6:32 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Wed, 2018-10-03 at 13:52 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Oct 02, 2018 at 07:05:45PM +0200, Benjamin Berg wrote:
> So, my proposal from the g-s-d side is:
> 1. For the *stable* release cycle, hide the new "feature" behind a
> compile time switch, disable it by default and announce properly
> in the release notes.
+1, even though a hidden setting key would be even nicer
Alright, upstream merge request to do this is available:
* https://gitlab.gnome.org/GNOME/gnome-settings-daemon/merge_requests/54
This really just disable the feature again thereby working around the
bug.
Benjamin
9:16 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
----- 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)
10:20 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Di, 02.10.18 10:16, Bastien Nocera (bnocera(a)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
--
Lennart Poettering, Red Hat
11:16 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
----- Original Message -----
On Di, 02.10.18 10:16, Bastien Nocera (bnocera(a)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.
11:39 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
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.
8:24 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
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(a)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
4:11 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
----- 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(a)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.
[1] https://github.com/systemd/systemd/pull/10262
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).
6:30 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Thu, Oct 4, 2018 at 11:12 AM Bastien Nocera <bnocera(a)redhat.com> wrote:
(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).
The popular solution to this is to use "vm.swappiness = 1" (or 0) in sysctl.
6:24 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
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(a)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.
>
> [1] https://github.com/systemd/systemd/pull/10262
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
10:12 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Di, 02.10.18 07:26, Justin Forbes (jmforbes(a)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
--
Lennart Poettering, Red Hat
11:02 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Tue, Oct 2, 2018 at 10:12 AM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
On Di, 02.10.18 07:26, Justin Forbes (jmforbes(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to desktop-leave(a)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...
11:50 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Tue, Oct 2, 2018 at 10:02 AM, Justin Forbes <jmforbes(a)linuxtx.org> wrote:
On Tue, Oct 2, 2018 at 10:12 AM, Lennart Poettering
<mzerqung(a)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.
--
Chris Murphy
11:28 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Tue, Oct 2, 2018 at 9:12 AM, Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Di, 02.10.18 07:26, Justin Forbes (jmforbes(a)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.
--
Chris Murphy
10:36 a.m.
New subject: Disabling kernel's hibernate support by default, allow
re-enabling it with a kernel cmdline option
On Tue, 2018-10-02 at 12:53 +0200, Hans de Goede 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(a)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 if we renamed it "MightHibernate"? :)
(only sort-of kidding...)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2020
days inactive
2028
days old
desktop@lists.fedoraproject.org
29 comments
11 participants
participants (11)
-
Adam Williamson -
Anderson, Charles R -
Bastien Nocera -
Benjamin Berg -
Chris Murphy -
Hans de Goede -
Justin Forbes -
Kamil Paral -
Lennart Poettering -
Peter Robinson -
Zbigniew Jędrzejewski-Szmek