| Summary: | DNF produces different results in interactive versus non-interactive terminals. | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Artur Szostak <aszostak> | ||||||||
| Component: | dnf | Assignee: | rpm-software-management | ||||||||
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | low | ||||||||||
| Version: | 23 | CC: | aszostak, jmracek, jsilhan, mluscon, packaging-team-maint, pnemade, vmukhame | ||||||||
| Target Milestone: | --- | Keywords: | Triaged | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | i686 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2016-12-06 14:56:22 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: | |||||||||
| Attachments: |
|
||||||||||
|
Description
Artur Szostak
2016-04-26 15:37:51 UTC
Please attach logs after update from non-interactive session. Those are located in /var/log/dnf.* Created attachment 1152970 [details]
Logs of DNF non-interactive session
(In reply to artur from comment #2) > Created attachment 1152970 [details] > Logs of DNF non-interactive session hm, I don't see errors there... Can you point me where is a problem? Created attachment 1153026 [details]
Logs for a successful run through pty to simulate interactive mode.
logs_success.tar.gz contains logs where an update with DNF completed successfully when running through 'expect' to connect DNF to a pseudotty to simulate interactive mode. One can ignore the last DNF transaction which simply removes 'expect'.
The problem is that DNF exists with code = 1. It seems like it dies just before verification without actually producing an error message. Compare the logs in attachment 1153026 [details], where DNF succeeded (returned error code = 0), to the logs in attachment 1152970 [details] where DNF failed. We'll take a look. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. 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 '23'. 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 23 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. We made a lot of changes in dnf-2.0. It is now available in rawhide or from our testing repository for fc24+ ('dnf copr enable rpmsoftwaremanagement/dnf-nightly'). Please can you test it and if your problem still appears, reopen the bug report.
I have checked this for Fedora 25 and this problem no longer occurs. |