Systemd non-error message ignores quiet parameter

[Zepmann]

systemd version the issue has been seen with

258-4

Used distribution

Arch Linux

Linux kernel version used

6.16.8-arch3-1

CPU architectures issue was seen on

x86_64

Component

systemd

Expected behaviour you didn't see

Credit to @x140x1n, who created the first bug report that was closed too quickly.

When a system is booted with kernel command-line parameters "quiet" and a low enough log level, systemd should not show non-error, non-warning messages.

Unexpected behaviour you saw

The message I see during early boot is described by and discussed in #39150. As noted by @yuwata in that issue, this is just a log message. Not a warning, not an error.

I see this message with different tested kernel log levels. Descriptions based on this:

• The first log level is 0, identified by the KERN_EMERG string. This is the highest level in order of severity: it’s adopted by messages about system instability or imminent crashes.
• Loglevel 1, or KERN_ALERT it’s what comes immediately after. This level is used in situations where the user attention is immediately required.
• Loglevel 3, also identified by the KERN_ERR string, it’s the next in the scale. Messages adopting this level are often used to notify the user about non-critical errors, as for example a failed or problematic device recognition, or more generally driver-related problems.

The message is not an error, not even a non-critical error. The system works fine. There is no reason to show this message. I suspect that the kernel log level and quiet parameters are ignored.

Steps to reproduce the problem

The way I tested:

1. Install Arch Linux on a computer with a TPM and (likely) an older firmware missing a certain non-critical TPM feature. I tested this with EFISTUB and a unified kernel image.
2. Boot the system with the TPM enabled in the firmware.
3. Observe the message during boot.

This is especially annoying with a "quiet" Plymouth boot, since the message cannot be avoided unless the TPM is disabled/hidden, which is an unacceptable workaround for obvious reasons.

Additional program output to the terminal or log subsystem illustrating the issue

[lorenmntlla]

The log message being described is issued in systemd-boot, before the bootloader had the opportunity to boot the kernel. Since the bootloader isn't controlled by kernel parameters, it isn't ignoring anything.

I'm actually having this message myself, and it would be nice to disable its appearance (or the appearance of log messages on sd-boot altogether) via a configuration option in loader.conf.

[qwertviop]

I'm actually having this message myself, and it would be nice to disable its appearance (or the appearance of log messages on sd-boot altogether) via a configuration option in loader.conf.

This has actually already been merged in #38701 and will be part of v259, which also sets the default log level to LOG_INFO, so this particular message would not be shown anymore. But unless you backport this PR, that will not help you much. You might be able to convince your package maintainer to patch the call to log_debug() out, if only because it introduces a 2.5s boot delay.

[poettering]

The message is a debug log message, and those are not shown by default, at least in git main. hence there's nothing to fix. My guess is that you have a hosed backport or so on your system, which either didn't backport the new logging logic in sd-boot that hides debug messages by default, or it didn't remove the log message to avoid the problem. either way, git main seems to be fully correct on all of this, hence closing.