Hide Forgot
Created attachment 1150998 [details] Kickstarter file used to build initial instance Description of problem: When updating a fresh installation using "dnf -y update" in a session that is not attached to an interactive console or pseudo terminal the dnf command fails and returns exit code = 1. There are not obvious error messages produced. The behaviour is different if running the command in an interactive terminal or attached to a pseudo terminal (dnf succeeds in that case). How reproducible: Always Steps to Reproduce: 1. Perform a clean install using the attached kickstarter file and the following ISO: http://download.fedoraproject.org/pub/fedora/linux/releases/23/Server/i386/iso/Fedora-Server-netinst-i386-23.iso 2. Run the following command inside the fresh installation: ssh -T root@localhost dnf -y update Actual results: "dnf -y update" returns with exit code = 1 Expected results: "dnf -y update" should return with exit code = 0 i.e. the following two commands should produce the same results: ssh -T root@localhost dnf -y update ssh -t root@localhost dnf -y update
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.