On Friday, December 6, 2019 11:22:34 AM MST Chris Murphy wrote:
On Fri, Dec 6, 2019 at 7:46 AM John M. Harris Jr
> On Thursday, December 5, 2019 8:12:13 PM MST Chris Murphy wrote:
> > Using the word to be defined in the definition is insufficient and
> > vague. It's meaningless.
> > Feature existence is not support. The community members make a thing
> > supported, and it's only by community effort and prioritization that
> > features are supported. The track record of hibernation support, such
> > as it is, is best effort, but not blocking. If it breaks, Fedora ships
> > with it broken. There are flat out not enough resources to treat it
> > with any higher priority than this - it's not a new issue either.
> Nonetheless, it is "supported" in Fedora.
And now you're using private terminology, and it amounts to denialism
and arguing rather than issue progression. It's tedious and makes the
conversation as pointless as talking to a wall.
If anything, you're the one with a weird definition of the term. It's
supported in Fedora. It's there. Out of box. It seems it's not supported on a
specific configuration, from what you've provided, but it's supported on the
vast majority of systems, where that specific configuration is not in use.
And likewise there are minimum expectations of reliability for
something to be enabled by default, and hibernation does not qualify.
And yet, it's enabled by default.
In the first paragraph you correctly state Secure Boot limits what
boots to code that's been signed by Fedora's signing key (or
alternatively user keys, if so configured).
No, I describe it as relying on vendor keys. This is a fundamental flaw in
And in the second you describe a means of thwarting Secure Boot by
permitting arbitrary code execution, and advocate for this by default, while
also questioning the decision making capacity of others.
Bypassing a flawed system, which was originally designed to limit the
operating systems that could be installed on hardware. Please do not forget
the history of "Secure Boot", or it's original intentions.
What does encryption have to do with it? Do you think encryption
mimics or is akin to code signing? Does it provide error detection or
error correction? If you change a single block of encrypted data do
you think upon decryption there's EIO or some kind of warning?
If the swap partition is encrypted, it's not possible to modify it in a manner
that would compromise security, only in a manner which would make the data
invalid, and only if using `discard` for that luks container.
You're making excuses for an unprivileged process fork bombing a
default installation. And you're also changing the goal post by
blaming the user.
If the user chooses to run something, that's up to them. I've given you the
The topic, set by you, is the assertion that you've never seen a
system freeze up when swap size is at least 1x RAM. I have provided a
reproducer that contradicts this. And instead of acknowledging that,
either at face value or testing it yourself, you proceed with totally
off topic distractions that also blame the user.
That's simply not the case. I explained that what you provided is easily
mitigated, with proper configuration. It is a non-issue.
It's a debate style that is intended to generate more debate
conclusion or progression of the issues, and I consider it
Again, a solution to the problem was provided. If you have an issue with it,
we can discuss that off-list, or in a new thread specific to that issue. A
more relevant mailing list for that would be fedora-users, where users
commonly ask for assistance with configuration.
> That's because it is supported. It works out of box, and
several DEs even
> have a button for it. I don't know if GNOME does, but the GNOME Spin has
> always been a bit special.
More private terminology, as if you think repeating it will make it
stick. The difference with my repetition is it's backed by dozens of
conversations among various developers and stakeholders in the Fedora
community considering it not supported, it isn't me personally
asserting a belief or fantasy.
What are you suggesting is "private terminology", other than "GNOME
know that I'm referring to what others call "Workstation", which is a
in my opinion.
It's simply false to say that hibernation is not supported. Not only is it
supported, there's a big button for it in the major DEs. I have not tested
GNOME, but I'd be willing to be it's there, unless something has changed with
the shutdown menu since the version of GNOME 3 used in RHEL 7. Please do let
me know if GNOME is missing that button in Fedora, so that I may open a
feature request on behalf of GNOME users in Fedora.
It doesn't work out of the box with sufficient consistency or
predictability to consider it supported or supportable. You'll find
myriad upstream and downstream bug reports about hibernation that
languish indefinitely. Some do get fixed. Whether it works depends on
make/model, the firmware revision, and kernel version.
See above. It works out of box. I will take that further to say that it works
consistently, so long as you don't select a different kernel image to resume.
On some hardware, you would be correct that hibernation does not work, but
that is not the case with most systems, and is irrelevant of the degree to
which Fedora supports it, which is that the option is available for use in the
major DEs and on the command line.
A common theme in the discussion thread I cite earlier in this
is corrupt hibernation images on resume. I have two computers that
exhibit this behavior. I do not consider that it works out of the box
at all. If I take a very selfish point of view about only my
experiences I would say it's 100% broken out of the box.
I make no claims as to the reliability of hibernation, I cannot test that on
all hardware. I make no claims to ones ability to even run the Linux kernel on
all hardware. I don't have enough hardware to test support on a wide variety
of systems, and I would not claim that it works or does not work based solely
on the systems that I have available.
But being one to recognize the lay of the land is complex, I
take only my own experiences to be the way of things, like you are.
I'm not dismissive of other people's experiences, as you are. I use an
inclusive language: it works for some, it doesn't work for others.
It's sufficiently unreliable and unpredictable that it cannot
reasonably be considered supported or supportable on Fedora without
either a lot more resources, or a white list of hardware.
Well, hold on. I don't either, but I also don't claim that something which is
clearly supported is not, simply because there is not a release blocker for
it, an arbitrary criterion. It is supported in Fedora, and that's the extent
of it. As Fedora contributors, we cannot possibly test all hardware
configurations, and to create a whitelist of hardware to allow hibernation on
would be absurd. Perhaps a blacklist, based on user reports, but that's all I
could suggest there.
Your style of debate is grating and can be summarized as: 'I am
right and you are always wrong, you should do things my way because
you are doing it wrong and everyone doing things differently than I
want them is wrong and misguided.'
I make no claims at being right. You may notice that, in other threads, and at
certain points in this thread, I have learned something about a part of the
stack that I don't work with, like UEFI + Secure Boot specific kernel
limitations. You were the one that brought that to my attention, which has led
to my writing a note to open a bug report.
Unless I have a solution in mind, or the suggestion of somebody else would
break either my workflow or the workflow of the users I support, or I view it
as a breaking change for Fedora's silent majority userbase, I generally don't
like to pipe in on these things, because people often see those taking issue
with their suggestions as hostile. That seems to be the case here. I intend no
hostility, I'm just trying to suggest a better way, that doesn't needlessly
> The only time it wouldn't work seems to be in one of those
special UEFI +
> Secure Boot cases.
It's not special. It happens to be the default firmware and
configuration of most new x86_64 hardware, and the default policy upon
installation by Fedora.
That is simply not the case. While most new consumer x86_64 hardware comes
with UEFI on by default, unless it came with Windows installed, Secure Boot is
As for "default policy upon installation by Fedora", what the GNOME Spin
chooses to do is not the same as what Fedora as a whole does.
And that means hibernation is not presently possible by default on
Simply because somebody decided to disable the feature, as a "security"
There is no agreement by distributions how to handle hibernation
signing that upstream will accept and Fedora isn't likely to carry out of
tree patches for such a thing.
There's no need to sign the hibernation image to
begin with. That is an
arbitrary requirement that has been thrown in for absolutely no reason that I
can think of. You're not booting from the hibernation image. It doesn't need
to be signed to comply with the absurd requirements of "Secure Boot".
John M. Harris, Jr.