#2858 Issue closed: after recover system error with python module¶
Labels: support / question, fixed / solved / done
RolfWeilen opened issue at 2022-09-07 14:15:¶
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.7 / 2022-07-13 -
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
Distributor ID: RedHatEnterprise
Description: Red Hat Enterprise Linux release 8.6 (Ootpa)
Release: 8.6
Codename: Ootpa
- ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
AUTOEXCLUDE_MULTIPATH=N
OUTPUT=ISO
#OUTPUT_URL=file:/var/lib/rear/output/
OUTPUT_URL=null
ISO_DEFAULT=manuel
TIMESYNC=NTP
BACKUP=TSM
TSM_RESULT_SAVE=n
TSM_RESULT_FILE_PATH=
USE_DHCLIENT=y
USE_STATIC_NETWORKING=
ONLY_INCLUDE_VG=(h51ll60vg00)
GRUB_RESCUE=n
WAIT_SECS=31104000
SSH_ROOT_PASSWORD=rear
REBUILD_INITRAMFS="no"
tested as well with
REBUILD_INITRAMFS="yes"
-
Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
VM on RHEV Hypervisor -
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
x86 -
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):
local disk -
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
/dev/sr0 /dev/sr0 ata rom 1024M
/dev/vda /dev/vda disk 240G
|-/dev/vda1 /dev/vda1 /dev/vda part xfs 2G /boot
`-/dev/vda2 /dev/vda2 /dev/vda part LVM2_member 238G
|-/dev/mapper/h51ll60vg00-root /dev/dm-0 /dev/vda2 lvm xfs 20G /
|-/dev/mapper/h51ll60vg00-swap /dev/dm-1 /dev/vda2 lvm swap 16G [SWAP]
|-/dev/mapper/h51ll60vg00-alib /dev/dm-2 /dev/vda2 lvm xfs 5G /app/lib
|-/dev/mapper/h51ll60vg00-home /dev/dm-3 /dev/vda2 lvm xfs 5G /home
|-/dev/mapper/h51ll60vg00-vlsu /dev/dm-4 /dev/vda2 lvm xfs 5G /var/log/suva
|-/dev/mapper/h51ll60vg00-vlog /dev/dm-5 /dev/vda2 lvm xfs 5G /var/log
`-/dev/mapper/h51ll60vg00-uloc /dev/dm-6 /dev/vda2 lvm xfs 5G /usr/local
- Description of the issue (ideally so that others can reproduce it):
After recover the system many programms with are using python3
are not working anymore.
# yum list
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/dnf/crypto.py", line 35, in <module>
I tried different rear version but it's the same with all versions.
RedHat Version 7 is working fine.
I tested as well a Version 8 server about 1 year ago
with rear 2.61 and it was working without problmes
(no error at testprotocol).
Mybee you have an idee, why the python programms has such errors.
-
Workaround, if any:
-
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
# yum list
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/dnf/crypto.py", line 35, in <module>
from gpg import Context
File "/usr/lib64/python3.6/site-packages/gpg/__init__.py", line 123, in <module>
from . import core
ImportError: cannot import name 'core'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/yum", line 57, in <module>
from dnf.cli import main
File "/usr/lib/python3.6/site-packages/dnf/__init__.py", line 30, in <module>
import dnf.base
File "/usr/lib/python3.6/site-packages/dnf/base.py", line 35, in <module>
from dnf.db.history import SwdbInterface
File "/usr/lib/python3.6/site-packages/dnf/db/history.py", line 28, in <module>
from dnf.yum import misc
File "/usr/lib/python3.6/site-packages/dnf/yum/misc.py", line 29, in <module>
import dnf.crypto
File "/usr/lib/python3.6/site-packages/dnf/crypto.py", line 38, in <module>
import gpgme
ModuleNotFoundError: No
module named 'gpgme'
jsmeix commented at 2022-09-08 08:46:¶
@RolfWeilen
I know nothing at all about Python runtime stuff
so only an offhanded blind shot in the dark:
Do those programms which are using Python3
still work after a reboot of your original system?
Caution:
If those programms which are using Python3
do no longer work after a reboot of your original system
you may be left with a broken original system
and then you would need ReaR to restore it
but that also fails so you may finally end up
with an ultimate disaster of your original system.
My reasoning:
I guess that the root cause is not the ReaR recovery
but that it works by luck in the running original system
(in particular with what is in its main memory, e.g. caches)
while it would not work whith only the files on the disk
of the original system so it fails when the original system
is restarted from scratch (i.e. rebooted with only what
there is in its files on its disk).
jsmeix commented at 2022-09-08 08:51:¶
@pcahyna
because this issue is about RHEL
could you have a look here
as far as time permits?
pcahyna commented at 2022-09-08 09:24:¶
That's a strange problem. Note that restoration of the Python files (or any other files) is not directly ReaR's job, but the backup program's job (TSM here, given that BACKUP=TSM is being used). Could there be something wrong with the TSM backup, or its restoration? I am afraid I won't be able to offer much help, as I don't know anything about TSM. But I would recommend extracting the TSM backup to a subdirectory on some working system, chroot to that subdirectory, and running the same command that is failing.
jsmeix commented at 2022-09-08 10:12:¶
If something went wrong with TSM backup restore
I expect that the dsmc_exit_code handling code in
restore/TSM/default/400_restore_with_tsm.sh
shows appropriate messages to the user.
https://github.com/rear/rear/files/9506934/rear-h51ll60.log
shows (excerpts):
2022-09-07 15:44:56.585717904 The following filesystems will be restored:
2022-09-07 15:44:56.589001617 /
2022-09-07 15:44:56.592912929 /app/lib
2022-09-07 15:44:56.597127693 /boot
2022-09-07 15:44:56.600914320 /home
2022-09-07 15:44:56.604671886 /usr/local
2022-09-07 15:44:56.608383830 /var/log
2022-09-07 15:44:56.611438253 /var/log/suva
...
2022-09-07 15:47:00.666255270 Restoring TSM filespace / completed successfully
2022-09-07 15:47:06.240575920 Restoring TSM filespace /app/lib/ completed successfully
2022-09-07 15:47:11.919888099 Restoring TSM filespace /boot/ completed successfully
2022-09-07 15:47:18.413503641 Restoring TSM filespace /home/ completed successfully
2022-09-07 15:47:23.977837501 Restoring TSM filespace /usr/local/ completed successfully
2022-09-07 15:47:29.567765968 Restoring TSM filespace /var/log/ completed successfully
2022-09-07 15:47:35.431620947 Restoring TSM filespace /var/log/suva/ completed successfully
and the above lsblk output contains (excerpts)
|-/dev/vda1 /dev/vda1 /dev/vda part xfs 2G /boot
...
|-/dev/mapper/h51ll60vg00-root /dev/dm-0 /dev/vda2 lvm xfs 20G /
|-/dev/mapper/h51ll60vg00-alib /dev/dm-2 /dev/vda2 lvm xfs 5G /app/lib
|-/dev/mapper/h51ll60vg00-home /dev/dm-3 /dev/vda2 lvm xfs 5G /home
|-/dev/mapper/h51ll60vg00-vlsu /dev/dm-4 /dev/vda2 lvm xfs 5G /var/log/suva
|-/dev/mapper/h51ll60vg00-vlog /dev/dm-5 /dev/vda2 lvm xfs 5G /var/log
`-/dev/mapper/h51ll60vg00-uloc /dev/dm-6 /dev/vda2 lvm xfs 5G /usr/local
so all mounted filesystems were restored "correctly"
(according to what TSM reports).
Perhaps the TSM backup might be incomplete
e.g. some Python3 related files were not included?
But that would not be ReaR's problem because
the user is responsible to include in his backup
all what is needed to recreate his system as he needs,
cf. "Relax-and-Recover versus backup and restore" in
https://en.opensuse.org/SDB:Disaster_Recovery
RolfWeilen commented at 2022-09-09 08:55:¶
Hi
I will investigate it further.
But all files are include in the backup. As well the backup and restore
has no error.
On RHEL 7 System (same filesystems) the restore with rear works.
As well i think it's not a problem of rear itself, because the system is
booting without problems after recover.
We have now the newest RHEL Version 8.6. I try to do a restore with
previus Version of RHEL.
Keep inform you
gdha commented at 2022-09-09 10:40:¶
@RolfWeilen When I look at the source of the python script:
[/usr/lib/python3.6/site-packages/dnf]#
#-> more crypto.py
from __future__ import print_function
from __future__ import absolute_import
from __future__ import unicode_literals
from dnf.i18n import _
import contextlib
import dnf.pycomp
import dnf.util
import dnf.yum.misc
import io
import logging
import os
import tempfile
try:
from gpg import Context
from gpg import Data
except ImportError:
import gpgme
I noticed that in your case the script fails when trying to import
gpgme which it should do in the first place. Can you confirm that the
directory /usr/lib/python3.6/site-packages/dnf was properly restored?
In my case I see:
#-> ls
base.py comps.py crypto.py drpm.py history.py lock.py module plugin.py query.py rpm subject.py util.py
callback.py conf db exceptions.py i18n.py logging.py package.py __pycache__ repodict.py sack.py transaction.py yum
cli const.py dnssec.py goal.py __init__.py match_counter.py persistor.py pycomp.py repo.py selector.py transaction_sr.py
RolfWeilen commented at 2022-09-10 16:58:¶
Hi
I have found a missmatch between restored and new system. There are some
missing files.
No idee why there are missing.
But it has nothing to do with rear.
I will inform you when i know what happend.
Thank a lot for your support.
regards
Rolf
RolfWeilen commented at 2022-09-11 08:05:¶
Hi
I have found the files where are missing. Not all Files are in the
backup and as a result there was no restore of those files.
We can close the case.
Thanks for your input and best regards
Rolf
RolfWeilen commented at 2022-09-11 08:06:¶
close
jsmeix commented at 2022-09-12 06:57:¶
@RolfWeilen
thank you for the info what the actual reason was.
[Export of Github issue for rear/rear.]