Bug 1258164 - fedora-release conflicts with old systemd over presets file
fedora-release conflicts with old systemd over presets file
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: fedora-release (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dennis Gilmore
Fedora Extras Quality Assurance
:
: 1277042 (view as bug list)
Depends On:
Blocks: upgrade-conflicts
  Show dependency treegraph
 
Reported: 2015-08-29 15:23 EDT by Boyd
Modified: 2016-07-19 13:43 EDT (History)
29 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-19 13:43:01 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
debugdata (7.18 MB, application/x-gzip)
2015-09-03 11:55 EDT, Boyd
no flags Details

  None (edit)
Description Boyd 2015-08-29 15:23:33 EDT
Description of problem:

installed the dnf-plugin-system-upgrade. 

But when running dnf system-upgrade download --releasever=23

I get the following error:

Running transaction test
Error: Transaction check error:
  file /usr/lib/systemd/system-preset/90-default.preset from install of fedora-release-23-0.15.noarch conflicts with file from package systemd-219-21.fc22.x86_64



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:

1.  dnf install dnf-plugin-system-upgrade
2.  dnf update
3.  dnf system-upgrade download --releasever=23


Actual results:

Running transaction test
Error: Transaction check error:
  file /usr/lib/systemd/system-preset/90-default.preset from install of fedora-release-23-0.15.noarch conflicts with file from package systemd-219-21.fc22.x86_64


Expected results:

System update to Fedora 23

Additional info:
Comment 1 Jan Synacek 2015-08-31 08:48:15 EDT
I don't see any reason why a file from an F23 package should be checked for a conflict against a file from an F21 package before it's updated.
Comment 2 Honza Silhan 2015-09-01 11:49:09 EDT
How does transaction check work in rpm? Does it consider the updates in transaction instead of to-be-upgrade package files? Is it possible to have this fixed?
Comment 3 Florian Festi 2015-09-01 11:58:56 EDT
RPM actually does check for the to-be installed files. If there is not a massive bug (which is possible) I'd rather guess that system-upgrade does not remove systemd-219-21.fc22.x86_64 for whatever reason. Can you please check that it is actually updated?
Comment 4 Honza Silhan 2015-09-03 05:19:49 EDT
Boyd, can you attach debugdata [1], after execution of `dnf system-upgrade download --releasever=23 --debugsolver`, please?

[1] https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting#dependency-resolution-problem
Comment 5 Boyd 2015-09-03 11:55:04 EDT
Created attachment 1069946 [details]
debugdata

I left out a few repo files, google, adobe etc.  I can send this on if relevent.  Thanks.
Comment 6 Ľuboš Kardoš 2015-09-17 09:06:57 EDT
(In reply to Florian Festi from comment #3)
> RPM actually does check for the to-be installed files. If there is not a
> massive bug (which is possible) I'd rather guess that system-upgrade does
> not remove systemd-219-21.fc22.x86_64 for whatever reason. Can you please
> check that it is actually updated?

You are right, system-upgrade does not remove systemd-219-21.fc22.x86_64. You can see that from attached logs. Moving to dnf-plugin-system-upgrade.
Comment 7 Adam Williamson 2015-09-24 18:01:27 EDT
dnf-plugin-system-upgrade doesn't do anything special in terms of building the transaction, it does the same as plain dnf. this is likely a dnf issue, not a system-upgrade one. I'd guess it's one of the cases where there's a dep issue if it tries to use the systemd fc23 package, so instead of bailing, it just silently tries to keep systemd fc22.

I'd bet that with --best , the reason why systemd can't be updated to the fc23 package will be revealed...
Comment 8 Adam Williamson 2015-09-25 03:34:11 EDT
https://plus.google.com/u/0/104617077706179713070/posts/Sf6hu5CzGMi - similar report from G+. Clearly there's some kind of issue in some package set which is causing systemd to be left out of the update set, but we need someone to post output with --best to know why.
Comment 9 David Vásquez 2015-09-25 15:03:50 EDT
Well! I found my problem (G+); it's related to libudev0 ( a static libudev from a third-party repository) no available yet for Fedora 23.Thanks Adam Williamson for the tip --best
Comment 10 Zbigniew Jędrzejewski-Szmek 2015-10-06 21:33:20 EDT
Please add a conflict to systemd < 220 to fedora-release.

(preset files were removed in systemd-219-14.fc23, in the F23/rawhide branch, but are still present in systemd-219-21.fc22, so it is necessary to pick something higher. 220 should work fine.)
Comment 11 Kevin Fenzi 2015-10-07 22:35:22 EDT
(In reply to Zbigniew Jędrzejewski-Szmek from comment #10)
> Please add a conflict to systemd < 220 to fedora-release.
> 
> (preset files were removed in systemd-219-14.fc23, in the F23/rawhide
> branch, but are still present in systemd-219-21.fc22, so it is necessary to
> pick something higher. 220 should work fine.)

reading this bug I am confused where this came from, is there some additional data that points to this as being the issue? Can the orig reporter try with --best?
Comment 12 Zbigniew Jędrzejewski-Szmek 2015-10-08 10:37:52 EDT
(In reply to Kevin Fenzi from comment #11)
> is there some additional data that points to this as being the issue?
> Can the orig reporter try with --best?

It could be worked around with --best, but that is just a work-around.
It's an issue because dnf only sees the conflict too late, in the
transaction check phase, and not in the depsolving phase.
Comment 13 Kevin Fenzi 2015-10-08 12:03:30 EDT
Sure, rpm sees the file conflict only in the transaction phase, but looking at the depsolve attachments to this bug, the new systemd is never even in the transaction. 

So that makes me doubt that this is really the issue here... something else is holding the old systemd into the transaction it seems like. So, I think adding a conflict here would just cause it to fail out in a different way (something needs old systemd in, conflict requires new systemd). I expect it might just drop the new fedora-release out.
Comment 14 Zbigniew Jędrzejewski-Szmek 2015-10-08 12:14:14 EDT
Yeah, and I think that is a better outcome. It's easier for the user to understand what is going on if they get a smaller set of packages, then if they get a bigger set and then fail with a cryptic error about systemd.
Comment 15 Kevin Fenzi 2015-10-09 14:18:02 EDT
I disagree. It would result in a much more "partially upgraded" system that likely would not even have repos for the new release enabled, resulting in even more pain. Better to error out than leave the users system more broken.
Comment 16 Jan Synacek 2015-11-02 06:50:34 EST
*** Bug 1277042 has been marked as a duplicate of this bug. ***
Comment 17 Jan Vlug 2015-11-02 09:02:53 EST
I have this issue. Is there any info that I can provide to help?
I could run dnf with --best, but I'm a bit reluctant because I don't want to end up with a "partially upgraded" system.
Comment 18 Kevin Fenzi 2015-11-02 11:57:58 EST
(In reply to Jan Vlug from comment #17)
> I have this issue. Is there any info that I can provide to help?
> I could run dnf with --best, but I'm a bit reluctant because I don't want to
> end up with a "partially upgraded" system.

You can run with --best and just say 'n' when it asks you if you want to move forward.

Basically you will want the info from --best to tell what package is preventing a bunch of others from upgrading.
Comment 19 Jan Vlug 2015-11-02 14:01:37 EST
dnf system-upgrade --best download --releasever 23 
Last metadata expiration check performed 0:02:18 ago on Mon Nov  2 19:56:12 2015.
Error: package libudev0-182-2.fc22.x86_64 conflicts with libgudev provided by libgudev-230-2.fc23.x86_64.
package rubygem-celluloid-0.15.2-2.fc22.noarch requires rubygem(timers) < 1.2, but none of the providers can be installed.
package libgudev1-219-25.fc22.x86_64 requires systemd-libs(x86-64) = 219-25.fc22, but none of the providers can be installed.
package popcorntime-0.3.7.2-2.20150429gitddee0b5.fc22.x86_64 requires libudev0, but none of the providers can be installed.
package popcorntime-0.3.7.2-2.20150429gitddee0b5.fc22.x86_64 requires libudev0, but none of the providers can be installed
(try to add '--allowerasing' to command line to replace conflicting packages)
Comment 20 Stephen Gallagher 2015-11-02 14:16:58 EST
(In reply to Jan Vlug from comment #19)
> dnf system-upgrade --best download --releasever 23 
> Last metadata expiration check performed 0:02:18 ago on Mon Nov  2 19:56:12
> 2015.
> Error: package libudev0-182-2.fc22.x86_64 conflicts with libgudev provided
> by libgudev-230-2.fc23.x86_64.
> package rubygem-celluloid-0.15.2-2.fc22.noarch requires rubygem(timers) <
> 1.2, but none of the providers can be installed.
> package libgudev1-219-25.fc22.x86_64 requires systemd-libs(x86-64) =
> 219-25.fc22, but none of the providers can be installed.
> package popcorntime-0.3.7.2-2.20150429gitddee0b5.fc22.x86_64 requires
> libudev0, but none of the providers can be installed.
> package popcorntime-0.3.7.2-2.20150429gitddee0b5.fc22.x86_64 requires
> libudev0, but none of the providers can be installed
> (try to add '--allowerasing' to command line to replace conflicting packages)

So the problem here is that you have the popcorntime package installed which specifically requires a package that is no longer in Fedora. This is essentially a case of a non-Fedora package holding back your upgrade. I'd recommend removing popcorntime and then trying to upgrade.
Comment 21 Jan Vlug 2015-11-02 15:31:04 EST
First I did: dnf erase popcorntime

Then:
dnf system-upgrade --best download --releasever 23 
Last metadata expiration check performed 1:08:30 ago on Mon Nov  2 19:56:12 2015.
Error: package libudev0-182-2.fc22.x86_64 conflicts with libgudev provided by libgudev-230-2.fc23.x86_64.
package libgudev1-219-25.fc22.x86_64 requires systemd-libs(x86-64) = 219-25.fc22, but none of the providers can be installed
(try to add '--allowerasing' to command line to replace conflicting packages)

Next:
dnf erase libudev0-182-2.fc22.x86_64

Again:
dnf system-upgrade --best download --releasever 23 
RPM Fusion for Fedora 23 - Free                                                                                                                                                    1.6 MB/s | 738 kB     00:00    
RPM Fusion for Fedora 23 - Nonfree                                                                                                                                                 2.2 MB/s | 218 kB     00:00    
Last metadata expiration check performed 0:00:00 ago on Mon Nov  2 21:09:25 2015.
Error: package kmod-VirtualBox-4.1.8-200.fc22.x86_64-4.3.32-1.fc22.x86_64 requires kernel-uname-r = 4.1.8-200.fc22.x86_64, but none of the providers can be installed
(try to add '--allowerasing' to command line to replace conflicting packages)

Next:
dnf erase kmod-VirtualBox-4.1.8-200.fc22.x86_64-4.3.32-1.fc22.x86_64

Again:
dnf system-upgrade download --releasever 23

There are no errors any more.
Comment 22 Zbigniew Jędrzejewski-Szmek 2015-11-02 21:01:13 EST
I think libudev0 comes from http://sourceforge.net/projects/postinstaller/, we certainly didn't have any subpackage called libudev0 in F22.
Comment 23 Jan Vlug 2015-11-03 17:32:05 EST
I think I got libudev0 by following these instructions:
https://github.com/pirvudoru/popcorn-app/wiki/Install-Popcorn-Time-on-Fedora
Comment 24 Fedora End Of Life 2016-07-19 13:43:01 EDT
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.