#2120 Issue closed: rear mkrescue log contains "Welcome to Relax-and-Recover..." numerous times

Labels: enhancement, cleanup, fixed / solved / done, minor bug

OliverO2 opened issue at 2019-04-16 11:03:

  • ReaR version: 2.4 / Git 3f5e5e4f

  • OS version: Ubuntu 18.04.2 LTS

  • Log file excerpt:

2019-04-15 23:06:58.047744964 Testing that each program in the PROGS array can be found as executable command within the recovery system
/usr/share/rear/build/default/990_verify_rootfs.sh: line 132: type: grub: not found
/usr/share/rear/build/default/990_verify_rootfs.sh: line 132: type: lilo: not found
partprobe is /sbin/partprobe

Welcome to Relax-and-Recover. Run "rear recover" to restore your system !

partprobe is /bin/partprobe
fdisk is /sbin/fdisk

Welcome to Relax-and-Recover. Run "rear recover" to restore your system !

fdisk is /bin/fdisk
cfdisk is /sbin/cfdisk

Welcome to Relax-and-Recover. Run "rear recover" to restore your system !

cfdisk is /bin/cfdisk
sfdisk is /sbin/sfdisk

Welcome to Relax-and-Recover. Run "rear recover" to restore your system !

sfdisk is /bin/sfdisk
/usr/share/rear/build/default/990_verify_rootfs.sh: line 132: type: rpc.statd: not found
/usr/share/rear/build/default/990_verify_rootfs.sh: line 132: type: rpcbind: not found
  • Seems like this line in usr/share/rear/build/default/990_verify_rootfs.sh makes bash print usr/share/rear/skel/default/etc/motd on each invocation:
chroot $ROOTFS_DIR /bin/bash --login -c "type $program" || missing_programs="$missing_programs $program"

jsmeix commented at 2019-04-17 10:36:

I will have a look...

jsmeix commented at 2019-04-17 15:06:

Strange, I cannot reproduce it on my openSUSE Leap 15.0 system
with our current GitHub master code:

# usr/sbin/rear -D mkrescue
...
Using log file: /root/rear.github.master/var/log/rear/rear-g243.log
...
Running exit tasks
You should also rm -Rf /tmp/rear.nwzW4ZOgUr3Q7jP

# cat /tmp/rear.nwzW4ZOgUr3Q7jP/rootfs/etc/motd

Welcome to Relax-and-Recover. Run "rear recover" to restore your system !

# less /root/rear.github.master/var/log/rear/rear-g243.log
...
+ source /root/rear.github.master/usr/share/rear/build/default/990_verify_rootfs.sh
...
++ local missing_programs=
++ for program in "${PROGS[@]}"
++ type grub
/root/rear.github.master/usr/share/rear/build/default/990_verify_rootfs.sh: line 132: type: grub: not found
++ continue
++ for program in "${PROGS[@]}"
++ type lilo
/root/rear.github.master/usr/share/rear/build/default/990_verify_rootfs.sh: line 132: type: lilo: not found
++ continue
++ for program in "${PROGS[@]}"
++ type partprobe
partprobe is /usr/sbin/partprobe
+++ basename partprobe
++ program=partprobe
++ chroot /tmp/rear.nwzW4ZOgUr3Q7jP/rootfs /bin/bash --login -c 'type partprobe'
partprobe is /sbin/partprobe
++ for program in "${PROGS[@]}"
++ type fdisk
fdisk is /sbin/fdisk
+++ basename fdisk
++ program=fdisk
++ chroot /tmp/rear.nwzW4ZOgUr3Q7jP/rootfs /bin/bash --login -c 'type fdisk'
fdisk is /sbin/fdisk
++ for program in "${PROGS[@]}"
++ type cfdisk
cfdisk is /sbin/cfdisk
+++ basename cfdisk
++ program=cfdisk
++ chroot /tmp/rear.nwzW4ZOgUr3Q7jP/rootfs /bin/bash --login -c 'type cfdisk'
cfdisk is /sbin/cfdisk
++ for program in "${PROGS[@]}"
++ type sfdisk
sfdisk is /sbin/sfdisk
+++ basename sfdisk
++ program=sfdisk
++ chroot /tmp/rear.nwzW4ZOgUr3Q7jP/rootfs /bin/bash --login -c 'type sfdisk'
sfdisk is /sbin/sfdisk

@OliverO2
can you test if the following change in usr/share/rear/build/default/990_verify_rootfs.sh
helps to suppress the unwanted output in your case

    # Suppress all output to avoid useless messages in the log file (see https://github.com/rear/rear/issues/2120):
    chroot $ROOTFS_DIR /bin/bash --login -c "type $program" &>/dev/null || missing_programs="$missing_programs $program"

OliverO2 commented at 2019-04-17 15:47:

@jsmeix usr/share/rear/skel/default/etc/profile displays the motd greeting only when a terminal is present. So maybe you have called rear mkrescue without stdin coming from a terminal.

I've checked your suggestion and it works. Some remarks:

jsmeix commented at 2019-04-17 16:17:

@OliverO2
I have called rear -D mkrescue from within an xterm.

I would prefer to keep the type $program output like

partprobe is /sbin/partprobe

because that could be useful in the log to better understand what goes on,
I mean when e.g. I have to inspect a log from another user and I must
imagine what goes on (in particular what may go wrong) on his system.

Could you do a pull request with redirecting the input to /dev/null
at all those places where you need it because I cannot easily verify
in my environment what actually works best in your case.

In particular I wonder why you don't also get such messages
when we run stuff via chroot ... /bin/bash --login
in all those other scripts:

# find usr/share/rear/ -name '*.sh' | xargs grep -l 'chroot .* /bin/bash --login'

usr/share/rear/build/default/990_verify_rootfs.sh
usr/share/rear/restore/default/900_create_missing_directories.sh
usr/share/rear/restore/ZYPPER/default/950_grub2_mkconfig.sh
usr/share/rear/restore/ZYPPER/default/980_initial_network_setup.sh
usr/share/rear/restore/ZYPPER/default/970_set_root_password.sh
usr/share/rear/restore/YUM/default/950_grub2_mkconfig.sh
usr/share/rear/restore/YUM/default/980_initial_network_setup.sh
usr/share/rear/restore/YUM/default/970_set_root_password.sh
usr/share/rear/finalize/Fedora/ppc64/550_rebuild_initramfs.sh
usr/share/rear/finalize/Fedora/ppc64le/550_rebuild_initramfs.sh
usr/share/rear/finalize/Fedora/i386/550_rebuild_initramfs.sh
usr/share/rear/finalize/Linux-ppc64/660_install_grub2.sh
usr/share/rear/finalize/Debian/ppc64le/550_rebuild_initramfs.sh
usr/share/rear/finalize/Debian/i386/550_rebuild_initramfs.sh
usr/share/rear/finalize/Linux-ppc64le/660_install_grub2.sh
usr/share/rear/finalize/Linux-i386/660_install_grub2.sh
usr/share/rear/finalize/SUSE_LINUX/ppc64/550_rebuild_initramfs.sh
usr/share/rear/finalize/SUSE_LINUX/ppc64le/550_rebuild_initramfs.sh
usr/share/rear/finalize/SUSE_LINUX/i386/550_rebuild_initramfs.sh

Many thanks in advance!

OliverO2 commented at 2019-04-19 10:14:

Could you do a pull request with redirecting the input to /dev/null
at all those places where you need it because I cannot easily verify
in my environment what actually works best in your case.

Yes, sure.

In particular I wonder why you don't also get such messages
when we run stuff via chroot ... /bin/bash --login
in all those other scripts:

The majority of these probably don't get called: I don't test i386/ppc/zypper/yum/Fedora stuff. So the only candidate would be usr/share/rear/restore/default/900_create_missing_directories.sh. I'll have a look.

jsmeix commented at 2019-04-23 08:26:

Of course I meant only what is actually run in your case.

From your results we may then conclude that we could
always redirect the input to /dev/null for chroot calls
(provided input is not needed in each particular case)
to avoid such unwanted messages in the log in any case.

jsmeix commented at 2019-04-29 08:35:

With https://github.com/rear/rear/pull/2125 merged
this issue is fixed for ReaR 2.5 and listed in its release notes via
https://github.com/rear/rear.github.com/commit/07cb4ea8e76744e8c8b9de00897bbda301d92dbd

[Export of Github issue for rear/rear.]