.... (Fedora Rawhide)¶

Labels: support / question, not ReaR / invalid

GreasyMonkee opened issue at 2022-01-18 08:21:¶

Relax-and-Recover (ReaR) Issue Template¶

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

ReaR version ("/usr/sbin/rear -V"): Relax-and-Recover 2.6 / 2020-06-17
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"): Fedora release 36 (Rawhide)
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"): see attached file, rear.txt
Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR): HPE DL380P
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device): x86 compatible
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot): BIOS, GRUB
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe): USB drive
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"): see attached file, lsblk.txt
Description of the issue (ideally so that others can reproduce it): run /usr/sbin/rear -v mkbackup
Workaround, if any: None known
Attachments, as applicable ("rear -D mkbackup" debug log files):
rear-servnet.log
rear.txt
lsblk.txt

To paste verbatim text like command output or file content,
include it between a leading and a closing line of three backticks like

```
problem has occurred after weekly upgrade, using "dnf upgrade", with multiple packages updated, including latest Rawhide Kernel.

No changes in config file were done, same external USB device as used for the previous week's backup.
```

jsmeix commented at 2022-01-18 10:41:¶

https://github.com/rear/rear/files/7887202/rear-servnet.log
contains

++ chroot /tmp/rear.72nSC6tc1CdkreF/rootfs /bin/bash -c true
chroot: failed to run command '/bin/bash': No such file or directory
...
BUG in /usr/share/rear/build/default/990_verify_rootfs.sh line 48:
ReaR recovery system in '/tmp/rear.72nSC6tc1CdkreF/rootfs' is broken: 'bash -c true' failed
...
Some latest log messages since the last called script 990_verify_rootfs.sh:
  2022-01-18 08:24:50.904093409 Including build/default/990_verify_rootfs.sh
  2022-01-18 08:24:50.907783481 Entering debugscript mode via ''set -x''.
  2022-01-18 08:24:50.918613967 Testing that the recovery system in /tmp/rear.72nSC6tc1CdkreF/rootfs contains a usable system
  chroot: failed to run command '/bin/bash': No such file or directory

so this looks as if there is no '/bin/bash' in the recovery system.

https://github.com/rear/rear/files/7887202/rear-servnet.log
also contains

2022-01-18 08:24:33.759201567 RequiredSharedObjects: Skipping 'ldd' for '/bin/bash' (owner 'apache' not in TRUSTED_FILE_OWNERS)

which looks rather wrong that 'apache' is owner of '/bin/bash'
so this looks as if something may have gone rather wrong on the original system?

@GreasyMonkee
to inspect what your ReaR recovery system actually contains,
see the description about "KEEP_BUILD_DIR"
in usr/share/rear/conf/default.conf that is currently online at
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L163

I.e. inspect what your recovery system in /tmp/rear.72nSC6tc1CdkreF/rootfs
actually contains in your case and test things therein via
chroot /tmp/rear.72nSC6tc1CdkreF/rootfs

GreasyMonkee commented at 2022-01-18 11:35:¶

@jsmeix

Thanks, that explains it - I will need to roll back to the last backed-up version to recover the original system.

Cheers.

jsmeix commented at 2022-01-18 12:39:¶

@GreasyMonkee
I am not a Fedora / Red Hat user so what I wrote
are only assumptions from what I noticed in your ReaR log file.
Perhaps your original system is not totally broken
and could be somehow fixed without a roll back.

Because this issue does not look like a bug in ReaR I close it.
Nevertheless further comments can be added here as needed.

GreasyMonkee commented at 2022-01-18 17:15:¶

Understood, I have reloaded from the backup, problem solved and have done a
further successful backup.

Many thanks for your quick and helpful response.

Cheers
Garth.

On Tue, 18 Jan 2022, 13:39 Johannes Meixner, ***@***.***>
wrote:

@GreasyMonkee https://github.com/GreasyMonkee
I am not a Fedora / Red Hat user so what I wrote
are only assumptions from what I noticed in your ReaR log file.
Perhaps your original system is not totally broken
and could be somehow fixed without a roll back.

Because this issue does not look like a bug in ReaR I close it.
Nevertheless further comments can be added here as needed.

—
Reply to this email directly, view it on GitHub
https://github.com/rear/rear/issues/2742#issuecomment-1015371803, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ADH76G5GKKK2OEFQ5OVL3KLUWVNQFANCNFSM5MGQA6TQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID:
***@***.***>

jsmeix commented at 2022-01-19 11:04:¶

@GreasyMonkee
thank you for your feedback that it had worked for you.

I appreciate explicit positive feedback because it makes clear the issue
is actually solved (instead of only assuming "no news is good news").

[Export of Github issue for rear/rear.]

#2742 Issue closed: Backup failed due to Error in testing Recovery system in /tmp/.... (Fedora Rawhide)¶