Description of problem: Running `dnf info [packagename]` always fails when running as a user. This issue may be a result of the fact that I have set `umask 0077` to my root account and thus files or directories are created incorrectly when running dnf as root. Version-Release number of selected component: dnf-3.6.1-1.fc29 Additional info: reporter: libreport-2.9.5 cmdline: /usr/bin/python3 /usr/bin/dnf info gnome-todo crash_function: __init__ exception_type: RuntimeError executable: /usr/bin/dnf interpreter: python3-3.7.0-9.fc29.x86_64 kernel: 4.18.12-300.fc29.x86_64 runlevel: N 5 type: Python3 Truncated backtrace: transaction.py:729:__init__:RuntimeError: Open failed Traceback (most recent call last): File "/usr/bin/dnf", line 58, in <module> main.user_main(sys.argv[1:], exit_code=True) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 179, in user_main errcode = main(args) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main return _main(base, args, cli_class, option_parser_class) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in _main return cli_run(cli, base) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 115, in cli_run cli.run() File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 1051, in run return self.command.run() File "/usr/lib/python3.7/site-packages/dnf/cli/commands/__init__.py", line 219, in run self.opts.packages) File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 438, in output_packages '=' : clir, 'not in' : clie}) File "/usr/lib/python3.7/site-packages/dnf/cli/output.py", line 633, in listPkgs print(self.infoOutput(pkg, highlight=highlight) + "\n") File "/usr/lib/python3.7/site-packages/dnf/cli/output.py", line 504, in infoOutput history_repo = self.history.repo(pkg) File "/usr/lib/python3.7/site-packages/dnf/db/history.py", line 362, in repo return self.swdb.getRPMRepo(str(pkg)) File "/usr/lib/python3.7/site-packages/dnf/db/history.py", line 291, in swdb self._swdb = libdnf.transaction.Swdb(self.dbpath) File "/usr/lib64/python3.7/site-packages/libdnf/transaction.py", line 729, in __init__ this = _transaction.new_Swdb(*args) RuntimeError: Open failed Local variables in innermost frame: self: <libdnf.transaction.Swdb; > args: ('/var/lib/dnf/history.sqlite',)
Created attachment 1491548 [details] File: backtrace
Created attachment 1491549 [details] File: cpuinfo
Created attachment 1491550 [details] File: dnf-makecache.log
Created attachment 1491551 [details] File: namespaces
Created attachment 1491552 [details] File: _var_log_dnf.log
See also: bug #1154272 When run with `--cacheonly` option, I get a more clear error message: $ LC_ALL=C dnf --cacheonly info dnf [Errno 13] Permission denied: '/var/cache/dnf/expired_repos.json' So it looks like this file is created without making sure to get correct permissions. Running # chmod og+r /var/cache/dnf/expired_repos.json works around the issue for that file, but other caches are also not available.
I think the Fedora 29 version of dnf is just broken for running as non-root. Still broken with dnf-4.0.4-1.fc29. dnf info packagename dnf list packagename dnf list obsoletes all fail with a similar backtrace: Traceback (most recent call last): File "/usr/bin/dnf", line 58, in <module> main.user_main(sys.argv[1:], exit_code=True) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 179, in user_main errcode = main(args) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main return _main(base, args, cli_class, option_parser_class) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in _main return cli_run(cli, base) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 115, in cli_run cli.run() File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 1055, in run return self.command.run() File "/usr/lib/python3.7/site-packages/dnf/cli/commands/__init__.py", line 232, in run self.opts.packages) File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 402, in output_packages columns = _list_cmd_calc_columns(self.output, ypl) File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 109, in _list_cmd_calc_columns _add_pkg_simple_list_lens(data, opkg, indent=" " * 4) File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 93, in _add_pkg_simple_list_lens rid = len(pkg._from_repo) File "/usr/lib/python3.7/site-packages/dnf/package.py", line 84, in _from_repo pkgrepo = self.base.history.repo(self) File "/usr/lib/python3.7/site-packages/dnf/db/history.py", line 362, in repo return self.swdb.getRPMRepo(str(pkg)) File "/usr/lib/python3.7/site-packages/dnf/db/history.py", line 291, in swdb self._swdb = libdnf.transaction.Swdb(self.dbpath) File "/usr/lib64/python3.7/site-packages/libdnf/transaction.py", line 729, in __init__ this = _transaction.new_Swdb(*args) RuntimeError: Failed to open backup database: /var/lib/dnf/history.sqlite On my system, dnf is never run as root, /var/lib/dnf/ is empty, /var/cache/dnf/ contained some files dating from 2016, deleting those made no difference.
I'm also seeing this on Fedora 28 in OpenStack CI. dnf returns the information queried but returns a non-zero exit code. $ dnf info installed qemu-img* 2018-12-24 03:49:00.772 | [Errno 13] Permission denied: '/var/cache/dnf/expired_repos.json' 2018-12-24 03:49:00.772 | Installed Packages 2018-12-24 03:49:00.772 | Name : qemu-img 2018-12-24 03:49:00.772 | Epoch : 2 2018-12-24 03:49:00.772 | Version : 2.11.2 2018-12-24 03:49:00.772 | Release : 4.fc28 2018-12-24 03:49:00.772 | Arch : x86_64 2018-12-24 03:49:00.772 | Size : 5.0 M 2018-12-24 03:49:00.772 | Source : qemu-2.11.2-4.fc28.src.rpm 2018-12-24 03:49:00.772 | Repo : @System 2018-12-24 03:49:00.772 | From repo : updates 2018-12-24 03:49:00.773 | Summary : QEMU command line tool for manipulating disk images 2018-12-24 03:49:00.773 | URL : http://www.qemu.org/ 2018-12-24 03:49:00.773 | License : GPLv2 and BSD and MIT and CC-BY 2018-12-24 03:49:00.773 | Description : This package provides a command line tool for manipulating disk 2018-12-24 03:49:00.773 | : images 2018-12-24 03:49:00.773 | 2018-12-24 03:49:00.805 | Required package qemu-img is not installed. Exiting. libdnf-0.11.1-6.fc28.1.x86_64 dnf-plugins-core-2.1.5-4.fc28.noarch dnf-conf-2.7.5-12.fc28.noarch python3-dnf-plugins-core-2.1.5-4.fc28.noarch python3-dnf-2.7.5-12.fc28.noarch python2-dnf-2.7.5-12.fc28.noarch dnf-2.7.5-12.fc28.noarch CI logs: http://logs.openstack.org/81/600381/8/check/octavia-v2-dsvm-scenario-fedora-latest/995e2cf/controller/logs/devstacklog.txt.gz On my local Fedora 29, permissions permit reading the file: $ dnf info installed qemu-img* Installed Packages Name : qemu-img Epoch : 2 Version : 3.0.0 Release : 2.fc29 Arch : x86_64 Size : 5.1 M Source : qemu-3.0.0-2.fc29.src.rpm Repo : @System From repo : updates Summary : QEMU command line tool for manipulating disk images URL : http://www.qemu.org/ License : GPLv2 and BSD and MIT and CC-BY Description : This package provides a command line tool for manipulating disk images $ ls -la /var/cache/dnf/expired_repos.json -rw-r--r--. 1 root root 2 Dec 24 03:54 /var/cache/dnf/expired_repos.json $ rpm -qa *dnf* python3-libdnf-0.22.3-1.fc29.x86_64 dnf-data-4.0.9-2.fc29.noarch dnf-yum-4.0.9-2.fc29.noarch python3-dnf-plugin-system-upgrade-4.0.0-1.fc29.noarch dnf-4.0.9-2.fc29.noarch dnf-plugins-core-4.0.2-1.fc29.noarch libdnf-0.22.3-1.fc29.x86_64 python3-dnf-plugins-core-4.0.2-1.fc29.noarch python3-dnf-4.0.9-2.fc29.noarch python3-dnf-plugins-extras-common-4.0.0-1.fc29.noarch
Steps to reproduce: 1. run `dnf update` as root 2. run `dnf info [packagename]` as unprivileged user
> RuntimeError: Failed to open backup database: /var/lib/dnf/history.sqlite This problem should be fixed in: https://github.com/rpm-software-management/libdnf/pull/765 Then there's another problem with expired_repos.json: $ sudo rm /var/cache/dnf/expired_repos.json $ dnf info -C bash [Errno 13] Permission denied: '/var/cache/dnf/expired_repos.json' This one should be fixed in: https://github.com/rpm-software-management/dnf/pull/1448
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Issue is still present. Will it ever be fixed?
Created attachment 1663374 [details] Make dnf work again The problem seems to be that dnf falls over if this history database is not available (due to access permissions, or in my case, because it does not exist at all). Patching dnf to ignore those history database exceptions restores basic dnf operations involving querying installed packages. With that patch, I can now do "dnf list obsoletes" again.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still present on Fedora 33: $ LC_ALL=C dnf --cacheonly info dnf Failed to load expired repos cache: [Errno 13] Permission denied: '/var/cache/dnf/expired_repos.json' Version info: dnf-4.4.0-3.fc33.noarch libdnf-0.54.2-3.fc33.x86_64 python3-dnf-4.4.0-3.fc33.noarch
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Issue still present as in comment #16
This issue is overlapping with #1154272 so I'm closing it in favor of that one. *** This bug has been marked as a duplicate of bug 1154272 ***
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days