Description of problem: Customer is using properly defined custom repositories, the preugprade begins but fails early due to a missing /var/lib/leapp/el8userspace/etc/yum.repos.d. Removing the directory and trying again does not help. Version-Release number of selected component (if applicable): 0.16 How reproducible: Always for the customer, unable to reproduce internally. Steps to Reproduce: 1. Define custom HTTP repositories for el7 in /etc/yum.repos.d and custom HTTP repos for el8 in /etc/leapp/files/leapp_upgrade_repositories.repo 2. Execute leapp by enabling those custom el8 repos and disable rhsm Actual results: Traceback (most recent call last): File "/usr/lib64/python2.7/multiprocessing/process.py", line 258, in _bootstrap self.run() File "/usr/lib64/python2.7/multiprocessing/process.py", line 114, in run self._target(*self._args, **self._kwargs) File "/usr/lib/python2.7/site-packages/leapp/repository/actor_definition.py", line 72, in _do_run actor_instance.run(*args, **kwargs) File "/usr/lib/python2.7/site-packages/leapp/actors/__init__.py", line 335, in run self.process(*args) File "/usr/share/leapp-repository/repositories/system_upgrade/common/actors/targetuserspacecreator/actor.py", line 52, in process userspacegen.perform() File "/usr/lib/python2.7/site-packages/leapp/utils/deprecation.py", line 42, in process_wrapper return target_item(*args, **kwargs) File "/usr/share/leapp-repository/repositories/system_upgrade/common/actors/targetuserspacecreator/libraries/userspacegen.py", line 681, in perform _create_target_userspace(context, indata.packages, indata.files, target_repoids) File "/usr/share/leapp-repository/repositories/system_upgrade/common/actors/targetuserspacecreator/libraries/userspacegen.py", line 655, in _create_target_userspace _prep_repository_access(context, target_path) File "/usr/share/leapp-repository/repositories/system_upgrade/common/actors/targetuserspacecreator/libraries/userspacegen.py", line 246, in _prep_repository_access files_owned_by_rpms = _get_files_owned_by_rpms(target_context, '/etc/yum.repos.d') File "/usr/share/leapp-repository/repositories/system_upgrade/common/actors/targetuserspacecreator/libraries/userspacegen.py", line 214, in _get_files_owned_by_rpms for fname in os.listdir(context.full_path(dirpath)): OSError: [Errno 2] No such file or directory: '/var/lib/leapp/el8userspace/etc/yum.repos.d' Additional info: - I didn't find anything in the logs or even in the strace which could explain this: 13463 16:48:04.672460 openat(AT_FDCWD, "/var/lib/leapp/el8userspace/etc/yum.repos.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory) <0.000009> - Creating the directory in question and copying the repo file workarounds the issue: In `/usr/share/leapp-repository/repositories/system_upgrade/common/actors/targetuserspacecreator/libraries/userspacegen.py`, at the beginning of _get_files_owned_by_rpms(), adding these lines before the error occurs: if dirpath == "/etc/yum.repos.d": api.current_logger().debug('RECREATING YUM.REPOS.D') run(['cp', '-rf', '/etc/yum.repos.d', '/var/lib/leapp/el8userspace/etc/']) run(['cp', '-f', '/etc/leapp/files/leapp_upgrade_repositories.repo', '/var/lib/leapp/el8userspace/etc/yum.repos.d/'])
Discussed internally, it's possible the bug could be fixed by the redesigned use of OVL during in-place upgrades: https://github.com/oamg/leapp-repository/pull/1097 Is customer willing to test the upstream devel build? As we cannot reproduce the issue, we have no way to anyhow test whether the problem has been resolved or not. Upstream COPR repo file, modified for s390x (note the x86:64 in url is ok): ~~~~ [copr:copr.fedorainfracloud.org:group_oamg:leapp] name=Copr repo for leapp owned by @oamg baseurl=https://download.copr.fedorainfracloud.org/results/@oamg/leapp/epel-7-x86_64/ type=rpm-md skip_if_unavailable=True gpgcheck=1 gpgkey=https://download.copr.fedorainfracloud.org/results/@oamg/leapp/pubkey.gpg repo_gpgcheck=0 enabled=1 enabled_metadata=1 ~~~~ For the installation execute: ~~~ # yum install leapp-upgrade -y ~~~ In case of testing with the devel builds, we suggest to execute leapp with the --target option, e.g.: # leapp preupgrade --target 8.8 --debug Note: Setting the stale date to May 2024.