How to Switch Linux Kernel Console After Boot Process

Change default console loglevel during boot up

Do I need to recompile the kernel,

No.

or is there a way I can get the changed value to be persistent across reboot.

Yes.

Use the kernel command line parameter loglevel:

loglevel=       All Kernel Messages with a loglevel smaller than the
                    console loglevel will be printed to the console. It can
                    also be changed with klogd or other programs. The
                    loglevels are defined as follows:

                    0 (KERN_EMERG)          system is unusable
                    1 (KERN_ALERT)          action must be taken immediately
                    2 (KERN_CRIT)           critical conditions
                    3 (KERN_ERR)            error conditions
                    4 (KERN_WARNING)        warning conditions
                    5 (KERN_NOTICE)         normal but significant condition
                    6 (KERN_INFO)           informational
                    7 (KERN_DEBUG)          debug-level messages

The entire list of parameters possible on the kernel command line are in the Linux/Documentation/kernel-parameters.txt file in the source tree.

Depending on your bootloader (e.g. Grub or U-Boot), you will have to edit text to add this new parameter to the command line. Use cat /proc/cmdline to view the kernel command line used for the previous boot.

---

Addendum

To display everything, the number supplied for the loglevel parameter would have be be greater than KERN_DEBUG.

That is, you would have to specify loglevel=8.

Or simply use the ignore_loglevel parameter to display all kernel messages.

Booting linux kernel using a simple char driver as console?

They way the /dev/console driver works is to attach to some other tty device (or devices!), which is/are then used for the console. The sysfs attribute active of the console device (try /sys/class/tty/console/active) will tell you what device the console is attached to at the moment.

The kernel also tends to log console changes:

[    0.186989] dw-apb-uart ffc02000.serial0: ttyS0 at MMIO 0xffc02000 (irq = 194, base_baud = 6250000) is a 16550A
[    0.755529] console [ttyS0] enabled

In the above log, once the serial port device was created the kernel decided to use it as a console. This refers to the binding of the device to the driver in the kernel, not the device node in /dev. The latter does not matter here. Also understand that the attachment of the console device to a tty happens in the kernel. /dev/console is not a symlink to another device node.

The kernel has chosen ttyS0 because I told it to via the kernel command line, console=ttyS0,115200n8. Without a console argument, the kernel uses the first console that registers with register_console().

So the question here is how can one get /dev/ttyprintk to be attached to /dev/console. And the answer appears to be you can't.

A work around might be to create a custom initramfs that changes the /dev/console device node from major 5 minor 1 to use minor 3, thus changing it into /dev/ttyprintk. Or symlink to achieve the same thing. This should get init to use ttyprintk as its stdin/stdout/stderr.

In your example, writing a tty/console driver for your output device would be the right way. Make it the console and then the kernel sends printk there.

Using different console for respawn process in inittab on embedded device

I know the question is old, but it has no answers at all for crying out loud.

Remember that a TTY is both an output device and also an input device -- by cat'ing from it you're reading input from the terminal which means the keyboard, NOT the screen.

I don't know if there's a parallel in other *nixes, but Linux systems have /dev/vcsX and /dev/vcsaX character devices (nodes c,7,0+X and c,7,128+X respectively) for each /dev/ttyX device - these are mirrors of the data currently on the output of the TTY device (ie. the screen part of the TTY, not the keyboard part). These will give you what you're looking for. The vcsaX devices will give you a displaybyte+attributebyte pair (i.e. the foreground/background text colour -- see other references for more information on text attribute bytes) for each character on the screen, while the vcsX devices give only the displaybyte for each character. Of course it's a raw stream/dump so if the row and/or column count of your terminal doesn't match that of the the TTY you're dumping then you'll need to parse the data and reformat it to match.

tl;dr: use "cat /dev/vcs10"

Hope that helps.

How to disable serial console(non-kernel) in u-boot

I'm getting back to this issue almost a year later, now I've managed to find a proper solution.

The board I was working on had a reasonably new u-boot in its BSP. To disable the serial console I had to do the following:

• Add the following defines to the board's config header(located in include/configs/board.h):

    #define CONFIG_DISABLE_CONSOLE
    #define CONFIG_SILENT_CONSOLE
    #define CONFIG_SYS_DEVICE_NULLDEV
  

• Check if your board has early_init_f enabled in the same file:

    #define CONFIG_BOARD_EARLY_INIT_F 1
  

• Find the arch file(Something like arch/x86/cpu/architecture/architecture.c) and add this call to its early_init_f function. It actually modifies board's global data variable to have these flags:

    gd->flags |= (GD_FLG_SILENT | GD_FLG_DISABLE_CONSOLE);
  

• My board did not have one, so I had to add the whole function

     int board_early_init_f(void)
     {
          gd->flags |= (GD_FLG_SILENT | GD_FLG_DISABLE_CONSOLE);
          return 0;
     }
  

Example:
If you are looking for board_early_init_f of Orange Pi 4B it is in /build/cache/sources/u-boot/v2020.10/board/rockchip/evb_rk3399/evb-rk3399.c

That's it. Hope this helps someone else!

---

see also

---

Related Topics