On Tue, Jun 19, 2018 at 8:02 AM, Hans de Goede <hdegoede@xxxxxxxxxx> 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 _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx/message/NVDM2JS76DX62UMSCC245KNYGWXRYDV3/
