2

I recently installed Arch Linux on a System76 Lemur Pro laptop. The installation seemed to complete successfully, but the console_loglevel is set to the very high value of 15. The following command allowed me to draw this conclusion:

# cat /proc/sys/kernel/printk
15      4       1       4

The high console_loglevel causes a flood of kernel messages to be printed to the console, which makes it barely usable. I figured out that I can temporarily change the console_loglevel by running # echo 4 > /proc/sys/kernel/printk.

But I have so far been unable to permanently change the console_loglevel so it maintains its value after every boot. I've tried the following methods to permanently change it:

  • creating a /etc/sysctl.d/20-quiet-printk.conf file with the contents kernel.printk = 4 4 1 4 and then running sysctl -p /etc/sysctl.d/20-quiet-printk.conf (ref1, ref2)
  • creating a /etc/sysctl.conf file with the contents kernel.printk = 4 4 1 4 (ref1, ref2)
  • adding quiet loglevel=3 to the GRUB_CMDLINE_LINUX_DEFAULT entry in /etc/default/grub, and regenerating the GRUB configuration file using grub-mkconfig -o /boot/grub/grub.cfg (ref1, ref2)

Unfortunately, none of these methods worked, which leads me to believe that there is some other factor at play which is setting the console_loglevel to 15, and therefore overriding my settings above.

How can I determine what is setting the console_loglevel?

Trevor
  • 1,649
  • 1
  • 17
  • 28

2 Answers2

3

The log level was being set to a high value because of a kernel fault. I figured this out with the help of the System76 support team. The solution to my specific problem was to install the System76 ACPI DKMS driver, and info about the solution is now on the Arch Wiki.

Information about printk being set to a high value (of 15) in the case of a kernel fault is mentioned on the following man page:

$ man 2 syslog
...
   /proc/sys/kernel/printk
       /proc/sys/kernel/printk is a writable file containing four integer val‐
       ues that influence kernel printk() behavior when  printing  or  logging
       error messages.  The four values are:

   console_loglevel
          Only  messages  with  a  log level lower than this value will be
          printed to the console.  The default value for this field is <b>DE‐</b>
          <b>FAULT_CONSOLE_LOGLEVEL</b>  (7),  but  it  is set to 4 if the kernel
          command line contains the word &quot;quiet&quot;, 10 if the kernel command
          line  contains  the  word &quot;debug&quot;, and to 15 in case of a kernel
          fault (the 10 and 15 are just silly, and equivalent to 8).   The
          value  of  console_loglevel  can be set (to a value in the range
          1–8) by a <b>syslog</b>() call with a type of 8.



...
Trevor
  • 1,649
  • 1
  • 17
  • 28
-1

If you are running arch-linux then I presume that you know how to rebuild your kernel.

For setting all this stuff permanently, I would recommend setting the following kernel parameters :

CONFIG_CONSOLE_LOGLEVEL_DEFAULT / CONFIG_CONSOLE_LOGLEVEL_QUIET / CONFIG_MESSAGE_LOGLEVEL_DEFAULT.

After some # make menuconfig, you can access to these switches under the Kernel Hacking / Printk and dmesg options sub-menu.

MC68020
  • 7,981
  • Thanks for the suggestion. This may solve the problem, but my question is really about determining what factor is setting the log level, rather than determining a way to change it. I could just run the # echo 4 > /proc/sys/kernel/printk command automatically each time I boot. But I am trying to figure out what the root cause of this issue is, because this issue makes me suspicious that there is a larger problem going on. – Trevor Aug 08 '20 at 17:28
  • @wxyz : What factor is setting the log level ? CONFIG_CONSOLE_LOGLEVEL_DEFAULT! If you want to be certain about that, simply cd to wherever your kernel sources are located then # cat .config | grep CONSOLE_LOGLEVEL and you will discover that the value is defined in-kernel. – MC68020 Aug 08 '20 at 19:12
  • I have not modified the standard Arch Linux kernel. Most people use Arch Linux do not modify the kernel, and do not have the log problem I have described, so I wouldn't attribute the problem to the CONFIG_CONSOLE_LOGLEVEL_DEFAULT. Maybe I wasn't completely clear in my question. Anyway, I just learned that the problem was likely due to a kernel fault, and I have added an answer. – Trevor Aug 12 '20 at 18:44