----- Original Message -----
On Fr, 14.09.18 10:45, mcatanzaro(a)gnome.org (mcatanzaro(a)gnome.org)
> On Fri, Sep 14, 2018 at 10:16 AM, Ray Strode <rstrode(a)redhat.com> wrote:
> > But that's bonkers, there's no way systemd can know either.
> > The only way to make this reliable is if the kernel has a dedicated
> > hibernate
> > partition the same size as ram that doesn't get used for anything but
> > hibernate, right?
> I think I agree with Ray... the Workstation kernel should not offer this at
> all unless it can be made reliable.
I tend to agree with this actually. I mean, I can understand why the
GNOME folks don't want to expose an opt-in option for this, and want
the lower layers to disable it. In fact I understand it so well, that
I also would prefer if the lower layer from my own systemd PoV
(i.e. the kernel) wouldn't offer us a feature that is known to be
broken and unsupported.
Hence, I think that Fedora kernels should really turn off hibernation
support entirely during compilation if there's no intention to really
support it. This could be done either by compiling out the whole
subsystem's code for it, or maybe with a kernel patch that adds a
kernel cmdline or so, that must be specified to enable this code in
For all other interfaces the kernel provides we assume that it works
correctly if systemd can call into it. It *is* kinda weird if the
hibernation APIs the kernel provides are made available but actually
are not assumed to work properly.
Strongly agreed. Having systemd disable it meant that it could be enabled
and tested without either non-standard commands (whether a kernel option,
a special systemd command, or a GNOME non-UI option), or needing a kernel
There's a "nohibernate" kernel command-line option, but the code
seem to be well thought out to allow changing the default value:
(declaration near the top of the file, and options handling at the bottom)
Maybe this is enough?
-static int nohibernate;
+static int nohibernate = 1;