Fedora Account System
Red Hat Associate
Red Hat Customer
When the libdnf5-plugin-notify-PackageKit package is installed on Fedora 43, Ansible's "dnf" module no longer works. Reproducible: Always Steps to Reproduce: 1. On a fresh Fedora 43 system or toolbox, install the "ansible-core" package 2. Run "sudo ansible -m dnf -a 'name=bash' localhost" 3. Ansible should report that the package is installed. 4. Install the libdnf5-plugin-notify-PackageKit (it installs libdnf5-plugin-notify-PackageKit-0:1.3.1-2.fc43.x86_64 in my test) 5. Run the same ansible command again: "sudo ansible -m dnf -a 'name=bash' localhost" 6. Error is generated. Actual Results: I get this error: $ sudo ansible -m package -a 'name=bash' localhost localhost | FAILED! => { "changed": false, "failures": [], "msg": "Cannot load libdnf plugin enabled from: /etc/dnf/libdnf5-plugins/notify_packagekit.conf", "rc": 1 } Expected Results: $ sudo ansible -m package -a 'name=bash' localhost localhost | SUCCESS => { "changed": false, "msg": "Nothing to do", "rc": 0, "results": [] } Additional Information: I don't see this in Fedora 42, but there's also no libdnf5-plugin-notify-PackageKit package in Fedora 42.
The plugin exists in F42, with the exception that it uses `libsdbus-c++.so.1` vs `libsdbus-c++.so.2` in F43+. The plugin loads fine outside of ansible. What's different about that environment? How can we get more verbose logs from libdnf5? https://github.com/rpm-software-management/dnf5/blob/ee6508004c0ec96151ee8fb626858940b6052b8f/libdnf5/plugin/plugins.cpp#L149
I forgot to explain that the plugin exists in F42 as part of the main PackageKit package; it was split into a dedicated subpackage in F43.
with -vvv we get this: <127.0.0.1> ESTABLISH LOCAL CONNECTION FOR USER: root <127.0.0.1> EXEC /bin/sh -c 'echo ~root && sleep 0' <127.0.0.1> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo /root/.ansible/tmp `"&& mkdir "` echo /root/.ansible/tmp/ansible-tmp-1758925221.3186672-4621-80204330721445 `" && echo ansible-tmp-1758925221.3186672-4621-80204330721445="` echo /root/.ansible/tmp/ansible-tmp-1758925221.3186672-4621-80204330721445 `" ) && sleep 0' Using module file /usr/lib/python3.14/site-packages/ansible/modules/setup.py <127.0.0.1> PUT /root/.ansible/tmp/ansible-local-4617f2j1alsj/tmpadietry8 TO /root/.ansible/tmp/ansible-tmp-1758925221.3186672-4621-80204330721445/AnsiballZ_setup.py <127.0.0.1> EXEC /bin/sh -c 'chmod u+rwx /root/.ansible/tmp/ansible-tmp-1758925221.3186672-4621-80204330721445/ /root/.ansible/tmp/ansible-tmp-1758925221.3186672-4621-80204330721445/AnsiballZ_setup.py && sleep 0' <127.0.0.1> EXEC /bin/sh -c '/usr/bin/python3 /root/.ansible/tmp/ansible-tmp-1758925221.3186672-4621-80204330721445/AnsiballZ_setup.py && sleep 0' Using module file /usr/lib/python3.14/site-packages/ansible/modules/dnf5.py <127.0.0.1> PUT /root/.ansible/tmp/ansible-local-4617f2j1alsj/tmpz1lbw_9s TO /root/.ansible/tmp/ansible-tmp-1758925221.3186672-4621-80204330721445/AnsiballZ_dnf5.py <127.0.0.1> EXEC /bin/sh -c 'chmod u+rwx /root/.ansible/tmp/ansible-tmp-1758925221.3186672-4621-80204330721445/ /root/.ansible/tmp/ansible-tmp-1758925221.3186672-4621-80204330721445/AnsiballZ_dnf5.py && sleep 0' <127.0.0.1> EXEC /bin/sh -c '/usr/bin/python3 /root/.ansible/tmp/ansible-tmp-1758925221.3186672-4621-80204330721445/AnsiballZ_dnf5.py && sleep 0' <127.0.0.1> EXEC /bin/sh -c 'rm -f -r /root/.ansible/tmp/ansible-tmp-1758925221.3186672-4621-80204330721445/ > /dev/null 2>&1 && sleep 0' The full traceback is: File "/tmp/ansible_ansible.legacy.dnf5_payload__i37eif_/ansible_ansible.legacy.dnf5_payload.zip/ansible/modules/dnf5.py", line 826, in main Dnf5Module(module).run() ~~~~~~~~~~~~~~~~~~~~~~^^ File "/tmp/ansible_ansible.legacy.dnf5_payload__i37eif_/ansible_ansible.legacy.dnf5_payload.zip/ansible/modules/dnf5.py", line 633, in run base.setup() ~~~~~~~~~~^^ File "/usr/lib64/python3.14/site-packages/libdnf5/base.py", line 638, in setup return _base.Base_setup(self) ~~~~~~~~~~~~~~~~^^^^^^ localhost | FAILED! => { "ansible_facts": { "pkg_mgr": "dnf5" }, "changed": false, "failures": [], "invocation": { "module_args": { "allow_downgrade": false, "allowerasing": false, "auto_install_module_deps": true, "autoremove": false, "best": null, "bugfix": false, "cacheonly": false, "conf_file": null, "disable_excludes": null, "disable_gpg_check": false, "disable_plugin": [], "disablerepo": [], "download_dir": null, "download_only": false, "enable_plugin": [], "enablerepo": [], "exclude": [], "install_repoquery": true, "install_weak_deps": true, "installroot": "/", "list": null, "lock_timeout": 30, "name": [ "bash" ], "nobest": null, "releasever": null, "security": false, "skip_broken": false, "sslverify": true, "state": null, "update_cache": false, "update_only": false, "validate_certs": true } }, "msg": "Cannot load libdnf plugin enabled from: /etc/dnf/libdnf5-plugins/notify_packagekit.conf", "rc": 1 } so, ansible's actually using the dnf5 python bindings here...
Just to copy the note here: this isn't specific to ansible. It's trivially reproducible just by doing the same thing ansible is doing: >>> import libdnf5.base >>> base = libdnf5.base.Base() >>> conf = base.get_config() >>> base.load_config() >>> base.setup() Traceback (most recent call last): File "<python-input-4>", line 1, in <module> base.setup() ~~~~~~~~~~^^ File "/usr/lib64/python3.14/site-packages/libdnf5/base.py", line 638, in setup return _base.Base_setup(self) ~~~~~~~~~~~~~~~~^^^^^^ libdnf5.exception.Error: Cannot load libdnf plugin enabled from: /etc/dnf/libdnf5-plugins/notify_packagekit.conf
Looks like Neal backported a patch for this in https://bodhi.fedoraproject.org/updates/FEDORA-2025-39b49dbaaf .
FEDORA-2025-39b49dbaaf (PackageKit-1.3.1-6.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-39b49dbaaf
Fix confirmed. Thanks, Neal.
FEDORA-2025-39b49dbaaf (PackageKit-1.3.1-6.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.