#3112 PR closed: Set 'dmesg -n [4-7]' in sbin/rear

Labels: enhancement, won't fix / can't fix / obsolete

jsmeix opened issue at 2023-12-19 12:21:

In sbin/rear
find out if we're running inside the recovery system
and if yes call 'dmesg -n [4-7]' depending on
verbose and debug modes for ReaR.

In contrast to what I wrote in
https://github.com/rear/rear/issues/3107#issuecomment-1855732184
I set here
dmesg -n 4 as minimum i.e. in non verbose mode
dmesg -n 5 in verbose and debug mode
dmesg -n 6 in debugscript mode (with '-D' option)
dmesg -n 7 onyl with the long '--debugscripts' option
because dmesg log level 7 shows lots of (mostly useless)
informational messages that are normally not helpful
for debugging issues during 'rear recover'
but those many informational kernel messages
disturb the intended ReaR recovery messages and
in particular those needless kernel messages make
the intended ReaR recovery messages scroll away
out of sight too soon on console, cf.
https://github.com/rear/rear/issues/3107#issuecomment-1855783591
because I think the usual default is dmesg log level 7

In general:
If 'dmesg -n 8' (or something else) is needed
it can be called via PRE_RECOVERY_COMMANDS
so what we set here is only the default behaviour.

pcahyna commented at 2023-12-19 12:34:

Wouldn't it be better (more modular) to put the code into a script under usr/share/rear/setup/default, instead of directly into sbin/rear? That way you can also avoid checking whether we are inside the recovery system, because the setup stage is executed only in the workflows that run in the recovery system (true, it is not 100% the same thing, one can run rear mkbackup in the recovery system, but it is not usual).

jsmeix commented at 2023-12-19 12:42:

@pcahyna
thank you for your proposal.
I didn't consider doing it via a specific stage.
I will have a look if that works sufficiently fail-safe.
I mean:
It must never happen that we may accidentally change
the dmesg log level on the original system.
I also find relying on /etc/rear/rescue.conf somewhat uncertain.

pcahyna commented at 2023-12-19 12:57:

dmesg -n 6 in debugscript mode (with '-D' option)
dmesg -n 7 onyl with the long '--debugscripts' option

is it necessary to introduce a difference between -D and --debugscripts options? The manual page says:

       -D
           debugscript mode (log executed commands via set -x - also sets -v
           and -d)

       --debugscripts SET
           same as -d -v -D but debugscript mode with set -SET

so there should be no difference between -D and --debugscripts except for the possibility to specify other set flags. The manual page would need to be changed, but I would actually prefer to not introduce another (unrelated) difference.

pcahyna commented at 2023-12-19 12:58:

I also find relying on /etc/rear/rescue.conf somewhat uncertain.

me too. I already saw /etc/rear/rescue.conf in the original system (bad idea to do it, of course).

jsmeix commented at 2023-12-19 13:01:

Argh!
Now I see it (thanks to your above comment with the setup stage):
lib/recover-workflow.sh contains

# In the recovery system /etc/rear-release is unique (it does not exist otherwise)
# cf. init/default/050_check_rear_recover_mode.sh
test -f /etc/rear-release ...

I.e. I confused /etc/rear/rescue.conf with /etc/rear-release

jsmeix commented at 2023-12-19 13:04:

I think I will move the "set 'dmesg -n [4-7]' code" from sbin/rear
to init/default/050_check_rear_recover_mode.sh
because this is a generic piece of code
where the distinction between recovery system
and original system is implemented.

pcahyna commented at 2023-12-19 13:07:

init is sourced always though: SourceStage "init" in sbin/rear. I would find it safer (double check) to put it into setup, but it does not matter too much.
EDIT: you can put it into the case "$WORKFLOW" in (recover|layoutonly|restoreonly|finalizeonly|mountonly|opaladmin|help)
branch, and it has the same effect, but the effect then does not correspond to the stated purpose of the script (check recover mode).

pcahyna commented at 2023-12-19 13:13:

Consider the above only a minor remark. I don't like putting more code into sbin/rear, a script under usr/share/rear is fine if it does the job.

jsmeix commented at 2023-12-19 13:14:

In sbin/rear we have already

RECOVERY_MODE=""
...
# Check if we are in recovery mode:
test -e "/etc/rear-release" && RECOVERY_MODE="y" || true
readonly RECOVERY_MODE

which was introduced by
https://github.com/rear/rear/commit/f035085e26d22ce154cadd0c887e312cf954fab5
but meanwhile RECOVERY_MODE is no longer used anywhere.

I will use RECOVERY_MODE for the "set 'dmesg -n [4-7]' code"
regardless where that code will be implemented.

jsmeix commented at 2023-12-19 13:34:

According to init/default/050_check_rear_recover_mode.sh the workflows
recover layoutonly restoreonly finalizeonly mountonly opaladmin help
can run within the recovery system
but not all of them do SourceStage "setup"
(opaladmin and help do not SourceStage "setup").

So the question is whether or not dmesg -n [4-7]
should be called for all workflows that
can run within the recovery system
or only for those workflows that
can run within the recovery system
and do SourceStage "setup" ?

Of course it does not matter whether or not dmesg -n [4-7]
is called for the help workflow within the recovery system.

But should dmesg -n [4-7] be called for the opaladmin workflow
when it is run within the recovery system?

jsmeix commented at 2023-12-19 14:02:

@pcahyna
regarding your
https://github.com/rear/rear/pull/3112#issuecomment-1862714194

I already saw /etc/rear/rescue.conf in the original system
(bad idea to do it, of course).

Interestingly
prep/default/100_init_workflow_conf.sh
appends its initialization content
to $ROOTFS_DIR/etc/rear/rescue.conf
but fortunately prep/default/005_remove_workflow_conf.sh
had an existing $ROOTFS_DIR/etc/rear/rescue.conf removed
but unfortunately build/GNU/Linux/100_copy_as_is.sh
may later overwrite $ROOTFS_DIR/etc/rear/rescue.conf
by copying an existing /etc/rear/rescue.conf
from the original system.

Fortunately I am not too greedy so I won't dig deeper here
because I fear waking up daemons lurking in the dark, cf.
https://en.wikipedia.org/wiki/Moria_(Middle-earth)

The Dwarves dug too deep, greedy for mithril,
and disturbed a demon of great power:
a Balrog, which destroyed their kingdom

;-)

jsmeix commented at 2023-12-20 13:39:

This one is obsoleted by
https://github.com/rear/rear/pull/3113

jsmeix commented at 2023-12-21 07:04:

@pcahyna
after sleeping on it I decided to follow your proposal
to implement it in a 'setup' script in particular because
the remaining workflows that can run within the recovery system
opaladmin and help run with 'dmesg -n 5' from /etc/scripts/boot
so all workflows that can run within the recovery system
run with a reasonable default dmesg level.

[Export of Github issue for rear/rear.]