Set 'dmesg -n [4-6]' in new 'setup' script 007_set_dmesg_level.sh

[jsmeix]

• Type: Enhancement

• Impact: Normal

• Reference to related issue (URL):
  Set 'dmesg -n 5' in etc/scripts/boot #3108

• How was this pull request tested?
  I tested it and it works well for me.

• Description of the changes in this pull request:

The new 'setup' stage script setup/default/007_set_dmesg_level.sh
sets 'dmesg -n [4-6]' for the worksflows
recover layoutonly restoreonly finalizeonly mountonly
depending on verbose and debug modes for ReaR.

This pull request obsoletes
#3112

[jsmeix]

@rear/contributors
I would like to merge it today afternoon
unless there are objections

[pcahyna]

Only a nit, but is it intended to leave the first and last line of the file empty?

[jsmeix]

In contrast to what I wrote in
#3107 (comment)

With 'dmesg -n 5' in [skel/default]/etc/scripts/boot
I do not get any kernel error or warning message
during ReaR recovery system startup on my test VM
so normally 'dmesg -n 5' is sufficiently quiet.

I tested this pull request on another VM
with a rather minimal SLES15-SP5 system
and there 'dmesg -n 5' in /etc/scripts/boot
results a few systemd related kernel messages
during ReaR recovery system startup
and also a few systemd related kernel messages
during "rear recover" but nothing that could
really "pollute" the usual ReaR messages
so 'dmesg -n 5' behaves as I described in
#3108 (comment)

... 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 ...

Therefore I added

DebugPrint "Setting dmesg level $dmesg_level"

so the user could see in debug mode why kernel messages
appear now intermixed with ReaR messages on console
but only on console and not eg. from remote via 'ssh', cf
#3108 (comment)
which is a bit different behaviour on console
than it had been before with 'dmesg -n1'.

[jsmeix]

@pcahyna
probably unexpected but it is really intentional
that I prefer to keep the first and last line empty.
My explanation for that could become somewhat long-winded
but I have some good reasons with personal experience
for both cases (first line and last line).
Technically there is no reason for that but only
in theory, theory and practice are the same,
in practice, they are not ;-)

[pcahyna]

@jsmeix I would now to recommend to squash the first three commits together and force push. Then, when merging, use the usual procedure (create a merge commit).

[jsmeix]

@pcahyna
I simply merged with "Squash and merge" in the GitHub web frontend
which squashed all commits into one single merge commit.
The more I get used to it the more I like its simplicity.
Meanwhile I think its drawback as described in
#3089 (comment)
does not matter in practice in very most cases.
I.e. I think the simplicity of "squash all into one"
outweighs its possible drawback in very most cases.

[jsmeix]

Normally I use only the GitHub web frontend to implement changes
so normally I cannot squash specific commits myself locally.

Normally I do not implement things on a local git checkout
on my homeoffice laptop but I use the GitHub web frontend
as much as possible (to a certain extent) e.g. for some
really big changes I may prefer a local git checkout.

I test pull requests via git clone and git checkout
on a test VM that runs on my homeoffice laptop.

My personal reasons are:

Since more and more "doing work" changes from
doing one's own computing with one's own software
to Service as a Software Substitute (SaaSS), cf.
https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html

1. I just try to adapt to the new fancy modern way
   because I know how to do things the good old way
   but I want to really try out that new way
   and get some proper experience on my own
   to be able to better understand the new way.
2. I want to be independent of the particular computer
   where I sit in front of as far as possible (to a certain extent)
   so any computer with a browser should suffice.

My personal reason behind those reasons is
that some years ago I had a (smaller) accident at my leg
(it was about 2019 - i.e. before I changed to homeoffice)
which forced me to sit at home with a "home"-computer
that was not at all prepared to do my work.
But I was able to do my work (I only could not walk)
so I experienced how good it would be to be able
to work on an arbitrary (trusted) computer
with basically only a (reasonable) browser.