Rocky Linux 9.x aarch64: bad AppStream repo yaml file?

I have a few Rocky Linux 8 and 9 machines, of both x86_64 and aarch64 architecture, which regularly pull updates using dnf update.

Very recently, the Rocky Linux 9 aarch64 machines begin failing with:

Module yaml error: Parser error
terminate called after throwing an instance of 'libdnf::ModulePackageContainer::ResolveException'
what(): Failed to update from string: Unexpected YAML event in document stream [line 1 col 1]
Aborted

This is apparently while parsing one of the YAML files of the AppStream repository. That is, when I set enabled=0 for the [appstream] section in /etc/yum.repos.d/rocky.repo, the problem disappears.

Full transcript from a docker session:

% docker run -ti rockylinux:9
[root@a18d3b53294e /]# cat /etc/os-release
NAME="Rocky Linux"
VERSION="9.3 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.3"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Rocky Linux 9.3 (Blue Onyx)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:9::baseos"
HOME_URL="https://rockylinux.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
SUPPORT_END="2032-05-31"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-9"
ROCKY_SUPPORT_PRODUCT_VERSION="9.3"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.3"
[root@a18d3b53294e /]# uname -a
Linux a18d3b53294e 6.12.54-linuxkit #1 SMP Tue Nov  4 21:21:47 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux
[root@a18d3b53294e /]# dnf update
Rocky Linux 9 - BaseOS                           16 MB/s | 7.5 MB     00:00
Rocky Linux 9 - AppStream                        24 MB/s |  11 MB     00:00
Rocky Linux 9 - Extras                          1.1 kB/s |  17 kB     00:15
Module yaml error: Parser error
terminate called after throwing an instance of 'libdnf::ModulePackageContainer::ResolveException'
  what():  Failed to update from string: Unexpected YAML event in document stream [line 1 col 1]
Aborted

Having found a similar issue in Dnf (yum) suddenly stopped working on RockyLinux 8 machines - Support - TheForeman , I tried using strace as they did there:

openat(AT_FDCWD, "/var/cache/dnf/appstream-056c207c7f3c6316/repodata/c32a428b8b4e706b6fd51aa79ebe336585c3aaf0675b0c18a02a10b7303a3869-modules.yaml.xz", O_RDONLY) = 8
fstat(8, {st_mode=S_IFREG|0644, st_size=8596, ...}) = 0
..
write(2, "Module yaml error: ", 19)     = 19
write(2, "Parser error", 12)            = 12
write(2, "\n", 1)                       = 1
write(2, "terminate called after throwing "..., 48) = 48
write(2, "libdnf::ModulePackageContainer::"..., 48) = 48
...
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=944, si_uid=0} ---
+++ killed by SIGABRT (core dumped) +++

If I uncompress the c32a428b8b4e706b6fd51aa79ebe336585c3aaf0675b0c18a02a10b7303a3869-modules.yaml.xz file, I seems to start fairly normally:

# head -20 c32a428b8b4e706b6fd51aa79ebe336585c3aaf0675b0c18a02a10b7303a3869-modules.yaml
---
document: modulemd-defaults
version: 1
data:
  module: mariadb
  profiles:
    10.11: [server]
...
---
document: modulemd
version: 2
data:
  name: mariadb
  stream: "10.11"
  version: 9070020251119234135
  context: rhel9
  static_context: true
  arch: aarch64
  summary: MariaDB Module
  description: >-

Does anybody have an idea what might be wrong?

It looks like this only happens for aarch64, and Rocky Linux 9. x86_64 fine.

[Edited to indicate that this affects the latest Rocky 9.x. It’s a Docker artifact that the most recent rockylinux:9 tag seems to point at 9.3].

Okay, some further debugging with a YAML validator showed that there is a parse error in the c32a428b8b4e706b6fd51aa79ebe336585c3aaf0675b0c18a02a10b7303a3869-modules.yaml file, at line 2690:

yaml.scanner.ScannerError: while scanning a simple key
  in "c32a428b8b4e706b6fd51aa79ebe336585c3aaf0675b0c18a02a10b7303a3869-modules.yaml", line 2690, column 1
could not find expected ':'
  in "c32a428b8b4e706b6fd51aa79ebe336585c3aaf0675b0c18a02a10b7303a3869-modules.yaml", line 2691, column 1

The file around that part looks like:

    - rubygem-rbs-debuginfo-0:3.4.0-5.module+el9.7.0+40039+300ba1ed.aarch64
    - rubygem-rdoc-0:6.6.3.1-5.module+el9.7.0+40039+300ba1ed.noarch
    - rubygem-rexml-0:3.4.4-5.module+el9.7.0+40039+300ba1ed.noarch
    - rubygem-rss-0:0.3.1-5.module+el9.7.0+40039+300ba1ed.noarch
    - rubygem-test-unit-0:3.6.1-5.module+el9.7.0+40039+300ba1ed.noarch
    - rubygem-typeprof-0:0.21.9-5.module+el9.7.0+40039+300ba1ed.noarch
    - rubygems-0:3.5.22-5.module+el9.7.0+40039+300ba1ed.noarch
    - rubygems-devel-0:3.5.22-5.module+el9.7.0+40039+300ba1ed.noarch
..
---
document: modulemd
version: 2
data:
  name: mysql
  stream: "8.4"
  version: 9070020251211173557
  context: rhel9
  static_context: true
  arch: aarch64
  summary: MySQL Module
  description: >-

The .. line is exactly line 2690. It looks like somebody made a mistake when making the modules.yaml file for createrepo.

Should I file a bug in the bug tracker for this?

In the mean time, the repository’s repodata folder has been rotated due to updates, and the modules.yaml file is now OK.

1 Like

I also still have this issue, on new docker build also, so no cache.

How are you testing this? I just re-checked it here in a docker container (aarch64 host):

% docker run -ti rockylinux:9
[root@a53625d86869 /]# yum makecache
Rocky Linux 9 - BaseOS                           18 MB/s | 7.5 MB     00:00
Rocky Linux 9 - AppStream                        23 MB/s |  11 MB     00:00
Rocky Linux 9 - Extras                           84 kB/s |  17 kB     00:00
Metadata cache created.

No problems at all.

Even after having cleaned up images and all, the build still failed with the same error. Strangely, I retried an hour later and it worked fine. Maybe I hit a particular mirror that had not been updated. Go figure.