I keep getting this weird behavior on Fedora 29 for which there are no
journal messages at all. This is the setup:
1. on battery power
2. Settings>Power>Blank Power = 5 minutes
3. Settings>Power>Dim Screen when inactive = On
4. Settings>Power>Automatic Suspend>Battery = On, 15 minutes
5. Use is inactive for more than 5 minutes, and less than 15. (At 15
minutes it definitely goes into suspend successfully).
6. I look up and see the GNOME lock screen with multiple yakyak
notifications, and also see a power notification (international stop
sign symbol). The power notification doesn't itself make the display
come on, it's yakyak. If I don't receive an incoming message on
yakyak, I have no idea the power notification is present. And if I
take a screenshot while the display is off, the screenshot file is all
7. The instant I click on any key or the trackpad, only the power
notification vanishes. The yakyak message remain in the list, and once
I log back into my user session, the power notification is not in the
drop down list of notifications when clicking on the time. And yet all
the yakyak notifications are in the list.
8. Nothing in the journal related to power
Is there a way to make the environment spit out more verbose messages
into the journal? I don't see a debug or verbose option with
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:
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,
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?
Hi Benjamin, Carlos,
I'm mailing you 2 because you maintain g-s-d now.
As discussed on the Fedora desktop mailinglist in the
"system now hibernates automatically 3 hours after suspend ?"
thread, the suspend-then-hibernate behavior is not really
ready for mainstream use yet (according to the systemd folks).
Also from a kernel pov all of a sudden using hibernate is
a huge change and involves code paths which no other major
distro has been using sofar.
So we really need to disable this for Fedora 29. And as
mentioned in the thread when we decide to enable this for
a future release, it really needs to go through the changes
process so that it is well document we are changing this
and people will have a clue what is the likely culprit
if leaving their laptop suspend for > 3h all of a sudden
You are kindly invited to the meeting:
Silverblue on 2018-10-01 from 09:00:00 to 10:00:00 US/Eastern
The meeting will be about:
Fedora Silverblue IRC meeting in #fedora-meeting-2 on Freenode. Fedora Silverblue is an rpm-ostree-based Fedora desktop edition.
So, Beta RC4 is out there and being tested (thanks for all the testing
so far). There is an RC5 coming too: here's why.
We haven't found any blockers in RC4 yet, but we did find several not-
quite-blockers that seemed bad. First of all, the Silverblue (formerly
known as Atomic Workstation) installer image build failed due to a
network blip, so RC4 does not have that image. If we ship RC4 as the
Beta, we wouldn't have a Silverblue installer for the Beta at all
(unless we did some ugly hack to stuff some other image in), and that
seems bad - the image isn't release-blocking, but it is a major area of
development and we really ought to include it in Beta.
Beyond that, we happened to run into and find fixes for quite a slew of
bugs in gnome-shell, plus a couple in gtk+ and mesa that are quite
visible too. Here's a list of all the bugs in question:
So nirik, mboddu and I agreed it'd be reasonable to run a Beta RC5 to
give us at least the option of shipping a compose with the Silverblue
image and fixes for all those bugs, if everything goes well. As there
aren't any outright blockers in it, Beta RC4 is still a candidate for
Beta RC5 should complete in ten hours or so. There should be no
difference between Beta RC4 and Beta RC5 outside of GNOME and the mesa
fix, so most RC4 tests should be valid for RC5 too.
So, please continue testing RC4. Once RC5 arrives, go ahead and test
that too, prioritizing smoke tests, tests of GNOME, and any Basic /
Beta tests not yet run against RC4. It is not a high priority to run
tests on RC5 that have already been run on RC4, unless they're basic
smoke tests or GNOME tests.
Thanks a lot, everyone!
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net