When booting into Linux, there are sometimes one or two lines that get quickly cleared. I think that some of them don't even appear in dmesg. If nothing else, I want to suppress the clear before the "login:" prompt. Is there a kernel command or sysctl that I can set to prevent this so I can read them on the console screen after booting?

  • Doesn't /var/log/kern.log help? Or you don't have it?
    – HUB
    Apr 5, 2011 at 16:42
  • See /var/log/boot.log for the missed messages, in case you've not yet managed to prevent the console clearing.
    – Samveen
    Aug 26, 2020 at 1:25

5 Answers 5


Most of the information you want will be in /var/log/dmesg and /var/log/messages after the system boots, you should check those files first.

Generally linux machines run mingetty for the virtual terminals. If you have a traditional sysv init system, those are controlled by /etc/inittab. You can add the --noclear option to mingetty to prevent clearing the screen. To do this, edit /etc/inittab and change this line:

1:2345:respawn:/sbin/mingetty tty1


1:2345:respawn:/sbin/mingetty --noclear tty1

then reboot the machine.

Some newer linux distros use init replacements like Upstart (for example, Ubuntu). These generally don't use /etc/inittab and instead use some other config files. Here's a discussion of how calling mingetty works on Ubuntu.

  • Well, I forgot to mention that I indeed care about Ubuntu. The link above points to some out-of-date information, and my first attempt (just edit /etc/init/tty1.conf was not at all successful. Apr 5, 2011 at 18:36
  • They use getty from util-linux, not mingetty, but this works with Debian as well. Thanks!
    – mirabilos
    Feb 21, 2018 at 15:10

With systemd things are different. See article Stop Clearing My God Damned Console. In short:

mkdir /etc/systemd/system/[email protected]
cat >/etc/systemd/system/[email protected]/noclear.conf <<EOF
systemctl daemon-reload

Verify the result with systemctl cat [email protected]


If nothing else helped, you can grab your laptop and capture all the kernel log through serial console by adding something like this to kernel parameters:

console=tty0 console=ttyS0,9600n8 console=tty0

This will cause output to apperar on serial console (in your terminal program) and on standard tty. Sometimes SOL (Serial Over LAN) is available.


After hours of googling, I found the solution in this thread and this question. This procedure works for Ubuntu 12.04.1 LTS as also described here, but it should not differ too much for other distributions.

First, add console=tty1 to your GRUB_CMDLINE_LINUX (I also suggest to add noplymouth to inhibit plymouth and its useless splashscreen).

#> sudo vi /etc/default/grub

GRUB_CMDLINE_LINUX="console=tty1 noplymouth"

This forces the kernel log to be printed on tty1 instead of tty7 and avoid the tty switch before the login prompt.

Then just go into /etc/init and edit one or more of tty1.conf, tty2.conf, tty3.conf, tty4.conf, tty5.conf, tty6.conf or console.conf. I edited them all adding --noclear option to the getty command. For example, editing tty1.conf:

#> sudo vi /etc/init/tty1.conf

you'll have to replace:

exec /sbin/getty -8 38400 tty1


exec /sbin/getty -8 38400 --noclear tty1

That's all, now your system should boot in a single tty without clearing it.


dmesg here goes back to the very beginning of the kernel, starting with

[    0.000000] Initializing cgroup subsys cpuset

Perhaps this is some bios message or part of your boot loader? Either way, there are so many different things that can blank the screen, without knowing where exactly in the process it happened it's hard to say what to do about it. Is the only thing left on the screen "Login:"? or is there some other boot-up stuff above it? If it's immediately before the login prompt and nothing else is on the screen, then perhaps /etc/issue has a screen-blanking command in it? Otherwise, you could be using some kind of console frame buffer that is switching the video mode. On my computer, the screen is blanked when a console font is loaded.

  • TL;DR /etc/issue can be a culprit, too. Good hint.
    – Tino
    Mar 10, 2018 at 12:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .