Bug 1688462 - System upgrades involving modular content require explicit --setopt=module_platform_id to work correctly
Summary: System upgrades involving modular content require explicit --setopt=module_pl...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libdnf
Version: 29
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa AcceptedPreviousReleaseBlocker...
Keywords: CommonBugs, Triaged
Depends On:
Blocks: 1699348 F30FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2019-03-13 19:08 UTC by Adam Williamson
Modified: 2019-05-02 13:19 UTC (History)
24 users (show)

(edit)
Clone Of:
: 1699348 (view as bug list)
(edit)
Last Closed: 2019-04-29 02:15:05 UTC


Attachments (Terms of Use)

Description Adam Williamson 2019-03-13 19:08:04 UTC
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).

Comment 1 Petr Pisar 2019-03-14 15:43:34 UTC
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.

Comment 2 Geoffrey Marr 2019-03-18 18:27:51 UTC
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

Comment 3 Jaroslav Mracek 2019-04-02 08:05:45 UTC
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-)

Comment 4 Jaroslav Mracek 2019-04-03 08:19:17 UTC
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?

Comment 5 Kostya Vasilyev 2019-04-03 19:07:09 UTC
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.

Comment 6 Jaroslav Mracek 2019-04-05 07:35:55 UTC
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.

Comment 7 Stephen Gallagher 2019-04-10 13:45:41 UTC
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

Comment 8 Kevin Fenzi 2019-04-10 17:54:47 UTC
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...

Comment 9 Stephen Gallagher 2019-04-10 19:58:19 UTC
(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.

Comment 10 Fedora Update System 2019-04-10 20:12:15 UTC
fedora-release-29-10 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-425159a57e

Comment 11 Fedora Update System 2019-04-10 20:12:18 UTC
fedora-release-30-0.26 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-78e132ecd0

Comment 12 Stephen Gallagher 2019-04-10 22:13:51 UTC
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.

Comment 13 Fedora Update System 2019-04-12 02:47:27 UTC
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

Comment 14 Fedora Update System 2019-04-12 03:56:11 UTC
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

Comment 15 Fedora Update System 2019-04-13 00:05:25 UTC
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.

Comment 16 Jaroslav Mracek 2019-04-15 10:07:04 UTC
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).

Comment 17 Adam Williamson 2019-04-15 15:20:58 UTC
Will gnome-software need to do anything here, or will it be fine once libdnf is changed?

Comment 18 Fedora Update System 2019-04-16 04:04:04 UTC
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.

Comment 19 Adam Williamson 2019-04-17 17:00:14 UTC
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!

Comment 20 Adam Williamson 2019-04-23 22:03:25 UTC
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.

Comment 21 space88man 2019-04-24 08:17:41 UTC
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.

Comment 22 Ben Cotton 2019-04-24 12:07:10 UTC
The eclipse + maven + ant problem may be a separate issue: https://bugzilla.redhat.com/show_bug.cgi?id=1692089

Comment 23 Fedora Update System 2019-04-25 16:43:28 UTC
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

Comment 24 František Zatloukal 2019-04-25 17:16:02 UTC
(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.

Comment 25 Adam Williamson 2019-04-26 18:16:28 UTC
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!

Comment 26 ToddAndMargo@zoho.com 2019-04-26 19:47:46 UTC
(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?

Comment 27 Fedora Update System 2019-04-26 22:10:07 UTC
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

Comment 28 Kevin Fenzi 2019-04-26 23:17:50 UTC
(In reply to ToddAndMargo@zoho.com 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.

Comment 29 Adam Williamson 2019-04-27 02:33:53 UTC
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.

Comment 30 Fedora Update System 2019-04-29 02:15:05 UTC
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.

Comment 31 Randy Barlow 2019-04-29 20:13:36 UTC
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.

Comment 32 az.simple.az.that 2019-05-02 09:49:02 UTC
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.

Comment 33 az.simple.az.that 2019-05-02 10:01:01 UTC
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.

Comment 34 František Zatloukal 2019-05-02 10:29:30 UTC
(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

Comment 35 az.simple.az.that 2019-05-02 13:19:08 UTC
Thanks, that helped the upgrade getting started.


Note You need to log in before you can comment on or make changes to this bug.