Trying to do a Rawhide network install currently fails. Shortly after the hub loads, a dialog pops up which has only an 'Exit Installer' button. The contents of this dialog are some dependency errors in default modules. It looks like this: https://openqa.stg.fedoraproject.org/tests/556624#step/_boot_to_anaconda/15 Now, I think what's going on here is that dnf has some sort of 'early warning' mechanism for detecting and informing you of any dependency errors that exist within the set of default module streams. If you run *any kind* of DNF command on Rawhide currently, it shows much the same error, *but then goes ahead and does what you asked it*, like this: [adamw@adam bodhi (develop %)]$ sudo dnf search foo [sudo] password for adamw: Modular dependency problems: Problem 1: module libgit2:0.28:3120190606170438:f636be4b-0.x86_64 conflicts with module(libgit2:0.27) provided by libgit2:0.27:3120190407181414:f636be4b-0.x86_64 - module libgit2:0.27:3120190407181414:f636be4b-0.x86_64 conflicts with module(libgit2:0.28) provided by libgit2:0.28:3120190606170438:f636be4b-0.x86_64 - module silver:rolling:3120190608092801:36e279aa-0.x86_64 requires module(libgit2:0.28), but none of the providers can be installed - conflicting requests Problem 2: module libgit2:0.28:3120190606170438:f636be4b-0.x86_64 conflicts with module(libgit2:0.27) provided by libgit2:0.27:3120190407181414:f636be4b-0.x86_64 - module libgit2:0.27:3120190407181414:f636be4b-0.x86_64 conflicts with module(libgit2:0.28) provided by libgit2:0.28:3120190606170438:f636be4b-0.x86_64 - module exa:latest:3120190608082828:36e279aa-0.x86_64 requires module(libgit2:0.28), but none of the providers can be installed - module tokei:rolling:3120190424130518:c3f9a127-0.x86_64 requires module(libgit2:0.27), but none of the providers can be installed - conflicting requests ============================================ Name & Summary Matched: foo ============================================= bygfoot.x86_64 : Football management game bygfoot.x86_64 : Football management game (etc etc etc) I think anaconda is catching this 'early warning' from DNF, but instead of treating it as a warning, it's assuming it must be a fatal error and going down this path of displaying it and forcing you to quit the installer. This probably isn't warranted, and doesn't match our behaviour for non-modular packages. After all, the installer doesn't check whether there are absolutely any dependency issues between non-modular packages and refuse to continue if there are. It only bails if there are issues *in the actual package set you eventually decide to install*. The 'tokei' module, AFAICT, only includes one package, 'tokei'. It is not in comps, and nothing else requires it. So I'm *pretty* sure it shouldn't actually be winding up in the install transaction here.
note, there really are issues with the 'exa' and 'silver' modules here too it seems: see https://bugzilla.redhat.com/show_bug.cgi?id=1717117 and https://pagure.io/fesco/issue/2146 . I still get the feeling anaconda is failing before deciding if any of the packages it would actually install are affected by the issue, though.
(In reply to Adam Williamson from comment #1) > note, there really are issues with the 'exa' and 'silver' modules here too > it seems: see https://bugzilla.redhat.com/show_bug.cgi?id=1717117 and > https://pagure.io/fesco/issue/2146 . I still get the feeling anaconda is > failing before deciding if any of the packages it would actually install are > affected by the issue, though. As far as I understand the issue with libgit2 is twofold: 1) trying to install one of the affected modules will, of course, result in a big boom 2) but DNF *just reading* the conflicting metadata will also cause a crash originating from DNF as the metadata is simply invalid and DNF decides to rather crash than to do something bad as a result of this Why issue nr. 2 happens only during the installation ? I kinda remember some policy change to run DNF in strict mode during the installation, which is likely causing it to bail on the error. I've actually seen the same error message on a Rawhide machine when running "dnf module list". But in this case, the error message is just printed, followed by the module listing.
2. is the situation we're dealing with here, yes. I don't know whether dnf is actually *crashing*. What I know is that anaconda pops up that dialog. If anaconda only pops up that dialog when dnf crashes, then yes, I guess dnf crashed. :)
Did anyone do anything intentionally to fix this? Because it doesn't seem to be happening any more, but the bug is still NEW...
I would ask DNF developers for this question. It's correct that we did a new release recently but I'm not aware of any change which could be a fix for this.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
Hmm, this seems to be showing up again in the recent Rawhide compose: https://openqa.fedoraproject.org/tests/432081#step/_boot_to_anaconda/13
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.
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
This should be fixed in Rawhide by https://github.com/rhinstaller/anaconda/pull/3298.