Bug 1719976 - Dies on issues in default module streams even if they will not affect install
Summary: Dies on issues in default module streams even if they will not affect install
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 31
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-12 21:05 UTC by Adam Williamson
Modified: 2020-11-24 15:20 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-24 15:20:13 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1717117 high CLOSED Can't install module libgit2:0.28 due to (uninstalled) conflicts 2020-11-24 19:20:45 UTC
Red Hat Bugzilla 1718646 unspecified CLOSED Modular dependency problems involving libgit2, bat, exa, silver, tokei in F30 [tokei module has not been rebuilt for lib... 2020-10-14 00:28:05 UTC

Internal Links: 1718646

Description Adam Williamson 2019-06-12 21:05:10 UTC
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.

Comment 1 Adam Williamson 2019-06-12 21:11:33 UTC
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.

Comment 2 Martin Kolman 2019-06-19 16:16:41 UTC
(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.

Comment 3 Adam Williamson 2019-06-19 16:32:57 UTC
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. :)

Comment 4 Adam Williamson 2019-07-15 16:23:35 UTC
Did anyone do anything intentionally to fix this? Because it doesn't seem to be happening any more, but the bug is still NEW...

Comment 5 Jiri Konecny 2019-07-16 09:19:04 UTC
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.

Comment 6 Ben Cotton 2019-08-13 17:09:47 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 7 Ben Cotton 2019-08-13 19:02:00 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

Comment 8 Adam Williamson 2019-08-16 15:35:00 UTC
Hmm, this seems to be showing up again in the recent Rawhide compose:

https://openqa.fedoraproject.org/tests/432081#step/_boot_to_anaconda/13

Comment 9 Ben Cotton 2020-11-03 16:52:28 UTC
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.

Comment 10 Ben Cotton 2020-11-24 15:20:13 UTC
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.


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