#3308 PR `merged`: In 990_verify_rootfs.sh show relative paths in user messages for files in ROOTFS_DIR¶

Labels: enhancement, fixed / solved / done

jsmeix opened issue at 2024-09-03 15:00:¶

Type: Enhancement
Impact: High

From some SUSE customer support issues I learned
that there is confusion what those messages mean,
both for the user (i.e. for SUSE's customer) and
also for our (i.e. SUSE's) customer support pepole,
in particular when someone is not sufficiently
experienced with ReaR to imagine what actually
goes on behind the surface regardless of the
misleading file names in those messages.

Reference to related issue (URL):

https://github.com/rear/rear/pull/3250
therein in particular
https://github.com/rear/rear/pull/3250#discussion_r1676149339
https://github.com/rear/rear/pull/3250#discussion_r1741535372
https://github.com/rear/rear/pull/3250#discussion_r1741563610
https://github.com/rear/rear/pull/3250#discussion_r1741631492
https://github.com/rear/rear/pull/3250#discussion_r1741650136

https://github.com/rear/rear/issues/3283
therein only the first item

strip the ReaR build including .../rootfs from the found library

How was this pull request tested?

See below.

Description of the changes in this pull request:

In build/default/990_verify_rootfs.sh enhanced
how files from within the ReaR recovery system
(i.e. files from within ROOTFS_DIR)
are shown to the user:
In user messages it is misleading to show
the full path from within the recovery system
without leading ROOTFS_DIR e.g. show
/bin/parted for what actually is
/var/tmp/rear.XXX/rootfs/bin/parted
because for the user /bin/parted means
the full path on his original system
but there is no /bin/parted on the original
system because there it is /usr/sbin/parted
so to show files inside the recovery system to
the user even without (the long) leading ROOTFS_DIR
we can show them to the user as relative path
i.e. without leading slashes e.g. as bin/parted
when from the context it should be clear enough
that a file inside the recovery system is meant.

jsmeix commented at 2024-09-03 15:01:¶

On my SLES15-SP6 test VM:

localhost:~/rear.github.master # usr/sbin/rear -D mkrescue
.
.
.
Running 'build' stage ======================
...
Testing that the ReaR recovery system in '/var/tmp/rear.xSgQ1crMhNqnBMq/rootfs' contains a usable system
Testing each binary with 'ldd' for 'not found' libraries within the ReaR recovery system
usr/lib64/systemd/libsystemd-core-254.so requires libraries where 'ldd' shows 'not found'
usr/lib64/systemd/libsystemd-core-254.so requires libsystemd-shared-254.so which exists as usr/lib64/systemd/libsystemd-shared-254.so
Testing that the existing programs in the PROGS array can be found as executable command within the ReaR recovery system
Testing that each program in the REQUIRED_PROGS array can be found as executable command within the ReaR recovery system
Running 'pack' stage ======================

jsmeix commented at 2024-09-03 15:07:¶

On my SLES15-SP6 test VM
with an (artificial) test by added

rm $ROOTFS_DIR/usr/lib64/libparted.*

at the beginning of
usr/share/rear/build/default/990_verify_rootfs.sh
I get:

localhost:~/rear.github.master # usr/sbin/rear -D mkrescue
.
.
.
Running 'build' stage ======================
...
Testing that the ReaR recovery system in '/var/tmp/rear.qpxM6Od0v6ySLjq/rootfs' contains a usable system
Testing each binary with 'ldd' for 'not found' libraries within the ReaR recovery system
bin/parted requires libraries where 'ldd' shows 'not found' (fatal by default)
bin/parted requires libparted.so.2 which could not be found in the ReaR recovery system
bin/partprobe requires libraries where 'ldd' shows 'not found' (fatal by default)
bin/partprobe requires libparted.so.2 which could not be found in the ReaR recovery system
usr/lib64/systemd/libsystemd-core-254.so requires libraries where 'ldd' shows 'not found'
usr/lib64/systemd/libsystemd-core-254.so requires libsystemd-shared-254.so which exists as usr/lib64/systemd/libsystemd-shared-254.so
ReaR recovery system in '/var/tmp/rear.qpxM6Od0v6ySLjq/rootfs' needs additional libraries, check /root/rear.github.master/var/log/rear/rear-localhost.log for details
Build area kept for investigation in '/var/tmp/rear.qpxM6Od0v6ySLjq', remove it when not needed
Testing that the existing programs in the PROGS array can be found as executable command within the ReaR recovery system
Testing that each program in the REQUIRED_PROGS array can be found as executable command within the ReaR recovery system
ERROR: ReaR recovery system in '/var/tmp/rear.qpxM6Od0v6ySLjq/rootfs' not usable (required libraries are missing)
Some latest log messages since the last called script 990_verify_rootfs.sh:
  chattr is /sbin/chattr
  mkfs is /sbin/mkfs
  mkfs.btrfs is /sbin/mkfs.btrfs
  btrfs is /sbin/btrfs
  mkswap is /sbin/mkswap
  cryptsetup is /sbin/cryptsetup
  dmsetup is /sbin/dmsetup
  ldconfig is /sbin/ldconfig
Aborting due to an error, check /root/rear.github.master/var/log/rear/rear-localhost.log for details
Exiting rear mkrescue (PID 24261) and its descendant processes ...
Running exit tasks
To remove the build area you may use (with caution): rm -Rf --one-file-system /var/tmp/rear.qpxM6Od0v6ySLjq
Terminated

jsmeix commented at 2024-09-04 07:39:¶

Interesting output for another (artificial) test
when I have

rm $ROOTFS_DIR/usr/lib64/libparted.so.2.0.1

at the beginning of
usr/share/rear/build/default/990_verify_rootfs.sh
on my SLES15-SP6 test VM:

localhost:~/rear.github.master # usr/sbin/rear -D mkrescue
.
.
.
Running 'build' stage ======================
...
Testing that the ReaR recovery system in '/var/tmp/rear.MvxJ9aZDT3VElGE/rootfs' contains a usable system
Testing each binary with 'ldd' for 'not found' libraries within the ReaR recovery system
bin/parted requires libraries where 'ldd' shows 'not found' (fatal by default)
bin/parted requires libparted.so.2 which exists as usr/lib64/libparted.so.2
bin/partprobe requires libraries where 'ldd' shows 'not found' (fatal by default)
bin/partprobe requires libparted.so.2 which exists as usr/lib64/libparted.so.2
usr/lib64/systemd/libsystemd-core-254.so requires libraries where 'ldd' shows 'not found'
usr/lib64/systemd/libsystemd-core-254.so requires libsystemd-shared-254.so which exists as usr/lib64/systemd/libsystemd-shared-254.so
Build area kept for investigation in '/var/tmp/rear.MvxJ9aZDT3VElGE', remove it when not needed
Testing that the existing programs in the PROGS array can be found as executable command within the ReaR recovery system
Testing that each program in the REQUIRED_PROGS array can be found as executable command within the ReaR recovery system
ERROR: ReaR recovery system in '/var/tmp/rear.MvxJ9aZDT3VElGE/rootfs' not usable (required libraries are missing)
Some latest log messages since the last called script 990_verify_rootfs.sh:
  chattr is /sbin/chattr
  mkfs is /sbin/mkfs
  mkfs.btrfs is /sbin/mkfs.btrfs
  btrfs is /sbin/btrfs
  mkswap is /sbin/mkswap
  cryptsetup is /sbin/cryptsetup
  dmsetup is /sbin/dmsetup
  ldconfig is /sbin/ldconfig
Aborting due to an error, check /root/rear.github.master/var/log/rear/rear-localhost.log for details
Exiting rear mkrescue (PID 5391) and its descendant processes ...
Running exit tasks
To remove the build area you may use (with caution): rm -Rf --one-file-system /var/tmp/rear.MvxJ9aZDT3VElGE
Terminated

Therein in particular this (and same for bin/partprobe)

bin/parted requires libraries where 'ldd' shows 'not found' (fatal by default)
bin/parted requires libparted.so.2 which exists as usr/lib64/libparted.so.2

shows that it is not sufficient when something
that is reported as 'not found' by 'ldd'
actually exists within the recovery system
to assume that then the associated program(s)
will actually work within the recovery system.

In this case only the symlink
/usr/lib64/libparted.so.2 exists
but its link target (i.e. the actual library)
does not exist so parted (and partprobe)
cannot run within the recovery system.

jsmeix commented at 2024-09-04 12:36:¶

How things look on my SLES15-SP6 test VM
without any artificial test stuff:

In debug mode:

localhost:~/rear.github.master # usr/sbin/rear -d mkrescue
...
Testing that the ReaR recovery system in '/var/tmp/rear.JdqkcGSuu13c4ZH/rootfs' contains a usable system
Testing each binary with 'ldd' for 'not found' libraries within the ReaR recovery system
usr/lib64/systemd/libsystemd-core-254.so requires libraries where 'ldd' shows 'not found'
usr/lib64/systemd/libsystemd-core-254.so requires libsystemd-shared-254.so which exists as usr/lib64/systemd/libsystemd-shared-254.so

In verbose mode:

localhost:~/rear.github.master # usr/sbin/rear -v mkrescue
...
Testing that the ReaR recovery system in '/var/tmp/rear.idsaHMnfLWuWElp/rootfs' contains a usable system
usr/lib64/systemd/libsystemd-core-254.so requires libraries where 'ldd' shows 'not found'
usr/lib64/systemd/libsystemd-core-254.so requires libsystemd-shared-254.so which exists as usr/lib64/systemd/libsystemd-shared-254.so

In normal mode (i.e. non-verbose mode):

localhost:~/rear.github.master # usr/sbin/rear mkrescue
localhost:~/rear.github.master #

i.e. in non-verbose mode there is no output.

jsmeix commented at 2024-09-04 12:52:¶

@rear/contributors
from my point of view things look OK to me.
Please review this pull request as time permits.

A note against false expectations what I can do:
This pull request is neither meant to
(nor will I do via this pull request)
implement additional separated things,
e.g. things like what @schlomo proposed in
https://github.com/rear/rear/pull/3250#discussion_r1741724854
and
https://github.com/rear/rear/issues/3283#issuecomment-2328276184
Separated issues should be done via separated pull requests.

jsmeix commented at 2024-09-04 13:36:¶

@pcahyna @lzaoral
regarding the above "1 failing checks" which is

testing-farm:fedora-39-x86_64 — Tests failed ...

When I follow its "Details" link to
https://github.com/rear/rear/pull/3308/checks?check_run_id=29654121837
and therein follow the "Testing Farm" related link to
https://artifacts.dev.testing-farm.io/7876f414-87eb-46f5-ad0b-d868b7e3f744/
then this one shows (excerpts):

/make-backup-and-restore-iso
...
testout.log
...
Run rear mkbackup
...
Running rear mkbackup (PID 4713 date 2024-09-04 07:39:41)
Command line options: /usr/sbin/rear -d mkbackup
...
Testing that the ReaR recovery system in '/var/tmp/rear.lJbPdFS9aflRgKC/rootfs' contains a usable system
Testing each binary with 'ldd' for 'not found' libraries within the ReaR recovery system
usr/lib64/systemd/libsystemd-core-254.16-1.fc39.so requires libraries where 'ldd' shows 'not found'
usr/lib64/systemd/libsystemd-core-254.16-1.fc39.so requires libsystemd-shared-254.16-1.fc39.so which exists as usr/lib64/systemd/libsystemd-shared-254.16-1.fc39.so
...
Running 'output' stage ======================
Let GRUB2 load kernel /isolinux/kernel
Let GRUB2 load initrd /isolinux/initrd.cgz
Set GRUB2 default root device via 'set root=cd0'
Let GRUB2 search root device via 'search --no-floppy --set=root --file /boot/efiboot.img'
grub2-mkstandalone may fail to make a bootable EFI image of GRUB2 (no /usr/*/grub*/x86_64-efi/moddep.lst file)
GRUB2 modules to load: ext2 fat part_gpt part_msdos
ERROR: Failed to make bootable EFI image of GRUB2 (error during grub2-mkstandalone of /var/tmp/rear.lJbPdFS9aflRgKC/tmp/mnt/EFI/BOOT/BOOTX64.efi)
Some latest log messages since the last called script 250_populate_efibootimg.sh:
  2024-09-04 07:41:09.368662434 Let GRUB2 load initrd /isolinux/initrd.cgz
  2024-09-04 07:41:09.375270792 Set GRUB2 default root device via 'set root=cd0'
  2024-09-04 07:41:09.378628607 Let GRUB2 search root device via 'search --no-floppy --set=root --file /boot/efiboot.img'
  /usr/share/rear/lib/_input-output-functions.sh: line 581: type: grub-mkstandalone: not found
  /usr/share/rear/lib/_input-output-functions.sh: line 581: type: grub-probe: not found
  2024-09-04 07:41:10.092032475 grub2-mkstandalone may fail to make a bootable EFI image of GRUB2 (no /usr/*/grub*/x86_64-efi/moddep.lst file)
  2024-09-04 07:41:10.095741686 GRUB2 modules to load: ext2 fat part_gpt part_msdos
  grub2-mkstandalone: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory.
You may use debugscript mode '-D' for full debug messages with 'set -x' output
Aborting due to an error, check /var/log/rear/rear-ip-172-31-27-236.log for details

where "testout.log" is a link to
https://artifacts.dev.testing-farm.io/7876f414-87eb-46f5-ad0b-d868b7e3f744/work-backup-and-restorew7s7ztm_/tests/plans/backup-and-restore/execute/data/guest/default-0/make-backup-and-restore-iso-1/output.txt

So - as far as I see - the reason why it fails
has nothing to do with the changes in this pull request,
actually the changes in this pull request seem to work well.

So - as far as I see - we can safely ignore that

testing-farm:fedora-39-x86_64 — Tests failed ...

for this pull request here.

jsmeix commented at 2024-09-04 14:39:¶

Regarding using $PRODUCT for the ReaR name (in long),
i.e. via

... PRODUCT="Relax-and-Recover"

in usr/sbin/rear e.g. for ReaR 2.7 online at
https://github.com/rear/rear/blob/rear-2.7/usr/sbin/rear#L56

Because one point of this pull request is
to get the user messages shorter
I don't think it is actually helpful for readability
for the user to use Relax-and-Recover
instead of ReaR in user messages.

I think using everywhere the long form Relax-and-Recover
could even make our user messages look a bit
like "marketing bullshit" - in particular because
our users are often rather experienced (e.g. admins)
who may feel rather annoyed to read in user messages
again and again the long form Relax-and-Recover
instead of the established and well known
abbreviation ReaR.

According to

# find usr/sbin/rear usr/share/rear/ -type f \
 | xargs grep -w 'ReaR' | grep -v ': *#' | wc -l

82

# find usr/sbin/rear usr/share/rear/ -type f \
 | xargs grep -w 'ReaR' | grep -v ': *#' \
 | cut -s -d ':' -f1 | sort -u | wc -l

39

we have currently about 82 code places
in about 39 code files where we use ReaR
(probably some of them are "false positives").

In contrast according to

# find usr/sbin/rear usr/share/rear/ -type f \
 | xargs grep '$PRODUCT' | grep -v ': *#' | wc -l

39

# find usr/sbin/rear usr/share/rear/ -type f \
 | xargs grep '$PRODUCT' | grep -v ': *#' \
 | cut -s -d ':' -f1 | sort -u | wc -l

11

we have currently about 39 code places in about 11 files
where $PRODUCT is used.

So currently it is common practice to use ReaR.

I think a proper solution could be
to add another variable to usr/sbin/rear like

... PRODUCT_ABBR="ReaR"

for the cases where the abbreviated form ReaR
should be used and then fix all the code places
where currently ReaR is used literally.

schlomo commented at 2024-09-04 14:42:¶

I don't want to delay this PR, so feel free to ignore.

About the product name variables, I guess we could also change PRODUCT=ReaR and introduce PRODUCT_LONG=Relax-and-Recover as I assume that we want to use more often the short name than the long name.

jsmeix commented at 2024-09-05 10:32:¶

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

[Export of Github issue for rear/rear.]

#3308 PR merged: In 990_verify_rootfs.sh show relative paths in user messages for files in ROOTFS_DIR¶