Hi All,
As some of you have probably heard I'm working on making Fedora be less "chatty" during boot, part of this is:
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu
But that only makes grub quiet.
We've been passing to the kernel for a long time for the same reasons. Unfortunately quiet is not really always quiet.
There are simply many false-positive or at least completely harmless messages printed by the kernel with a loglevel of KERN_ERR. Currently we display all these. For at least the last year or so I've been sending patches to the upstream kernel to silence these, but new ones always pop up. So this is an endless and hopeless game of whack-a-mole.
Therefor I propose to instead of keep whacking the moles, we change the loglevel associated with "quiet" from 4 to 3, so that only messages with a higher severity then KERN_ERR (CRIT, ALERT, EMERG) get printed on the console.
Note all messages will still be available in dmesg and the journal. This is purely about which messages get printed on the console and thus get thrown in the users face.
Besides improving the boot experience by not needlessly showing scary messages to end users, this should also help to reduce the amount of bugs we receive about these kind of errors. Here is a quick and in no way complete list of bugs which I believe fall into this category:
1413342 - Linux 4.9.3: ACPI Error: [_OSI] Namespace lookup failure, AE_NOT_FOU 1415853 - ACPI Error: Namespace lookup failure, AE_NOT_FOUND (20160831/psargs- 1514937 - ACPI Error: AE_NOT_FOUND 1527870 - ACPI Error: [_SB_.PCI0.SAT1] Namespace lookup failure, AE_NOT_FOUND 1552580 - ACPI Error: Method parse/execution failed 1553320 - Kernel errors at bootup -- system runs okay 1556967 - ACPI Error: [SMIC] Namespace lookup failure, AE_ALREADY_EXISTS 1582825 - ACPI Error: Method parse/execution failed https://bugzilla.kernel.org/show_bug.cgi?id=109511 https://bugzilla.kernel.org/show_bug.cgi?id=194687
Esp. the bugzilla.kernel.org ones are interesting and then esp.:
https://bugzilla.kernel.org/show_bug.cgi?id=109511 109511 - ACPI error messages caused by undefined object - Dell XPS 13 9350
Which is about a completely harmless ACPI DSDT problem which many machines have, resulting in an AE_NOT_FOUND error. I've done multiple attempts to get the upstream ACPICA people to drop the loglevel of AE_NOT_FOUND errors to KERN_WARNING, also see the 194687 bug. But upstream ACPICA refuses to change this instead insisting that:
a) Vendors should fix there DSDTs to be perfect; and b) end-users should then update their BIOS to fix this
Neither of which is a realistic expectation in anyway, this just goes to show that getting the kernel to not log harmless errors is a loosing proposition.
###
TL;DR: kernel is still too verbose at loglevel 4, lets change quiet to mean 3. To achieve this without needing downstream patches I've posted a patch upstream to make this configurable from Kconfig:
https://lkml.org/lkml/2018/6/19/462
My question to the Fedora kernel team now is, are you ok with changing the log-level associated with "quiet" from 4 to 3?
I can take care of making the necessary changes.
Regards,
Hans
On Tue, Jun 19, 2018 at 8:02 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi All,
As some of you have probably heard I'm working on making Fedora be less "chatty" during boot, part of this is:
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu
But that only makes grub quiet.
We've been passing to the kernel for a long time for the same reasons. Unfortunately quiet is not really always quiet.
There are simply many false-positive or at least completely harmless messages printed by the kernel with a loglevel of KERN_ERR. Currently we display all these. For at least the last year or so I've been sending patches to the upstream kernel to silence these, but new ones always pop up. So this is an endless and hopeless game of whack-a-mole.
Therefor I propose to instead of keep whacking the moles, we change the loglevel associated with "quiet" from 4 to 3, so that only messages with a higher severity then KERN_ERR (CRIT, ALERT, EMERG) get printed on the console.
Note all messages will still be available in dmesg and the journal. This is purely about which messages get printed on the console and thus get thrown in the users face.
Besides improving the boot experience by not needlessly showing scary messages to end users, this should also help to reduce the amount of bugs we receive about these kind of errors. Here is a quick and in no way complete list of bugs which I believe fall into this category:
1413342 - Linux 4.9.3: ACPI Error: [_OSI] Namespace lookup failure, AE_NOT_FOU 1415853 - ACPI Error: Namespace lookup failure, AE_NOT_FOUND (20160831/psargs- 1514937 - ACPI Error: AE_NOT_FOUND 1527870 - ACPI Error: [_SB_.PCI0.SAT1] Namespace lookup failure, AE_NOT_FOUND 1552580 - ACPI Error: Method parse/execution failed 1553320 - Kernel errors at bootup -- system runs okay 1556967 - ACPI Error: [SMIC] Namespace lookup failure, AE_ALREADY_EXISTS 1582825 - ACPI Error: Method parse/execution failed https://bugzilla.kernel.org/show_bug.cgi?id=109511 https://bugzilla.kernel.org/show_bug.cgi?id=194687
Esp. the bugzilla.kernel.org ones are interesting and then esp.:
https://bugzilla.kernel.org/show_bug.cgi?id=109511 109511 - ACPI error messages caused by undefined object - Dell XPS 13 9350
Which is about a completely harmless ACPI DSDT problem which many machines have, resulting in an AE_NOT_FOUND error. I've done multiple attempts to get the upstream ACPICA people to drop the loglevel of AE_NOT_FOUND errors to KERN_WARNING, also see the 194687 bug. But upstream ACPICA refuses to change this instead insisting that:
a) Vendors should fix there DSDTs to be perfect; and b) end-users should then update their BIOS to fix this
Neither of which is a realistic expectation in anyway, this just goes to show that getting the kernel to not log harmless errors is a loosing proposition.
###
TL;DR: kernel is still too verbose at loglevel 4, lets change quiet to mean 3. To achieve this without needing downstream patches I've posted a patch upstream to make this configurable from Kconfig:
https://lkml.org/lkml/2018/6/19/462
My question to the Fedora kernel team now is, are you ok with changing the log-level associated with "quiet" from 4 to 3?
I can take care of making the necessary changes.
I think it is fine, the first thing we do when getting information from people debugging an issue is ask for dmesg, or if it is early boot and they don't get a terminal, we ask them to remove quiet. Basically it should make the user experience better, and have no impact on our ability to track down issues.
Justin
Hi,
On 06/19/2018 09:02 AM, Hans de Goede wrote:
Hi All,
<snip>
TL;DR: kernel is still too verbose at loglevel 4, lets change quiet to mean 3. To achieve this without needing downstream patches I've posted a patch upstream to make this configurable from Kconfig:
https://lkml.org/lkml/2018/6/19/462
My question to the Fedora kernel team now is, are you ok with changing the log-level associated with "quiet" from 4 to 3?
I can take care of making the necessary changes.
Sounds like a good plan to me, I'm all for it.
Thanks, Jeremy
Hi,
On 19-06-18 18:45, Jeremy Cline wrote:
Hi,
On 06/19/2018 09:02 AM, Hans de Goede wrote:
Hi All,
<snip>
TL;DR: kernel is still too verbose at loglevel 4, lets change quiet to mean 3. To achieve this without needing downstream patches I've posted a patch upstream to make this configurable from Kconfig:
https://lkml.org/lkml/2018/6/19/462
My question to the Fedora kernel team now is, are you ok with changing the log-level associated with "quiet" from 4 to 3?
I can take care of making the necessary changes.
Sounds like a good plan to me, I'm all for it.
Ok, so hopefully the patch will go upstream without too much trouble.
My plan is to wait for the patch, which I linked above, to be in -next and add it to the Fedora kernels as a downstream patch for Fedora-29, which can then be dropped on the next kernel rebase. Is that ok?
Regards,
Hans
On 06/19/2018 03:57 PM, Hans de Goede wrote:
Hi,
On 19-06-18 18:45, Jeremy Cline wrote:
Hi,
On 06/19/2018 09:02 AM, Hans de Goede wrote:
Hi All,
<snip>
TL;DR: kernel is still too verbose at loglevel 4, lets change quiet to mean 3. To achieve this without needing downstream patches I've posted a patch upstream to make this configurable from Kconfig:
https://lkml.org/lkml/2018/6/19/462
My question to the Fedora kernel team now is, are you ok with changing the log-level associated with "quiet" from 4 to 3?
I can take care of making the necessary changes.
Sounds like a good plan to me, I'm all for it.
Ok, so hopefully the patch will go upstream without too much trouble.
My plan is to wait for the patch, which I linked above, to be in -next and add it to the Fedora kernels as a downstream patch for Fedora-29, which can then be dropped on the next kernel rebase. Is that ok?
Laura is the 4.18 maintainer so whatever she wants to do. It sounds fine to me, though.
- Jeremy
kernel@lists.fedoraproject.org