Bug 1421244
| Summary: | DNF keeps packages with broken scriptlets installed, although it claims they were removed. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Vít Ondruch <vondruch> |
| Component: | dnf | Assignee: | Jaroslav Mracek <jmracek> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | high | ||
| Version: | 26 | CC: | ignatenko, jmracek, kardos.lubos, mjw, packaging-team-maint, pmatilai, rpm-software-management, vmukhame |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | dnf-2.4.0-1.fc26 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-05-05 13:34:55 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: | |||
|
Description
Vít Ondruch
2017-02-10 17:35:46 UTC
we will investigate why DNF does not report the package was not removed correctly. The DNF return code should be checked as well. This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'. I have to ask rpm team, how to solve a problem. Simply rpm refuse to remove the file and even it do not report removal as fail. It can be reproduce: 1. dnf install https://kojipkgs.fedoraproject.org//packages/vagrant-adbinfo/0.0.9/4.fc24/noarch/vagrant-adbinfo-doc-0.0.9-4.fc24.noarch.rpm 2. rpm -e --nodeps $(dnf repoquery --installed -q rubygem*) 3. rpm -e vagrant-adbinfo In this case rpm refuse to remove package with return code 255. We really cannot do much if rpm cannot handle it. %preun scriptlets have the power to stop a package from being removed, this is expected behavior. Yes, typos fixed in the next release and all. "rpm -e --noscripts vagrant-adbinfo" to get around it. IIRC yum had some switch to do the same. As for the verifying step showing all okay I dunno what yum (and now dnf due to the inheritance) do there, it always seemed like a strange addition to me. Instead of filling the screen with redundant goo that's not even accurate (as witnessed here), it could ask rpm whether a transaction element failed (te.Failed()) and only report the failed ones if there were any, or something like that. Thanks Panu for info.
But to fix problem we need an assistance from RPM.
In this case we run:
errors = rpm.transaction.TransactionSet.run()
But errors is 0.
then we tests (code dnf.base lines 796-833)
# ts.run() exit codes are, hmm, "creative": None means all ok, empty
# list means some errors happened in the transaction and non-empty
# list that there were errors preventing the ts from starting...
if errors is None:
pass
elif len(errors) == 0:
# this is a particularly tricky case happening also when rpm failed
# to obtain the transaction lock. We can only try to see if a
# particular element failed and if not, decide that is the
# case.
if len([el for el in self._ts if el.Failed()]) > 0:
errstring = _('Warning: scriptlet or other non-fatal errors '
'occurred during transaction.')
logger.debug(errstring)
and el.Failed() == 1 but we recognize it as soft problem. Please can you provide detailed information how we should handle the returns from rpm and their combinations? Thanks a lot for your help.
Well that's more "creativity" in this area. Chasing down the origins of that el.Failed() and its interpretation comes to this:
commit 543a95d8859377530270a7515002d099a87abfd7
Author: Ales Kozumplik <akozumpl>
Date: Tue Apr 17 13:58:42 2012 +0200
better handling of the no-root situtation.
...for which checking te.Failed() seems bizarre. At any rate, te.Failed() returning true certainly signifies a hard error and is what rpm itself uses to track failures within transaction.
Thanks for help. I created a pull request that should solve the problem with marking unremoved packages as removed: https://github.com/rpm-software-management/dnf/pull/780 . To remove packages with broken scriplets it is possible to use "dnf remove --setopt=tsflags=noscripts <package>" . dnf-plugins-core-2.0.0-1.fc26 libdnf-0.8.2-1.fc26 dnf-2.4.0-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4e95959f0d dnf-2.4.0-1.fc26 dnf-plugins-core-2.0.0-1.fc26 dnf-plugins-extras-2.0.0-1.fc26 libdnf-0.8.2-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4e95959f0d dnf-2.4.0-1.fc26, dnf-plugins-core-2.0.0-1.fc26, dnf-plugins-extras-2.0.0-1.fc26, libdnf-0.8.2-1.fc26 has been pushed to the Fedora 26 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-2017-4e95959f0d dnf-2.4.0-1.fc26, dnf-plugins-core-2.0.0-1.fc26, dnf-plugins-extras-2.0.0-1.fc26, libdnf-0.8.2-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. |