#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"):

tested as well with

  • 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):

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
    local disk


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:

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?

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:

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
shows appropriate messages to the user.

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

RolfWeilen commented at 2022-09-09 08:55:

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:

#-> 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

    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:

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.


RolfWeilen commented at 2022-09-11 08:05:

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

RolfWeilen commented at 2022-09-11 08:06:


jsmeix commented at 2022-09-12 06:57:

thank you for the info what the actual reason was.

[Export of Github issue for rear/rear.]