The 'quiet' kernel parameter used by most desktop-oriented Linux distributions fails to do what it implies most of the time. When that configuration option is enabled it's expected to suppress any kind of superfluous log message, however, that is often not the case. Most desktop-oriented Linux distributions enable that flag specifically to make the boot process more seamless, but in its current state, that Kernel parameter fails to do that most of the time. The vast majority of messages that are shown to users are non-actionable or are just warnings with little to no relevance to users since the computers still work normally despite them. The messages 'quiet' fail to suppress are numerous. They vary from ACPI errors to filesystem checks, to warnings about firmware options (e.g. Intel SGX being disabled), system status messages (e.g. Broadcast messages about shutting down/rebooting, possibly by systemd?), and much more. I've gathered throughout the last few months many examples of people seeing those messages during boot, even though their distribution enables the 'quiet' flag to prevent that exact scenario from happening. I also added some searches that show the thousands of people that noticed the same problem and the myriad of workarounds that are needed to achieve the desired effect. Workarounds (meaning there is a demand to suppress those messages): https://wiki.archlinux.org/title/silent_boot ----------- Search results with thousands of people talking about kernel messages on boot: https://www.google.com/search?q=linux+acpi+errors+on+boot https://www.google.com/search?q=linux+poweroff+now+broadcast+message https://www.google.com/search?q=linux+boot+sgx+disabled+by+bios https://www.google.com/search?q=linux+boot+clean+files+blocks https://www.google.com/search?q=linux+mtd+device+boot+message https://www.google.com/search?q=linux+read+log+page+failed+message https://www.google.com/search?q=linux+integrity+problem+loading+certificate and many more kinds of messages... ---------- Reddit posts I compiled in the past few months just by browsing Linux subreddits (I didn't search for them, which shows how much of a nuisance for people that is): https://www.reddit.com/r/Ubuntu/comments/100pyii/reboot_error/ https://www.reddit.com/r/Ubuntu/comments/wu1a3g/help_this_shows_up_every_time_i_boot_my_pc_does/ https://www.reddit.com/r/Ubuntu/comments/wvij75/this_shows_up_every_time_in_bootup_screen/ https://www.reddit.com/r/Ubuntu/comments/wwebyw/what_does_the_writing_on_the_picture_mean_guys/ https://www.reddit.com/r/Ubuntu/comments/wwey13/whats_the_cause_of_this_how_to_fix_it/ https://www.reddit.com/r/linux/comments/z55yq8/error_while_booting_ubuntu_everytime/ https://www.reddit.com/r/Ubuntu/comments/z719xl/could_anyone_help_me_with_this/ https://www.reddit.com/r/Ubuntu/comments/zutvre/ubuntu_startup_error_message_acpi_bios_error/ https://www.reddit.com/r/archlinux/comments/id10mj/almost_completely_silent_boot_but/ https://www.reddit.com/r/archlinux/comments/sgdsem/systemd_silent_boot_and_reboot/ If this bug report is too broad to be actionable or if this is not truly the kernel's fault, please tell me what's to blame for those messages so I can make bug reports in the right places. Thank you for your attention and time.
It's near impossible to work through all the cases when messages are "real" and when they are "bogus" and "non-actionable" like you said. You can suppress all the kernel messages if you want - open a bug report with your distro: loglevel=3 (or even 2, 1, 0)
(In reply to Artem S. Tashkinov from comment #1) > It's near impossible to work through all the cases when messages are "real" > and when they are "bogus" and "non-actionable" like you said. > > You can suppress all the kernel messages if you want - open a bug report > with your distro: > > loglevel=3 (or even 2, 1, 0) Thank you very much for your suggestion. loglevel=3 seems to work for my specific boot messages. The problem with filling a bug report for individual distros is that this affects all of them in a way or another. From the kernel side, do you think it would make sense to set the loglevel to 3 (or 2,1,0) implicitly by default when the quiet parameter is enabled? (distros could still override that value by setting their preferred loglevel explicitly). Currently, it doesn't make much sense to use the 'quiet' parameter unless it does what the name implies by default.
You seem to be concerned about your own case while not recognizing that other people may have real actionable error/warning messages shown on the screen when the quiet option is enabled. It literally takes under a minute to add loglevel=3 to your GRUB options and forget about the issue :-) "Quiet" works as expected. What you see are warnings which are expected to be shown/seen.
(In reply to Artem S. Tashkinov from comment #3) > You seem to be concerned about your own case while not recognizing that > other people may have real actionable error/warning messages shown on the > screen when the quiet option is enabled. It literally takes under a minute > to add loglevel=3 to your GRUB options and forget about the issue :-) > > "Quiet" works as expected. What you see are warnings which are expected to > be shown/seen. Those messages are undoubtedly a problem for many people, not only me, as evidenced by the links I posted and the huge amount of people that see those messages at boot and think their system is broken. This is especially true for user-oriented distributions (and the ones that come preinstalled in hardware), where we can't assume users have any technical knowledge to decipher the meaning of those messages or set the loglevel to a lower value. As you said, it would be pretty hard to check all possible messages and classify them as useful or not. In that case, I don't see an easy solution for this on the Kernel side. I'll probably try to discuss this with some of the most well known user-oriented distributions and see if someone has any ideas. Thank you for triaging this bug report.
Here's another very serious issue. The Linux kernel often sees serious regressions, some of which result in not being about to boot or see anything on the screen (GPU drivers). If you set loglevel to 3 it's quite possible that a new kernel update which could print some warnings/errors on the screen will instead become completely quiet for you, thus you won't be able to recognize the issue or understand what's going on. Unlike Windows where Microsoft has employed the WHQL certification program for over a decade now, Linux has no alternative. Stable Linux kernel releases, e.g. 6.2.4 sometimes have deal-breaking regressions because some developer tested only a single piece of hardware while not taking into account all the possible devices the particular driver is responsible for. I've no idea how this can be resolved unless companies such as AMD and Intel take Linux even more seriously and dedicate considerable resources to regression/hardware testing. In almost every kernel release over the past three decades at least one piece of hardware, often more, has been broken one way or another. If you're a user of RHEL, you can perfectly afford hiding these warnings because during the lifetime of a single RHEL release, you have the same kernel and only minor fixes and backports (i.e. backported drivers from newer kernel releases which are extremely unlikely to result in regressions).