As discussed in https://bugzilla.redhat.com/show_bug.cgi?id=1656509 , it seems to be generally the case that any upgrade which involves modular content will not work correctly unless the 'module_platform_id' option is explicitly set to the correct value for the target release. e.g. when upgrading to Fedora 30, this is needed: sudo dnf system-upgrade download --refresh --releasever=30 --setopt='module_platform_id=platform:f30' It was generally agreed by the Modularity WG and others (including QA) that this is not acceptable: upgrades should work as they did before modularity, i.e. only --releasever should need to be passed. I'm setting the version here to 29, but in fact I suspect we should put the fix in all active branches (including F28) so upgrades from F28 to F30, for e.g., work? Proposing as an F30 Beta blocker, but I suspect we may decide to make this a Beta FE and a Final blocker (on the basis that it might be OK to ask people to do the --setopt for a Beta, but not for a final release).
Maybe it's time for specifying an upgrade path between module streams. platform:f29 is unsupported in Fedora 30. Thus Fedora 30 modular repository should specify that platform:f30 replaces platform:f29. With this metadata available DNF could switch the stream automatically on system upgrade. Something like Obsoletes in RPM. This feature should be available for all modules. Not only platform. Because other modules' streams are also subjects of becoming end-of-life.
Discussed during the 2019-03-18 blocker review meeting: [1] The decision to classify this bug as a "RejectedBlocker (Beta)", a "RejectedFreezeException (Beta)", and an "AcceptedBlocker (Final)" was made as we agreed that the workaround here (using --setopt) is OK for Beta, but not acceptable for Final, so this is accepted as a Final blocker. We do not grant a Beta FE as we don't think fixing this late for Beta is worth the risk of taking more DNF change. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-03-18/f30-blocker-review.2019-03-18-16.03.txt
I propose to drop Platform ID Platform ID is in many aspect redundant to releasever or to dependencies generated during rpm builds Pros: The simplest implementation Platform incompatibility handled by package requires and releasever (RHEL-7) No errors Negs: Impossible to play with names of the platform Increase importance of proper delivery channels (identical to RHEL7/Fedora27-)
To resolve the bug we need a decision from Modularity team about a future of the Platform ID. So far the subject is under discussion with Modularity team without a final decision. Please could you provide additional information?
Kind of same thing with Fedora XFCE (+ updates + updates testing) ---------------------- sudo dnf system-upgrade download --refresh --releasever=30 Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y Fedora 30 openh264 (From Cisco) - x86_64 5.0 kB/s | 3.0 kB 00:00 Fedora Modular 30 - x86_64 20 kB/s | 19 kB 00:00 Fedora Modular 30 - x86_64 - Updates 70 kB/s | 3.0 kB 00:00 Fedora Modular 30 - x86_64 - Test Updates 49 kB/s | 2.4 kB 00:00 Fedora 30 - x86_64 - Test Updates 104 kB/s | 4.7 kB 00:00 Fedora 30 - x86_64 - Updates 25 kB/s | 25 kB 00:00 Fedora 30 - x86_64 15 kB/s | 14 kB 00:00 google-chrome 16 kB/s | 1.3 kB 00:00 MongoDB Repository 6.7 kB/s | 2.5 kB 00:00 Scooter Software 8.9 kB/s | 2.9 kB 00:00 skype (stable) 14 kB/s | 2.9 kB 00:00 Sublime Text - x86_64 - Dev 6.2 kB/s | 2.9 kB 00:00 Visual Studio Code 8.4 kB/s | 2.9 kB 00:00 Modular dependency problems: Problem 1: conflicting requests - nothing provides module(platform:f30) needed by module newsboat:latest:3020190307162417:a5b0195c-0.x86_64 Problem 2: conflicting requests - nothing provides module(platform:f30) needed by module newsboat:latest:3020190325084033:a5b0195c-0.x86_64 Problem 3: conflicting requests - nothing provides module(platform:f30) needed by module avocado:stable:3020190304180315:a5b0195c-0.x86_64 Problem 4: conflicting requests - nothing provides module(platform:f30) needed by module bat:latest:3020190307100850:e50d0d19-0.x86_64 Problem 5: conflicting requests - nothing provides module(platform:f30) needed by module dwm:6.1:3020190304180429:a5b0195c-0.x86_64 Problem 6: conflicting requests - nothing provides module(platform:f30) needed by module exa:latest:3020190306064823:e50d0d19-0.x86_64 Problem 7: conflicting requests - nothing provides module(platform:f30) needed by module ffsend:latest:3020190317224628:a5b0195c-0.x86_64 Problem 8: conflicting requests - nothing provides module(platform:f30) needed by module fish:3:3020190301191132:602da195-0.x86_64 Problem 9: conflicting requests - nothing provides module(platform:f30) needed by module gimp:2.10:3020190304180601:a5b0195c-0.x86_64 Problem 10: conflicting requests - nothing provides module(platform:f30) needed by module heatseeker:latest:3020190309110310:a5b0195c-0.x86_64 Problem 11: conflicting requests - nothing provides module(platform:f30) needed by module hyperfine:latest:3020190318171218:a5b0195c-0.x86_64 Problem 12: conflicting requests - nothing provides module(platform:f30) needed by module libgit2:0.27:3020190304180745:a5b0195c-0.x86_64 Problem 13: conflicting requests - nothing provides module(platform:f30) needed by module meson:latest:3020190310183600:36245242-0.x86_64 Problem 14: conflicting requests - nothing provides module(platform:f30) needed by module minetest:5:3020190308194723:a5b0195c-0.x86_64 Problem 15: conflicting requests - nothing provides module(platform:f30) needed by module ninja:latest:3020190304180949:a5b0195c-0.x86_64 Problem 16: conflicting requests - nothing provides module(platform:f30) needed by module ripgrep:latest:3020190306064851:a5b0195c-0.x86_64 Problem 17: conflicting requests - nothing provides module(platform:f30) needed by module rpick:latest:3020190313083345:a5b0195c-0.x86_64 Problem 18: conflicting requests - nothing provides module(platform:f30) needed by module standard-test-roles:3.0:3020190319161255:a5b0195c-0.x86_64 Problem 19: conflicting requests - nothing provides module(platform:f30) needed by module stratis:1:3020190306064421:a5b0195c-0.x86_64 Error: Problem: problem with installed package tortoisehg-4.6.1-1.fc29.noarch - package tortoisehg-4.6.1-2.fc30.noarch requires mercurial < 4.7, but none of the providers can be installed - tortoisehg-4.6.1-1.fc29.noarch does not belong to a distupgrade repository - mercurial-4.5.3-1.fc29.x86_64 does not belong to a distupgrade repository (try to add '--skip-broken' to skip uninstallable packages) ---------------- Adding --setopt='module_platform_id=platform:f30 seemingly worked. I had to un-install "mercurial" and "tortoisehg" (don't know what the deal is, they are still present in F30) - will add back once I'm in F30.
According to discussions with Modularity team we will resolve the problem using additional detection of a platform ID from package provides (metadata). Because the change will have impact not only on DNF but also on other components (PackageKit, microdnf, satellite), in Fedora 29, 30, and 31 it requires a system wide change. I believe that without an approval we cannot release the change.
The DNF team and Modularity teams agreed on the approach to deal with this. We will add a new virtual Provides to the system-release package. This will be `Provides: base-module(platform:f29)`. DNF will then follow this ordering for determining the relative priority of the various ways the module can be provided: 1) Specified at commandline with --setopt Always prefer the user's explicit override 2) The virtual Provides from the latest `system-release` package in the enabled repos. This will deal with upgrades and enabling the Rawhide repo from a stable release. The net result here will be that upgrading any module stream to one that requires a newer platform will update the system-release package to that new platform. 3) /etc/os-release In the event that no enabled repos provide the virtual Provides, fall back to reading it from /etc/os-release 4) /usr/lib/os-release In the event that no enabled repos provide the virtual Provides and /etc/os-release doesn't exist (e.g. OSTree systems), fall back to reading it from /usr/lib/os-release Agreed to by Stephen Gallagher, Petr Sabata, Adam Samalik, Jaroslav Mracek and Stephen Tweedie
This sounds good to me, is this for f30+ ? or also pushed to f29? It would be super nice if this was done before freeze next week...
(In reply to Kevin Fenzi from comment #8) > This sounds good to me, is this for f30+ ? or also pushed to f29? > > It would be super nice if this was done before freeze next week... The fedora-release side of things is done and available for F29+. The DNF portion will need to be pushed to F29 as well or upgrades from F29->F30 will still have this bug (which we accepted as a blocker). I'm not going to speak for jmracek as to whether they can have it done in the next couple days. The remaining question from Jaroslav is that he'd like to have someone (FESCo) make the decision that fixing this bug is worth the degree of change it's going to require. In theory, we *could* decide that the --setopt workaround is safer for F30, but I personally think that the resulting upgrade problems will cause more trouble for Fedora. I'll open a FESCo ticket asking for an emergency vote, just to be sure.
fedora-release-29-10 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-425159a57e
fedora-release-30-0.26 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-78e132ecd0
Adjusting status back to NEW. The fedora-release change is necessary but not sufficient to fix this. FESCo voted quickly in https://pagure.io/fesco/issue/2118 to approve the proposed solution, so the DNF team is encouraged to go ahead as soon as possible.
fedora-release-30-0.26 has been pushed to the Fedora 30 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-2019-78e132ecd0
fedora-release-29-10 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-2019-425159a57e
fedora-release-30-0.26 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
I create a patch that implements the new workflows for a detection of the Platform ID (https://github.com/rpm-software-management/libdnf/pull/712).
Will gnome-software need to do anything here, or will it be fine once libdnf is changed?
fedora-release-29-10 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
So, what's the status here? Should this be working now, or is more work needed? Is that libdnf patch needed, for instance? In F30, or in the 'source' releases? Or both? Thanks!
So apparently DNF team have told us that what's needed to complete the fix for this is libdnf updates for F28 and F29. libdnf update on F30 side is *not* needed for upgrades *to* F30, it seems. Assuming that is accurate, I'm changing this to a PreviousReleaseBlocker, which is the appropriate 'special' blocker type for this kind of thing.
Despite the workaround, eclipse + ant + maven seems to still interfere with system-upgrade # this does not work dnf system-upgrade download --refresh --releasever=30 --setopt=module_platform_id=platform:f30 # need to dnf module disable ant dnf module disable maven # then proceed as recommended I didn't explicitly set the ant/maven modules for Cclipse, so this must have happened automagically by Eclipse in F29.
The eclipse + maven + ant problem may be a separate issue: https://bugzilla.redhat.com/show_bug.cgi?id=1692089
dnf-4.2.5-1.fc29 libdnf-0.31.0-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-2612a121ba
(In reply to Fedora Update System from comment #23) > dnf-4.2.5-1.fc29 libdnf-0.31.0-2.fc29 has been submitted as an update to > Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-2612a121ba dnf-4.2.5-1.fc29 and libdnf-0.31.0-2.fc29 fixes the issue.
Can folks please test and confirm if this is fixed with the dnf/libdnf update for F29, and if so, give it karma? We are required to push the fix for this stable before F30 releases on Tuesday. Thanks!
(In reply to František Zatloukal from comment #24) > (In reply to Fedora Update System from comment #23) > > dnf-4.2.5-1.fc29 libdnf-0.31.0-2.fc29 has been submitted as an update to > > Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-2612a121ba > > dnf-4.2.5-1.fc29 and libdnf-0.31.0-2.fc29 fixes the issue. I have two Fedora 28 servers that need to go to 30. Does this patch need to be added to 28 as well?
dnf-4.2.5-1.fc29, libdnf-0.31.0-2.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-2019-2612a121ba
(In reply to ToddAndMargo from comment #26 > I have two Fedora 28 servers that need to go to 30. Does this patch need > to be added to 28 as well? No, I don't think so. I just did some quick tests with a f28 vm and it doesn't have this issue.
In theory F28 could possibly be affected, as it was the first release with modules. But in practice, it seems F28 to F30 upgrades work fine without the extra arg, and fixing this in F28's libdnf is apparently quite hard, so we're going to leave it unless we find out about a scenario where it really causes problems. You can just go ahead and try your F28 to F30 upgrade, if no dep issues are reported, it'll be fine.
dnf-4.2.5-1.fc29, libdnf-0.31.0-2.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
The fix for this change was backwards incompatible: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/thread/433LMDYOSO76ZOV44FIT2IH6D25YVTJP/ FESCo was asked to approve the proposed change in this bugzilla ticket, but the ticket does not mention that there were backwards incompatible changes in the proposed fix. Please be sure to inform FESCo of significant details such as backwards incompatibilities in the future.
Dear folks: I'm trying to upgrade from FC29 to FC30 and run into this: sudo dnf system-upgrade download --releasever=30 Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y Adobe Systems Incorporated 19 kB/s | 2.9 kB 00:00 Fedora Modular 30 - x86_64 18 kB/s | 19 kB 00:01 Fedora Modular 30 - x86_64 - Updates 36 kB/s | 22 kB 00:00 Fedora 30 - x86_64 - Updates 86 kB/s | 23 kB 00:00 Fedora 30 - x86_64 - Updates 30 kB/s | 194 kB 00:06 Fedora 30 - x86_64 26 kB/s | 19 kB 00:00 google-chrome 17 kB/s | 1.3 kB 00:00 RPM Fusion for Fedora 30 - Free tainted 36 kB/s | 9.4 kB 00:00 RPM Fusion for Fedora 30 - Free - Updates 43 kB/s | 10 kB 00:00 RPM Fusion for Fedora 30 - Free - Updates 190 kB/s | 98 kB 00:00 RPM Fusion for Fedora 30 - Free 1.8 kB/s | 10 kB 00:05 RPM Fusion for Fedora 30 - Nonfree - Updates 1.9 kB/s | 10 kB 00:05 RPM Fusion for Fedora 30 - Nonfree - Updates 727 B/s | 7.6 kB 00:10 RPM Fusion for Fedora 30 - Nonfree 18 kB/s | 10 kB 00:00 Fedora 30 - x86_64 - VirtualBox 5.2 kB/s | 6.9 kB 00:01 Failed to synchronize cache for repo 'virtualbox' Ignoring repositories: virtualbox Error: Problem 1: package python2-hawkey-0.31.0-2.fc29.x86_64 requires libdnf(x86-64) = 0.31.0-2.fc29, but none of the providers can be installed - libdnf-0.31.0-2.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package python2-hawkey-0.31.0-2.fc29.x86_64 Problem 2: package python3-hawkey-0.28.1-1.fc30.x86_64 requires libdnf(x86-64) = 0.28.1-1.fc30, but none of the providers can be installed - cannot install both libdnf-0.28.1-1.fc30.x86_64 and libdnf-0.31.0-2.fc29.x86_64 - problem with installed package python3-hawkey-0.31.0-2.fc29.x86_64 - package python2-libdnf-0.31.0-2.fc29.x86_64 requires libdnf(x86-64) = 0.31.0-2.fc29, but none of the providers can be installed - python3-hawkey-0.31.0-2.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package python2-libdnf-0.31.0-2.fc29.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages) dnf --version 4.2.5 Installed: dnf-0:4.2.5-1.fc29.noarch at Mon 29 Apr 2019 06:57:51 AM GMT Built : Fedora Project at Thu 25 Apr 2019 04:38:17 PM GMT Installed: rpm-0:4.14.2.1-2.fc29.x86_64 at Sun 03 Feb 2019 12:10:34 PM GMT Built : Fedora Project at Mon 29 Oct 2018 01:10:13 PM GMT I think the problem I am facing is related to this thread. The FC29 I am trying to upgrade is fully updated according to the recommended procedure. More info: rpm -qi python2-hawkey-0.31.0-2.fc29.x86_64 Name : python2-hawkey Version : 0.31.0 Release : 2.fc29 Architecture: x86_64 Install Date: Mon 29 Apr 2019 08:57:52 AM CEST Group : Unspecified Size : 264888 License : LGPLv2+ Signature : RSA/SHA256, Thu 25 Apr 2019 06:45:16 PM CEST, Key ID a20aa56b429476b4 Source RPM : libdnf-0.31.0-2.fc29.src.rpm Build Date : Thu 25 Apr 2019 05:46:06 PM CEST Build Host : buildhw-07.phx2.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : https://github.com/rpm-software-management/libdnf Bug URL : https://bugz.fedoraproject.org/libdnf Summary : Python 2 bindings for the hawkey library Description : Python 2 bindings for the hawkey library. rpm -qi python3-hawkey-0.31.0-2.fc29.x86_64 Name : python3-hawkey Version : 0.31.0 Release : 2.fc29 Architecture: x86_64 Install Date: Mon 29 Apr 2019 08:57:47 AM CEST Group : Unspecified Size : 262747 License : LGPLv2+ Signature : RSA/SHA256, Thu 25 Apr 2019 06:45:09 PM CEST, Key ID a20aa56b429476b4 Source RPM : libdnf-0.31.0-2.fc29.src.rpm Build Date : Thu 25 Apr 2019 05:46:06 PM CEST Build Host : buildhw-07.phx2.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : https://github.com/rpm-software-management/libdnf Bug URL : https://bugz.fedoraproject.org/libdnf Summary : Python 3 bindings for the hawkey library Description : Python 3 bindings for the hawkey library. rpm -qi python2-libdnf-0.31.0-2.fc29.x86_64 Name : python2-libdnf Version : 0.31.0 Release : 2.fc29 Architecture: x86_64 Install Date: Mon 29 Apr 2019 08:57:26 AM CEST Group : Unspecified Size : 3519081 License : LGPLv2+ Signature : RSA/SHA256, Thu 25 Apr 2019 06:44:55 PM CEST, Key ID a20aa56b429476b4 Source RPM : libdnf-0.31.0-2.fc29.src.rpm Build Date : Thu 25 Apr 2019 05:46:06 PM CEST Build Host : buildhw-07.phx2.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : https://github.com/rpm-software-management/libdnf Bug URL : https://bugz.fedoraproject.org/libdnf Summary : Python 2 bindings for the libdnf library. Description : Python 2 bindings for the libdnf library.
Related to above, I also tried this: sudo dnf system-upgrade download --refresh --releasever=30 --setopt=module_platform_id=platform:f30 .. which produced the exact same result.
(In reply to az.simple.az.that from comment #32) > I think the problem I am facing is related to this thread. It is not. You should be able to upgrade with: sudo dnf system-upgrade download --refresh --releasever=30 --allowerasing
Thanks, that helped the upgrade getting started.