Those are kernel messages. You can turn them off by passing quiet or console_loglevel=5 on the kernel commandline.

We might actually want to do that automatically, maybe by invoking dmesg -n in the getty unit. Thoughts, anyone?

So far we are very careful with messing with the defaults of the kernel.

People have different expectations and configure their kernel to that, and
unless we have a really good reason, we should leave these setting alone.

There is CONFIG_DEFAULT_MESSAGE_LOGLEVEL= in the kernel compile-time config,
that should be changed if we are sure we want a different default.

The kernel's log behavior is controlled by:
  /proc/sys/kernel/printk
see:
  man 5 proc

But, isn't systemd able to redirect that messages to journalctl or filter them? (kernel would still show the messages but they would be put in journalctl, that is what probably most people will prefer instead of losing the messages completely)

(In reply to comment #3)
> But, isn't systemd able to redirect that messages to journalctl or filter
> them? (kernel would still show the messages but they would be put in
> journalctl, that is what probably most people will prefer instead of losing
> the messages completely)
Yes, but putting messages in the kernel log buffer is independent. Here we're only talking about the output that kernel is doing to the kernel console.

The kernel's use of the console is entirely unrelated to what it stored
in the kernel log buffer (the stuff you see with dmesg) or what is imported
into the journal (the kernel stuff journalctl shows).

The messages will always end up in the kernel buffer and the journal, even
when the output is suppressed from the console. There is no re-direct, or
anything needed, systemd does not need to read the console, it's all in the
kernel log buffer anyway.

Note: The way the kernel puts stuff to the console and the default level of
showing almost everything comes from a time where it was exciting that the
kernel booted at all on a box, and Linux was used by people who ran their
self-compiled kernels and were happy that they could watch it doing its job. :)

No idea how openRC is able to filter that messages then :|

It probably writes to:
  /proc/sys/kernel/printk
at bootup and just disables the kernel messages at the console, there is no
specific filtering of messages besides the log-level, right?

OpenRC runs 'dmesg' to set the level:
  dmesg_level="1"
  dmesg -n$dmesg_level

http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=blob;f=init.d/dmesg.in;hb=HEAD

Was just asking for that in #openrc IRC channel ;)

There isn't anything to fix in systemd here. If you want to get rid of these messages then boot with "quiet" on the kernel command line or drop in a /etc/sysctl.d/ snippet that fiddles with the "kernel.printk" variable. But systemd shouldn't do anything like that by default I am sure. This should be kernel configuration, boot-time configuration or user configuration, but not systemd overrides.

How about doing what openrc does? That is, add a unit that calls dmesg -n4 or so at a very early point in the boot process. This way systemd would behave the same way no matter how the kernel was configured.

egorov-ey ~ # cat /etc/{conf,init}.d/dmesg
# Sets the level at which logging of messages is done to the
# console.  See dmesg(1) for more info.
dmesg_level="1"
#!/sbin/runscript
# Copyright (c) 2007-2008 Roy Marples <roy@marples.name>
# Released under the 2-clause BSD license.

description="Set the dmesg level for a cleaner boot"

depend()
{
        before dev modules
        keyword -lxc -prefix -vserver
}

start()
{
        if [ -n "$dmesg_level" ]; then
                dmesg -n$dmesg_level
        fi
}
egorov-ey ~ # ls -l /etc/runlevels/sysinit/dmesg
lrwxrwxrwx 1 root root 17 мая   10  2012 /etc/runlevels/sysinit/dmesg -> /etc/init.d/dmesg
egorov-ey ~ #

I'm sorry, did not notice the comment #8

Created attachment 83017 [details]
dmesg.service

Simpe fix for me.