Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1596827
Summary: | DNF 3 crashes with "UNIQUE constraint failed" for comps_environment_group.groupid or trans_with.trans_id | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | George R. Goffe <grgoffe> | ||||||
Component: | dnf | Assignee: | Daniel Mach <dmach> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | urgent | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 29 | CC: | awilliam, dmach, gmarr, grgoffe, mblaha, msuchy, packaging-team-maint, paul.destefano-redhat2, renault, robatino, rpm-software-management, samuel-rhbugs, sanjay.ankur, sgallagh, skpgkp1, tpopela, vmukhame | ||||||
Target Milestone: | --- | Keywords: | CommonBugs, Triaged | ||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | AcceptedBlocker https://fedoraproject.org/wiki/Common_F29_bugs#dnf-unique-constraint | ||||||||
Fixed In Version: | dnf-3.6.1-1.fc29 | Doc Type: | If docs needed, set a value | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2018-10-07 20:59:23 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 1517013, 1628844 | ||||||||
Attachments: |
|
My rawhide installation is also broken with similar error message. $ sudo dnf history Traceback (most recent call last): File "/bin/dnf", line 58, in <module> main.user_main(sys.argv[1:], exit_code=True) File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 179, in user_main errcode = main(args) File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 64, in main return _main(base, args, cli_class, option_parser_class) File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 95, in _main cli.configure(list(map(ucd, args)), option_parser()) File "/usr/lib/python3.6/site-packages/dnf/cli/cli.py", line 905, in configure self.command.configure() File "/usr/lib/python3.6/site-packages/dnf/cli/commands/__init__.py", line 849, in configure if not os.access(self.base.history.path, os.R_OK): File "/usr/lib/python3.6/site-packages/dnf/db/history.py", line 308, in path return self.swdb.getPath() File "/usr/lib/python3.6/site-packages/dnf/db/history.py", line 290, in swdb self._swdb = libdnf.transaction.Swdb(self.dbpath) File "/usr/lib64/python3.6/site-packages/libdnf/transaction.py", line 713, in __init__ this = _transaction.new_Swdb(*args) RuntimeError: C++ std::exception: Step: UNIQUE constraint failed: trans_with.trans_id, trans_with.item_id in INSERT INTO trans_with ( trans_id, item_id ) VALUES (3777, 20073) With this version of dnf -- # rpm -q dnf dnf-3.0.1-1.fc29.noarch -- updates are not possible. Dnf can not parse the configuration files in /etc/yum.conf.d any more. # dnf update Förrådet EGI-trustanchors har ingen spegel eller bas-url satt. Förrådet rawhide har ingen spegel eller bas-url satt. Förrådet rawhide-debuginfo har ingen spegel eller bas-url satt. Förrådet rawhide-source har ingen spegel eller bas-url satt. Fel: Det finns inga aktiva förråd. It says "no mirror or base-url set". I tried to set LANG to C to get the error message in English for the purpose of this comment, but then dnf suddenly can parse the configuration. However, now it segfaults instead. # LANG=C.UTF-8 dnf update Last metadata expiration check: 0:43:42 ago on Wed Jul 4 09:08:21 2018. Segmenteringsfel (minnesutskrift skapad) Mattias: those both look like different problems, so can you please file separate bugs for them? A single huge bug with All The Problems Anyone Ever Ran Into With DNF 3 will not be useful for reporters or maintainers, it'll just be a confusing mess, so trying to avoid that happening. Thanks. I'm not *sure* if both #c0 and #c1 have the same cause (they're both basically issues with database values that should be unique not being unique, but not the *same* values), but let's not split them up just yet, unless a DNF maintainer says to do so. (In reply to Adam Williamson from comment #3) > Mattias: those both look like different problems, so can you please file > separate bugs for them? Done, see bug 1598336. Also, "Software" app hangs. I think this the same root cause and is not a surprise, but should be mentioned in case someone else is looking for that symptom. Hi, Since dnf is so screwed up I thought I'd try yum. I get the feeling that it would have worked except for one of the packages has a problem. I used this command "yum-deprecated upgrade dnf'*'" and got this for my trouble: Error: Invalid version flag: or Apparently one of the packages has a problem. George... This problem is not a package problem, it's a yum-deprecated problem... somewhere in the bowels of yum-deprecated. Can "we" get someone to fix this problem please? Paul "I think this the same root cause and is not a surprise" it's quite unlikely. Please file it separately. Adam, Was your last message meant for me? George... No. That's why it says "Paul" at the start of it. Any idea about a workaround for this? I cannot upgrade now. I have renamed /var/lib/dnf/history and started an upgrade about 10 hours ago. It's still running (>7k upgrades). Dnf created a /var/lib/dnf/history.sqlite. George... Could you attach the /var/lib/dnf/history to the bug, assuming you don't consider any of its likely contents (I'm assuming, all your previous DNF transactions) private? Thanks! Adam, I would like to do this but the file (history-2017-06-27.sqlite) is rather large: 5,570,596,864 bytes or gzip'd (742712270). Is there a site where I can download this file? George... Yikes! I didn't realize it was that big. Perhaps a Google Drive share would work? Adam, RedHat doesn't have a blind ftp server? I'm not familiar with Google Drive. George... Adam, You should have email from me... George... Adam, I think I have a smaller history.sqlite file if you're interested. George... Adam, I'm seeing more of these problems. I think I'm seeing a correlation between multiple instances of dnf running where the failures occur. I'm seeing a message about the "DB being locked". George... Thanks. I did get the file mail, btw, just haven't had time to check with dnf folks if it's of interest to them yet. So, let me understand what you're experiencing here: you are seeing the same crashes again, and each time you have to wipe the history file to make DNF work again? Or what? Created attachment 1472876 [details]
tar gzip'd file containing console output from failure
Adam,
Essentially you are correct.
The database gets locked somehow and the attempt fails.
Here's my latest attempt that has failed although sometimes dnf succeeds.
George...
Adam, In the above case, dnf was running already. Argh!!! George... Adam, More info... Note that dnf was already running (see the end of this data): dnf erase environment-modules Traceback (most recent call last): File "/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 123, in cli_run ret = resolving(cli, base) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 146, in resolving base.resolve(cli.demands.allow_erasing) File "/usr/lib/python3.7/site-packages/dnf/base.py", line 791, in resolve self.history) File "/usr/lib64/python3.7/site-packages/hawkey/__init__.py", line 220, in push_userinstalled user_installed = query.userinstalled(history.swdb) File "/usr/lib/python3.7/site-packages/dnf/db/history.py", line 290, in swdb self._swdb = libdnf.transaction.Swdb(self.dbpath) File "/usr/lib64/python3.7/site-packages/libdnf/transaction.py", line 713, in __init__ this = _transaction.new_Swdb(*args) RuntimeError: C++ std::exception: Exec failed: database is locked Warning: ssh still initialized; probably ssh_init() was called more than once (init count: 1) fc27-bash 4.4 /export/home/cfake# psg dnf new n=/usr/bin/ps -efadlc | /usr/bin/grep -v grep | /usr/bin/egrep -i \(WCHAN\|dnf\)<... ..... F S UID PID PPID CLS PRI ADDR SZ WCHAN STIME TTY TIME CMD 0 S root 14850 1 TS 19 - 184800 x64_sy 08:47 ? 00:00:01 /usr/bin/python3 /bin/dnfdragora-updater 4 R root 91694 17467 TS 19 - 187422 - 09:56 pts/16 00:00:11 /usr/bin/python3 /bin/dnf -y --best upgrade --allowerasing p11-kit-devel.x86_64 p11-kit-trust.x86_64 p11-kit.i686 p11-kit.x86_64 This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'. *** Bug 1598590 has been marked as a duplicate of this bug. *** Note the bug I just marked as dupe has a history file that the reporter says reliably triggers the bug: https://bugzilla.redhat.com/attachment.cgi?id=1458556 *** Bug 1624682 has been marked as a duplicate of this bug. *** Discussed during the 2018-09-17 blocker review meeting: [1] The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criteria: "The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type" We will ask the dnf team for more investigation of this. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-09-17/f29-blocker-review.2018-09-17-16.02.txt I believe I have a fix. I'll write several unit tests and post a patch tomorrow. It should be part of the next DNF build. Daniel, It does seem that parts of dnf are not expecting a situation where there are two and I presume more dnf processes running and produce a stack dump. I was just running a "dnf reinstall libreoffice'*'" and a "dnf upgrade liborcus" and got a stack dump. If a dnf resource needs to be serialized then dnf should wait on it's release, if not, dnf should run without taking a dump. George... George: I think that may be a different problem from this. If you don't see the same traceback, it is likely not the same bug. If you can reproduce the bug in #c25 reliably, it would be good if you could report that separately, as it should definitely be dealt with. Thanks. George: I think https://bugzilla.redhat.com/show_bug.cgi?id=1631533 should be the bug for any time you hit the "Exec failed: database is locked" traceback. That one is definitely not the same thing as the "UNIQUE constraint failed" crash. I believe https://github.com/rpm-software-management/libdnf/commit/d41f9a2f9879712cef8c5316d091d2e99fb1347a may be the intended fix for this, is that correct, dmach? It is in libdnf 0.20.0, which was recently tagged. *** Bug 1634305 has been marked as a duplicate of this bug. *** I can confirm that with libdnf 0.20.0 the traceback is gone. Let's call this POST, then, as I'm still waiting to hear from dmach what he wants to do about the DNF 3.6 / libdnf 0.20 update for F29. anaconda-29.24.3-2.fc29 dnf-3.6.1-1.fc29 dnf-plugins-core-3.0.4-1.fc29 dnf-plugins-extras-3.0.2-1.fc29 libdnf-0.20.0-1.fc29 lorax-29.12-3.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-abc8825d92 anaconda-29.24.3-2.fc29 dnf-3.6.1-1.fc29 dnf-plugins-core-3.0.4-1.fc29 dnf-plugins-extras-3.0.2-1.fc29 libdnf-0.20.0-1.fc29 lorax-29.12-3.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-abc8825d92 anaconda-29.24.3-2.fc29, dnf-3.6.1-1.fc29, dnf-plugins-core-3.0.4-1.fc29, dnf-plugins-extras-3.0.2-1.fc29, libdnf-0.20.0-1.fc29, lorax-29.12-3.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-abc8825d92 anaconda-29.24.3-2.fc29, dnf-3.6.1-1.fc29, dnf-plugins-core-3.0.4-1.fc29, dnf-plugins-extras-3.0.2-1.fc29, libdnf-0.20.0-1.fc29, lorax-29.12-3.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. |
Created attachment 1455552 [details] gzip'd execution log of the beginning of this problem Description of problem: after attempting to upgrade this system with this command "dnf -y --best upgrade --allowerasing dnf-data.noarch dnf-plugins-core.noarch dnf.noarch", dnf became totally unusable. See enclosed log below. Version-Release number of selected component (if applicable): dnf-3.0.1-1.fc29.noarch How reproducible: always Steps to Reproduce: 1.see above 2. 3. Actual results: TOTAL catastrophe Expected results: Successful and clean system upgrade. Additional info: dnf -y --best upgrade --allowerasing vala.x86_64 Fedora - Rawhide - Developmental packages for the next Fedora release 21 kB/s | 16 kB 00:00 Last metadata expiration check: 0:00:00 ago on Fri 29 Jun 2018 11:44:56 AM PDT. Traceback (most recent call last): File "/bin/dnf", line 58, in <module> main.user_main(sys.argv[1:], exit_code=True) File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 179, in user_main errcode = main(args) File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 64, in main return _main(base, args, cli_class, option_parser_class) File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 99, in _main return cli_run(cli, base) File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 123, in cli_run ret = resolving(cli, base) File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 146, in resolving base.resolve(cli.demands.allow_erasing) File "/usr/lib/python3.6/site-packages/dnf/base.py", line 817, in resolve self._transaction = self._goal2transaction(goal) File "/usr/lib/python3.6/site-packages/dnf/base.py", line 737, in _goal2transaction ts.add_upgrade(pkg, upgraded[0], obs) File "/usr/lib/python3.6/site-packages/dnf/db/group.py", line 269, in add_upgrade ti_new = self.new(new, libdnf.transaction.TransactionItemAction_UPGRADE) File "/usr/lib/python3.6/site-packages/dnf/db/group.py", line 219, in new rpm_item = self._pkg_to_swdb_rpm_item(pkg) File "/usr/lib/python3.6/site-packages/dnf/db/group.py", line 210, in _pkg_to_swdb_rpm_item rpm_item = self.history.swdb.createRPMItem() File "/usr/lib/python3.6/site-packages/dnf/db/history.py", line 290, in swdb self._swdb = libdnf.transaction.Swdb(self.dbpath) File "/usr/lib64/python3.6/site-packages/libdnf/transaction.py", line 713, in __init__ this = _transaction.new_Swdb(*args) RuntimeError: C++ std::exception: Step: UNIQUE constraint failed: comps_environment_group.environment_id, comps_environment_group.groupid in INSERT INTO comps_environment_group ( environment_id, groupid, installed, group_type ) VALUES (144536, 'libreoffice', 1, 4)