Version is incorrect. Version is 30, but the drop down does not allow that value. Description of problem: dnf upgrade fails to upgrade the system. It downloads the packages with dnf system-upgrade download --refresh --releasever=32 --allowerasing. The system reboots when the dnf system-upgrade reboot is issued. The screen comes up Upgrading System at 0% and never upgrades any thing. After a few seconds on the upgrading screen, the system reboots to the old kernel with nothing in the grub2 prompt about a version 32 kernel on the system. Version-Release number of selected component (if applicable): dnf-4.2.18-1.fc30.noarch python3-dnf-plugin-system-upgrade-4.0.8-4.fc30.noarch How reproducible: always Steps to Reproduce: 1. sudo dnf upgrade --refresh 2. sudo dnf install dnf-plugin-system-upgrade # nothing to do; already installed 3. sudo dnf system-upgrade download --refresh --releasever=32 --allowerasing 4. sudo dnf system-upgrade reboot Actual results: Packages are downloaded but the system is not upgraded. Expected results: System should be upgraded. Additional info: There is a warning issued: Modular dependency problems: Problem 1: conflicting requests - nothing provides module(platform:f30) needed by module gimp:2.10:3020191106095052:a5b0195c-0.x86_64 Problem 2: conflicting requests - nothing provides module(platform:f30) needed by module libgit2:0.27:3020190304180745:a5b0195c-0.x86_64 and at end of package list Resetting modules: ant gimp libgit2 maven scala I tried rebuilding the RPm database. That did not change anything.
Is there progress on this? Should I try to upgrade to 31 and then 32
Can you try with version dnf-plugins-extras-4.0.8-5.fc30 (python3-dnf-plugin-system-upgrade-0:4.0.8-5.fc30.noarch) it has some fixes regarding system upgrades with modules. It is unfortunately available only in updates-testing repo so you have to install it from there.
Installed new package Installed Packages python3-dnf-plugin-system-upgrade.noarch 4.0.8-5.fc30 @updates-testing The system is still not upgraded. Same as first reported, the screen comes up Upgrading System at 0% and never upgrades any thing. After a few seconds on the upgrading screen, the system reboots to the old kernel with nothing in the grub2 prompt about a version 32 kernel on the system.
As a workaround you could try running: $ dnf distro-sync --releasever=32 It is safer to run it from a text console or from inside screen, because it upgrades a running system which may cause the desktop to crash and that would terminate the dnf/rpm transaction.
Also I tried to reproduce it with the same modules and it worked fine. Can you provide logs from the system-upgrades: /var/log/dnf.log and /var/log/dnf.rpm.log so we have more information and to see what is the actual problem?
Created attachment 1698007 [details] dnf log This the the log from yesterday before the system switched the log file.
Created attachment 1698008 [details] dnf rpm log
Unfortunately the logs are incomplete, your latest dnf system-upgrade download .. from 2020-06-17T15:16:04Z is cut in the middle of printing the transaction table for download, the rest could be in the new log file that your system switched to? But I noticed that at the beginning of the log there is an attempt to run most likely some previous dnf system-upgrade download .. from 2020-06-02T17:45:39Z but it also ends unfinished. It is missing a couple of lines at the end. When running the download command do you get an output saying: """ Download complete! Use 'dnf system-upgrade reboot' to start the upgrade. To remove cached metadata and transaction use 'dnf system-upgrade clean' """ ? There are no logs for running dnf system-upgrade reboot.
(In reply to Daniel Mach from comment #4) > As a workaround you could try running: > $ dnf distro-sync --releasever=32 > > It is safer to run it from a text console or from inside screen, > because it upgrades a running system which may cause the desktop > to crash and that would terminate the dnf/rpm transaction. I am reluctant to do this. I have a rather slow (DSL) Internet connection. It takes hours to download.
(In reply to amatej from comment #8) > Unfortunately the logs are incomplete, your latest dnf system-upgrade > download .. from 2020-06-17T15:16:04Z is cut in the middle of printing the > transaction table for download, the rest could be in the new log file that > your system switched to? > > But I noticed that at the beginning of the log there is an attempt to run > most likely some previous dnf system-upgrade download .. from > 2020-06-02T17:45:39Z but it also ends unfinished. It is missing a couple of > lines at the end. When running the download command do you get an output > saying: > """ > Download complete! Use 'dnf system-upgrade reboot' to start the upgrade. > To remove cached metadata and transaction use 'dnf system-upgrade clean' > """ > ? > > There are no logs for running dnf system-upgrade reboot. After the download, I do get Download complete! Use 'dnf system-upgrade reboot' to start the upgrade. To remove cached metadata and transaction use 'dnf system-upgrade clean' I will try again with an update, download, and reboot so that hopefully the log files will be complete in one file.
Created attachment 1698819 [details] dnf log I believe this log shows the issue. There are conflicting requests. raceback (most recent call last): File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 122, in cli_run ret = resolving(cli, base) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 158, in resolvin g base.resolve(cli.demands.allow_erasing) File "/usr/lib/python3.7/site-packages/dnf/base.py", line 777, in resolve raise exc dnf.exceptions.DepsolveError: Problem: both package rpmfusion-free-obsolete-packages-32-3.fc32.noarch and fed ora-obsolete-packages-32-44.noarch obsolete gstreamer-plugins-ugly < 0.10.19-34 - conflicting requests 2020-06-25T17:25:09Z CRITICAL Error: Problem: both package rpmfusion-free-obsolete-packages-32-3.fc32.noarch and fedora-obsolete-packages-32-44.noarch obsolete gstreamer-plugins-ugly < 0.10.19-34 - conflicting requests 2020-06-25T17:25:09Z INFO (try to add '--skip-broken' to skip uninstallable packages) 2020-06-25T17:25:09Z DDEBUG Cleaning up.
Ok I managed to reproduce the problem, here are the steps needed: 1. install f30 2. enable rpmfusion-free repo 3. install gstreamer-plugins-ugly 4. install fedora-obsolete-packages 5. dnf system-upgrade download --refresh --releasever=32 6. dnf system-upgrade reboot -> results in: Problem: both package rpmfusion-free-obsolete-packages-32-3.fc32.noarch and fedora-obsolete-packages-32-44.noarch obsolete gstreamer-plugins-ugly < 0.10.19-34 The issue is probably something with the fedora-obsolete-packages, this is a special package for obsoleting other packages and since f32 it is not installable, that is why its removed in the system-upgrade download transaction. While its true that both rpmfusion-free-obsolete-packages-32-3.fc32.noarch and fedora-obsolete-packages-32-44.noarch obsolete the gstreamer-plugins-ugly there are also newer versions of fedora-obsolete-packages-32 available such as fedora-obsolete-packages-32-51 that no longer obsolete the gstreamer-plugins-ugly, I am not sure why its not using that from the f32 updates repo. I think that is the cause of this bug and we should fix it. Anyway you can work around this by first manually uninstalling the fedora-obsolete-packages (since it would get uninstalled anyway) and the running the system-upgrade.
I removed fedora-obsolete-packages, but the system still does not install. Now it complains that the package is not there. hu 25 Jun 2020 01:02:51 PM EDT. 2020-06-26T17:05:58Z DDEBUG timer: sack setup: 6832 ms 2020-06-26T17:05:58Z DEBUG Completion plugin: Generating completion cache... 2020-06-26T17:06:00Z INFO Unable to match package: fedora-obsolete-packages-30-47.noarch 2020-06-26T17:06:03Z DDEBUG Cleaning up. 2020-06-26T17:06:03Z SUBDEBUG Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 65, in main return _main(base, args, cli_class, option_parser_class) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 98, in _main return cli_run(cli, base) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 114, in cli_run cli.run() File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 1162, in run return self.command.run() File "/usr/lib/python3.7/site-packages/dnf-plugins/system_upgrade.py", line 363, in run self._call_sub("run") File "/usr/lib/python3.7/site-packages/dnf-plugins/system_upgrade.py", line 371, in _call_sub
My mistake. I forgot to run dnf system-upgrade download --refresh --releasever=32 --allowerasing before doing dnf system-upgrade reboot. After 1) dnf remove fedora-obsolete-packages 2) dnf system-upgrade download --refresh --releasever=32 --allowerasing 3) dnf system-upgrade reboot My system upgraded.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. 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 '31'. 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 31 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.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.