kernel September 2018

kernel@lists.fedoraproject.org

6 participants
4 discussions

Disabling kernel's hibernate support by default, allow re-enabling it with a kernel cmdline option
by Hans de Goede 08 Oct '18

08 Oct '18

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

10 27

UEFI Secure Boot inhibits basic graphics?
by Chris Murphy 17 Sep '18

17 Sep '18

Hi, This looks intentional, as it's a lockdown related to Secure Boot, but it also constitutes a blocking bug because Fedora has a Basic Release criterion for basic graphics. Can someone from the kernel team please advise? https://bugzilla.redhat.com/show_bug.cgi?id=1628495 -- Chris Murphy

2 2

Headsup: Adding "efi/x86: Call efi_parse_options() from efi_main()" to F29+ kernels
by Hans de Goede 13 Sep '18

13 Sep '18

Hi, I've been getting some reports that the kernel is not fully quiet / the boot is not fully smooth / flickerfree when using secure boot. This is fixed by this patch: https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/commit/?id=ecb7… I believe that this patch is safe, so I plan to add it as downstream patch to the F29+ kernels for now. But this is early boot code so you never know. Hence the heads-up, if there are mysterious boot failures this might be the culprit (it would be weird if it is, but you never know). Regards, Hans

2 1

4.18 Rebase plans
by Laura Abbott 08 Sep '18

08 Sep '18

Hi, As you probably saw, 4.18 was released on Sunday. The 4.18 kernel was built for rawhide yesterday. We will be following roughly the same rebase schedule as in the past. F28 will get the rebase first, typically around 4.18.2 or 4.18.3 followed by F27 shortly thereafter. My best guess for when this would happen would be middle of September. As always, we'll keep you updated on any new developments. Thanks, Laura P.S. As a general reminder, if you like F27 please remember to give karma to kernels.

5 13

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel September 2018