Bug 217226
| Summary: | 'quiet' kernel parameter is not really quiet at all | ||
|---|---|---|---|
| Product: | Other | Reporter: | guimarcalsilva |
| Component: | Configuration | Assignee: | other_configuration (other_configuration) |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | ||
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | Subsystem: | ||
| Regression: | No | Bisected commit-id: | |
|
Description
guimarcalsilva
2023-03-21 22:51:06 UTC
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). |