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: NEW
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: 2019-08-19 09:15 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1717117 None NEW Can't install module libgit2:0.28 due to (uninstalled) conflicts 2019-09-17 07:56:52 UTC
Red Hat Bugzilla 1718646 None CLOSED Modular dependency problems involving libgit2, bat, exa, silver, tokei in F30 [tokei module has not been rebuilt for lib... 2019-09-17 07:56:52 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


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