pungi

#1783 Lua API mismatch version?
Closed: Fixed by kurokuo. Opened by kurokuo.

Closed: Fixed
Reopen Issue

Hi all,
When I want to pack my iso in rockylinux9.4, I faced an error message list below, it seems like an Lua API version mismatch. Is there any ways to solve this?


2024-09-03 06:37:15 [WARNING ] [SKIP ] ---------- PHASE: EXTRA_FILES ----------
2024-09-03 06:37:15 [INFO ] Config section 'ostree_container' was not found. Skipping.
2024-09-03 06:37:15 [INFO ] [BEGIN] Gathering packages (arch: x86_64, variant: BaseOS)
2024-09-03 06:37:15 [WARNING ] [SKIP ] ---------- PHASE: OSTREE ----------
2024-09-03 06:37:15 [INFO ] [DONE ] Running pipeline (3/5). Phases: extra_files
2024-09-03 06:37:15 [WARNING ] [SKIP ] ---------- PHASE: OSTREE_CONTAINER ----------
2024-09-03 06:37:15 [INFO ] Config section 'ostree_installer' was not found. Skipping.
2024-09-03 06:37:15 [INFO ] Cannot reuse old GATHER phase results - reuse of old gather results is disabled.
2024-09-03 06:37:15 [INFO ] [DONE ] Running pipeline (5/5). Phases: ostree_container
2024-09-03 06:37:15 [WARNING ] [SKIP ] ---------- PHASE: OSTREE_INSTALLER ----------
2024-09-03 06:37:15 [DEBUG ] Exporting file /workspace/Base/src/ks.cfg from current working directory...
2024-09-03 06:37:15 [INFO ] [DONE ] Running pipeline (4/5). Phases: ostree, ostree_installer

PANIC: unprotected error in call to Lua API (version mismatch: app. needs 503.0, Lua core provides 504.0)

Rockylinux9.4 used lua 5.4 as default

Pungi doesn't use Lua directly in any way. That error must be coming from some underlying tool. Was there a traceback that could point to more details?

Pungi doesn't use Lua directly in any way. That error must be coming from some underlying tool. Was there a traceback that could point to more details?

I found this error message will show when I added this config to general.conf. When I try to remove this config, no errors happened :(


module_defaults_dir = {
"scm": "file",
"dir": "/code/module.defaults/",
}

That would point towards libmodulemd. On my Fedora machine libmodulemd links against liblua.

Does modulemd-validator --help fail too?

Maybe libmodulemd needs to be rebuilt against new lua?

$ ldd /usr/lib64/libmodulemd.so.2
    linux-vdso.so.1 (0x00007f9968e6e000)
    libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f9968d5b000)
    libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f9968c0d000)
    librpmio.so.10 => /lib64/librpmio.so.10 (0x00007f9968bdc000)
    libyaml-0.so.2 => /lib64/libyaml-0.so.2 (0x00007f9968bbb000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f9968b8d000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f996899c000)
    libffi.so.8 => /lib64/libffi.so.8 (0x00007f996898a000)
    libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f99688ea000)
    libz.so.1 => /lib64/libz.so.1 (0x00007f99688c9000)
    libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f99688b5000)
    librpm_sequoia.so.1 => /lib64/librpm_sequoia.so.1 (0x00007f9968600000)
    liblua-5.4.so => /lib64/liblua-5.4.so (0x00007f9968870000)
    libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f9968541000)
    liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f996850e000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f9968e70000)
    libssl.so.3 => /lib64/libssl.so.3 (0x00007f9968437000)
    libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f9967e00000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f9968353000)

That would point towards libmodulemd. On my Fedora machine libmodulemd links against liblua.

Does modulemd-validator --help fail too?

Maybe libmodulemd needs to be rebuilt against new lua?

No, modulemd-validator --help got success!

[root@7b23402cf218 src]# modulemd-validator --help
Usage:
  modulemd-validator [OPTION…] FILES - Simple modulemd YAML validator
Help Options:
  -h, --help        Show help options
...

And ldd show these information, we think it is the same 

ldd /usr/lib64/libmodulemd.so.2
        linux-vdso.so.1 (0x00007ffdef3cf000)
        libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007febe0187000)
        libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007febe004c000)
        libmagic.so.1 => /lib64/libmagic.so.1 (0x00007febe001e000)
        librpmio.so.9 => /lib64/librpmio.so.9 (0x00007febdffe3000)
        libyaml-0.so.2 => /lib64/libyaml-0.so.2 (0x00007febdffc1000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007febdffa6000)
        libc.so.6 => /lib64/libc.so.6 (0x00007febdfd9b000)
        libffi.so.8 => /lib64/libffi.so.8 (0x00007febdfd8f000)
        libpcre.so.1 => /lib64/libpcre.so.1 (0x00007febdfd17000)
        libm.so.6 => /lib64/libm.so.6 (0x00007febdfc3c000)
        libz.so.1 => /lib64/libz.so.1 (0x00007febdfc22000)
        libbz2.so.1 => /lib64/libbz2.so.1 (0x00007febdfc0f000)
        libpopt.so.0 => /lib64/libpopt.so.0 (0x00007febdfbfe000)
        liblzma.so.5 => /lib64/liblzma.so.5 (0x00007febdfbd2000)
        libzstd.so.1 => /lib64/libzstd.so.1 (0x00007febdfafb000)
        liblua-5.4.so => /lib64/liblua-5.4.so (0x00007febdfab5000)
        libaudit.so.1 => /lib64/libaudit.so.1 (0x00007febdfa86000)
        libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007febdf653000)
        /lib64/ld-linux-x86-64.so.2 (0x00007febe0288000)
        libcap-ng.so.0 => /lib64/libcap-ng.so.0 (0x00007febdf648000)

Yeah, that indeed has liblua-5.4. I have no idea where the error is coming from then.
Maybe try using strace to find out more details about where exactly the crash is happening?

The only difference between pungi run with and without the module_defaults_dir is obtaining the files, processing them with libmodulemd (using Python API) and injecting the files into a repo with modifyrepo_c.

I found the root cause to this issue.

Root cause is on createrepo_c 1.14.0 binary which we installed from python pypi whl file. This version has a built-in liblua5.4.so which is not a compatible version. When we set fallback to use 0.20.0 (based on rocky9.4 official version), this issue disappeared.

Thanks for your help!!

Metadata Update from @kurokuo:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/pungi/pungi/issues/1783

Please continue any further discussion there.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.