New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
coreos-printk-quiet.service
: Lower kernel log level to 4
#1840
Conversation
I do think this change though is most likely something that should actually happen Fedora wide. Upstreaming this module into dracut might be the easiest. |
overlay.d/05core/usr/lib/dracut/modules.d/10coreos-printk/coreos-printk-quiet.service
Outdated
Show resolved
Hide resolved
Out of curiosity, why did you decide against a |
Alternatively...changing https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel-x86_64-fedora.config#_983 to 4 is likely the better way to do this. |
Makes sense to me. It's also easier to disable via Ignition that way. And we'll want to do that for the kola devshell code since I think the state machine there relies on those to know e.g. when to SSH. (But also personally for |
coreos-printk-quiet.service
: Lower kernel log level to 4
OK 🆕 updated
|
Also now updated to explicitly run |
overlay.d/05core/usr/lib/systemd/system/coreos-printk-quiet.service
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
overlay.d/05core/usr/lib/systemd/system-preset/40-coreos.preset
Outdated
Show resolved
Hide resolved
overlay.d/05core/usr/lib/systemd/system/coreos-printk-quiet.service
Outdated
Show resolved
Hide resolved
@@ -0,0 +1,24 @@ | |||
[Unit] | |||
Description=CoreOS: Set printk to level 4 (warn) | |||
Documentation=https://github.com/coreos/fedora-coreos-tracker/issues/1244 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we have proper FCOS docs for overriding this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Obviously not opposed to documentation but...in the current design we honor all the standard Linux APIs for this in kernel arguments and injecting a sysctl.d file. The change of default is notable but it's close to a bugfix.
I think I'd say let's tackle documenting the printk level when we push to do this Fedora wide?
overlay.d/05core/usr/lib/systemd/system/coreos-printk-quiet.service
Outdated
Show resolved
Hide resolved
Closes: coreos/fedora-coreos-tracker#1244 A lot going on for this simple service. See the tracker issue above for more info, but briefly: Anaconda has historically injected `quiet` into the kernel command line in many cases, and this suppresses *both* kernel and systemd output. On computers in general, but particularly many bare metal servers, the serial console can be slow. This can cause reliability issues. However for servers, we usually *do* want to see informational output when they boot. For example, today the kernel "mitigations" information for hardware vulnerabilities is output. This change is a compromise; we boot up at the kernel's default verbosity level (which for Fedora and derivatives is the upstream 7), but switch to 4 very early on in the real root. At that point, we've gotten most of the boot time output, and our initramfs is not extremely performance sensitive right now. Also, we explicitly only *lower* the output log level, and only if there isn't explicitly `debug` on the kernel command line.
Addressed all comments! |
We effectively do this by default now after coreos/fedora-coreos-config#1840
We effectively do this by default now after coreos/fedora-coreos-config#1840
We effectively do this by default now after coreos/fedora-coreos-config#1840
This doesn't work anymore since systemd locked down where generators can write files: [ 9.246494] /usr/lib/systemd/system-generators/coreos-liveiso-autologin-generator: line 24: /etc/sysctl.d/20-coreos-autologin-kernel-printk.conf: Read-only file system But anyway, nowadays this duplicates `coreos-printk-quiet.service` which was added two years after this code was written (coreos#1840). Noticed by Colin in ostreedev/ostree#3158 (comment).
This doesn't work anymore since systemd locked down where generators can write files: [ 9.246494] /usr/lib/systemd/system-generators/coreos-liveiso-autologin-generator: line 24: /etc/sysctl.d/20-coreos-autologin-kernel-printk.conf: Read-only file system But anyway, nowadays this duplicates `coreos-printk-quiet.service` which was added two years after this code was written (#1840). Noticed by Colin in ostreedev/ostree#3158 (comment).
This doesn't work anymore since systemd locked down where generators can write files: [ 9.246494] /usr/lib/systemd/system-generators/coreos-liveiso-autologin-generator: line 24: /etc/sysctl.d/20-coreos-autologin-kernel-printk.conf: Read-only file system But anyway, nowadays this duplicates `coreos-printk-quiet.service` which was added two years after this code was written (coreos#1840). Noticed by Colin in ostreedev/ostree#3158 (comment).
Closes: coreos/fedora-coreos-tracker#1244
A lot going on for this simple service. See the tracker issue above
for more info, but briefly:
Anaconda has historically injected
quiet
into the kernel commandline in many cases, and this suppresses both kernel and systemd
output. On computers in general, but particularly many bare metal
servers, the serial console can be slow. This can cause reliability
issues.
However for servers, we usually do want to see informational
output when they boot. For example, today the kernel "mitigations"
information for hardware vulnerabilities is output.
This change is a compromise; we boot up at the kernel's default
verbosity level (which for Fedora and derivatives is the upstream 7),
but switch to 4 very early on in the real root. At that point, we've
gotten most of the boot time output, and our initramfs is not
extremely performance sensitive right now.
Also, we explicitly only lower the output log level, and only if
there isn't explicitly
debug
on the kernel command line.