#3108 PR merged: Set 'dmesg -n 5' in etc/scripts/boot

Labels: enhancement, fixed / solved / done

jsmeix opened issue at 2023-12-14 12:02:

I tested various 'dmesg -n [1-7]' during "rear recover"
and up to 'dmesg -n 5' i.e. up to warning messages
there are almost no kernel messages so that level 5
does not "pollute" the usual ReaR messages.
In contrast level 6 (notice messages) shows some more
kernel messages which could be considered as disturbing
and with level 7 (info messages) it really gets too much.

  • Description of the changes in this pull request:

In [skel/default]/etc/scripts/boot set

dmesg -n 5

to limit console logging for 'dmesg' messages to level 5
so that kernel error and warning messages appear
(intermixed with ReaR messages) on the console
so that the user can notice when things go wrong
in kernel area which helps to understand problems.

pcahyna commented at 2023-12-14 12:36:

Unfortunately the console log in CI is not useful to see the result after successful recovery. The console log is limited to 64 kB, and successful recovery reboots multiple times (due to SELinux relabeling), so the console messages from the recovery run get scrolled into the memory hole.

pcahyna commented at 2023-12-14 12:53:

Here is the console log from the centos-stream-8-x86_64 CI run - it errored out because of timeout https://artifacts.dev.testing-farm.io/f6bd055b-71dd-4cb7-9550-89007881c9fa/ https://github.com/rear/rear/pull/3108/checks?check_run_id=19639265907

        Starting Relax-and-Recover boot script...
[  OK  ] Created slice system-serial\x2dgetty.slice.
[  OK  ] Started udev Kernel Device Manager.
         Starting Initialize Rescue System...
[  OK  ] Started Relax-and-Recover boot script.
[  OK  ] Started udev Coldplug all Devices.
[    3.824928] Error: Driver 'pcspkr' is already registered, aborting...
[  OK  ] Found device /dev/ttyS0.

Verifying md5sums of the files in the Relax-and-Recover rescue system
md5sums are OK

Configuring Relax-and-Recover rescue system

Running 00-functions.sh...
Running 01-run-ldconfig.sh...
Running 10-console-setup.sh...
Using keymap of the original system
Running 20-check-boot-options.sh...
Running 40-start-udev-or-load-modules.sh...
Loading modules specified in /etc/modules ...
insmod /lib/modules/4.18.0-527.el8.x86_64/kernel/drivers/net/xen-netfront.ko.xz 
modprobe: ERROR: could not insert 'xen_netfront': No such device
insmod /lib/modules/4.18.0-527.el8.x86_64/kernel/drivers/block/xen-blkfront.ko.xz 
modprobe: ERROR: could not insert 'xen_blkfront': No such device
Waiting for udev ... [    8.678961] Error: Driver 'pcspkr' is already registered, aborting...
done.
Running 41-load-special-modules.sh...
Running 42-engage-scsi.sh...
Running 45-serial-console.sh...
Serial console support enabled for ttyS0 at speed 115200
Running 55-migrate-network-devices.sh...
Running 58-start-dhclient.sh...
Attempting to start the DHCP client daemon
Running 60-network-devices.sh...
Running 62-routing.sh...
Running 65-sysctl.sh...
Running 99-makedev.sh...

Relax-and-Recover rescue system is ready

Launching 'rear recover' automatically
(...)

It shows that the only added message during boot is the repeated
Error: Driver 'pcspkr' is already registered, aborting...

jsmeix commented at 2023-12-14 12:59:

Regardless whether or not the kernel ring buffer
is useful for debugging CI problems,
I like 'dmesg -n 5' in general because
it is much better than 'dmesg -n1', see
https://github.com/rear/rear/issues/3107#issuecomment-1855783591

pcahyna commented at 2023-12-14 14:29:

right, and it actually is useful, see https://github.com/rear/rear/issues/3107#issuecomment-1855953570

jsmeix commented at 2023-12-15 09:07:

@rear/contributors
unless there is a critical objection
I would "just merge" it today afternoon
because I think nothing could get actually wrong
with 'dmesg -n 5' compared to 'dmesg -n1' before.
I think at most some unwanted kernel messages
could appear intermixed with ReaR messages
on the console - but only on the console
so when "rear recover" is not run on the console
e.g from remote via 'ssh' then no kernel messages
appear on the remote terminal where 'ssh' is run.

[Export of Github issue for rear/rear.]