Bug 1640235

It works properly with dnf 3.5.1 shipped with fc29 beta 1.5

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 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: Exec failed: attempt to write a readonly database

Proposed as a Blocker for 29-final by Fedora user jlanda using the blocker tracking app because:

 I'm filling this because @mattdm asked. Our concern is not the bug itself violates any criteria but because a major version update during freezing creates at least one new regression bug.

We are working on solutions

It's very annoying, but it doesn't violate any blocker criteria nor does it have issues when run as root (as it would be whenever actual changes are desired).

-1 blocker, but +1 FE.

There is a patch that solves the issue (https://github.com/rpm-software-management/libdnf/pull/616). I am going to release it.

libdnf-0.22.0-3.fc29 (https://koji.fedoraproject.org/koji/buildinfo?buildID=1154424) doesn't fix the issue:

***

$dnf info kernel

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 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/lib64/python3.7/site-packages/libdnf/transaction.py", line 788, in getRPMRepo
    return _transaction.Swdb_getRPMRepo(self, nevra)
RuntimeError: Statement: attempt to write a readonly database in

        SELECT
            repo.repoid as repoid
        FROM
            trans_item ti
        JOIN
            rpm USING (item_id)
        JOIN
            repo ON ti.repo_id == repo.id
        WHERE
            ti.action not in (3, 5, 7, 10)
            AND rpm.name = ?
            AND rpm.epoch = ?
            AND rpm.version = ?
            AND rpm.release = ?
            AND rpm.arch = ?
        ORDER BY
            ti.id DESC
        LIMIT 1;

Please the fix is applied after first command that opens swdb but it has to be run as a root. Like "sudo dnf list"

Ahh, okay.  This should be documented in upgrade as well.

```
After installing this update you need to run dnf as root user once.  After that querries can be performed by any unprivileged user as usual.
```

The patch is part of libdnf-0.22.0-3.fc29 and I would like to update https://bodhi.fedoraproject.org/updates/FEDORA-2018-2789f6b6e7 to replace libdnf-0.22.0-2.fc29 by libdnf-0.22.0-3.fc29 but there is a lock at the present time. Please can you help me?

(In reply to Jaroslav Mracek from comment #10)
> The patch is part of libdnf-0.22.0-3.fc29 and I would like to update
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-2789f6b6e7 to replace
> libdnf-0.22.0-2.fc29 by libdnf-0.22.0-3.fc29 but there is a lock at the
> present time. Please can you help me?

You need to wait until the Masher process (https://bodhi.fedoraproject.org/masher/) has finished.  After that the update can be edited again.

anaconda-29.24.6-1.fc29 dnf-4.0.4-1.fc29 dnf-plugins-core-4.0.0-2.fc29 libblockdev-2.20-2.fc29 libdnf-0.22.0-3.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2789f6b6e7

New build has been added to the update.  If you need this build to be present in updates-testing immediately, please ask Releng to perform a second push for Fedora 29 u-t.

The problem in this bag was introduced by libdnf-0.22.0-1 about 3 days ago (to resolve a locking db if multiple users use dnf/libdnf). Only users of rawhide or testers of Fedora 29 could be affected by the issue.

What about users upgrading from an earlier release of Fedora?  Don't they run into a scenario, where they need to run dnf as root once, before other users can use it without stumbling into this issue?

No, problem was introduce by commit https://github.com/rpm-software-management/libdnf/commit/6cfe4187978d36bb50c940db7b2aadce050d7042 merged on October 3rd into master. The release was on October 15th (libdnf-0.22.0-1) into rawhide and F29, but it was only in testing.

Discussed during the 2018-10-18 Fedora 29 Go/No-Go meeting: [1]

The decision to classify this bug as a "RejectedBlocker" and an "AcceptedFreezeException" was made as this does not violate any blocker criteria but should be fixed if DNF 4 is included in F29.

[1] https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-10-18/f29-final-go_no_go-meeting.2018-10-18-17.00.log.txt

*** Bug 1639986 has been marked as a duplicate of this bug. ***

*** Bug 1639863 has been marked as a duplicate of this bug. ***

anaconda-29.24.7-1.fc29, dnf-4.0.4-1.fc29, dnf-plugins-core-4.0.0-2.fc29, libblockdev-2.20-2.fc29, libdnf-0.22.0-5.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2789f6b6e7

anaconda-29.24.7-1.fc29, dnf-4.0.4-1.fc29, dnf-plugins-core-4.0.0-2.fc29, libblockdev-2.20-2.fc29, libdnf-0.22.0-5.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

Similar problem has been detected:

Viewing listing software as user i.e. "dnf list <package> led to traceback. Issue occured since dnf-4.0.4

reporter:       libreport-2.9.6
cmdline:        /usr/bin/python3 /usr/bin/dnf list gstreamer*
crash_function: __init__
exception_type: RuntimeError
executable:     /usr/bin/dnf
interpreter:    python3-3.7.0-9.fc29.x86_64
kernel:         4.18.14-300.fc29.x86_64
package:        dnf-4.0.4-1.fc29
reason:         transaction.py:729:__init__:RuntimeError: Exec failed: attempt to write a readonly database
runlevel:       N 5
type:           Python3
uid:            1000

You need to run dnf as root user once after updating, as pointed out in the update notes.