Uyuni/SUSE Manager: Error synchronizing Oracle Linux 8 YUM repositories
In Uyuni 2024.07 and 2024.08 the synchronization of Oracle Linux 8 repositories is not possible without errors. The cause of the problem lies in the repositories, which do not correctly adhere to the specifications of modular repositories. The following error therefore appears during synchronization using spacewalk-repo-sync:
1# spacewalk-repo-sync -c oraclelinux8-appstream-x86_64
209:15:06 ======================================
309:15:06 | Channel: oraclelinux8-appstream-x86_64
409:15:06 ======================================
509:15:06 Sync of channel started.
6Retrieving repository 'oraclelinux8-appstream-x86_64' metadata .....[done]
7Building repository 'oraclelinux8-appstream-x86_64' cache ..........[done]
8All repositories have been refreshed.
909:15:19
1009:15:19 Importing modules file 72532a5ca796febe70f0b6b2122739db1d79a7b72a5b1a6139e34e2594778204-modules.yaml.gz.
1109:15:19 *** NOTE: Importing modules file for the channel 'oraclelinux8-appstream-x86_64'. Previous modules will be discarded.
1209:15:20 An error occurred while reading module metadata: An error occurred while indexing a module entry:
1309:15:20 Failed to parse buildorder in component: 18446744073709551615: The integer value is larger than 9223372036854775807 [line 158 col 9]
1409:15:20 Failed to parse buildorder in component: 18446744073709551615: The integer value is larger than 9223372036854775807 [line 158 col 9]
1509:15:20 Failed to parse buildorder in component: 18446744073709551615: The integer value is larger than 9223372036854775807 [line 170 col 9]
1609:15:20 Failed to parse buildorder in component: 18446744073709551615: The integer value is larger than 9223372036854775807 [line 175 col 9]
1709:15:20 Failed to parse buildorder in component: 18446744073709551615: The integer value is larger than 9223372036854775807 [line 157 col 9]
A workaround is documented in the project's bug tracker. Until the openSUSE project delivers the updated version of the libmodulemd library (2.15.0, 2.13.0 is installed), a new version can be manually compiled on a second system.
This requires either an openSUSE Leap 15 SP5/SP6, Tumbleweed or SLES system, in which the source code is checked out and compiled. The architecture must match that of the target system (e.g. x86_64).
First, the required development tools must be installed:
1# zypper in git meson cmake {rpm,libyaml,gobject-introspection}-devel {gtk,glib2}-doc
The source code of the libmodulemd library in version 2.15.0 is then checked out:
1$ git clone https://github.com/fedora-modularity/libmodulemd.git
2$ cd libmodulemd/
3$ git checkout 2.15.0
In one line of the file meson_options.txt the value of the parameter accept_overflowed_buildorder must be set from false to true:
1option('accept_overflowed_buildorder', type : 'boolean', value: 'true', description : 'Accept overflowed 18446744073709551615 buildorder as -1. This breaks a specification, but some RHEL 8 module builds look like that.')
In the next step, the source code is compiled:
1$ meson setup buildir
2$ cd buildir
3$ ninja
The compiled library can then be found in the builddir folder - this must be copied into the target container. For this purpose, symbolic links must also be adapted:
1# cp libmodulemd.so.2.15.0 /usr/lib64/
2# cd /usr/lib64
3# rm libmodulemd.so.2
4# ln -s /usr/lib64/libmodulemd.so.2.15.0 /usr/lib64/libmodulemd.so.2
5# ls -la /usr/lib64/*modulemd*
6lrwxrwxrwx. 1 root root 21 Aug 29 13:32 libmodulemd.so.2 -> libmodulemd.so.2.15.0
7-rwxr-xr-x. 1 root root 482088 May 8 2022 libmodulemd.so.2.13.0
8-rw-r--r--. 1 root root 2273656 Aug 29 13:31 libmodulemd.so.2.15.0
This change is not persistent and must be repeated after every restart of the container.
The synchronization then works again as usual.