Bug 678201 - F14->F15 upgrade halted due to package conflicts
F14->F15 upgrade halted due to package conflicts
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
15
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs, Reopened
: 680820 680851 (view as bug list)
Depends On:
Blocks: F15Beta/F15BetaBlocker 678321
  Show dependency treegraph
 
Reported: 2011-02-17 00:19 EST by Hongqing Yang
Modified: 2011-04-05 17:38 EDT (History)
15 users (show)

See Also:
Fixed In Version: anaconda-15.26-1.fc15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-04-01 23:21:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
anaconda log (10.85 KB, text/plain)
2011-02-17 00:19 EST, Hongqing Yang
no flags Details
Wipe out pre-existing problems before transaction (1.04 KB, patch)
2011-02-23 02:19 EST, Panu Matilainen
no flags Details | Diff
F-15 Alpha RC2 anaconda log (10.86 KB, text/plain)
2011-02-28 21:35 EST, Hongqing Yang
no flags Details

  None (edit)
Description Hongqing Yang 2011-02-17 00:19:24 EST
Created attachment 479264 [details]
anaconda log

Description of problem:

when upgrade from f14 to f15 alpha tc2 with option "Create new boot loader configuration", there are package conflicts.

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


How reproducible:


Steps to Reproduce:
1.boot from f15 alpha tc2 DVD.iso
2. select upgrade exiting system
3. select Create new boot loader configuration
  
Actual results:
Error Running Transaction dialog pop up.

Expected results:


Additional info:
Test case :https://fedoraproject.org/wiki/QA:Testcase_Anaconda_Upgrade_New_Bootloader
Comment 1 James Laska 2011-02-17 08:30:25 EST
05:05:01,141 ERR anaconda: package conflicts: upstart-sysvinit conflicts with systemd-17-5.fc15.x86_64
05:05:01,142 ERR anaconda: package conflicts: systemd-sysvinit conflicts with (installed) upstart-sysvinit-0.6.5-9.fc14.x86_64

I believe this is the same issue reported in bug#676815

Can you repeat the test, while enabling updates-testing so it pulls systemd-18-1.fc15 (https://admin.fedoraproject.org/updates/systemd-18-1.fc15) into the transaction.

*** This bug has been marked as a duplicate of bug 676815 ***
Comment 2 James Laska 2011-02-17 10:39:40 EST
Apologies, I hastily closed this issue.  Upon closer inspection, there are other package failures listed besides the systemd conflict.  If memory serves, the installer ignores dependency problems on upgrade, but recognizes package conflicts.  I hope that's the case, otherwise we have a *lot* of package dependency bugs that will need to be resolved for upgrade to work.

In order to proceed with the remaining package issues, I think we'll need clarification from the installer team on how package dependencies are handled on upgrade.  If they are ignored, then a bug against anaconda may be in order (since it is not ignoring them).  If they are recognized, then a bug against *each* src.rpm that has dependency problems will be needed.  That will be a *lot* of bugs :(

Reassigning to 'anaconda' and adding 'clumens' to the cc for some insight.  Chris, any thoughts?
Comment 3 James Laska 2011-02-18 10:43:56 EST
According to clumens, this could be a behavior change with the new rpm-4.9 in Fedora (https://fedoraproject.org/wiki/Features/RPM4.9).

10:34:27  clumens:         if self.anaconda.upgrade:
10:34:28  clumens:             self.ts.ts.setProbFilter(~rpm.RPMPROB_FILTER_DISKSPACE)

@Panu - Any thoughts on changes that might have altered this behavior?
Comment 4 Panu Matilainen 2011-02-22 01:59:24 EST
Hum. Problem filtering never allowed filtering out conflicts, so that shouldn't be an issue. The dependency checking code did see a whole lot of changes in 4.9.x so its a possibility something there is misfiring ... but in general, conflicts are conflicts and if anything, it'd probably be yum that should be figuring a way out of them.

Do you have a log of what is being triggered as conflicts so I can get a better idea what's going on?
Comment 5 James Laska 2011-02-22 07:40:11 EST
(In reply to comment #4)
> Do you have a log of what is being triggered as conflicts so I can get a better
> idea what's going on?

Hi Panu.  Does the end of attachment#479624 [details] have the level of detail you are looking for?

05:04:26,327 INFO anaconda: Preparing to install packages
05:05:01,141 ERR anaconda: package conflicts: upstart-sysvinit conflicts with systemd-17-5.fc15.x86_64
05:05:01,142 ERR anaconda: package conflicts: systemd-sysvinit conflicts with (installed) upstart-sysvinit-0.6.5-9.fc14.x86_64
05:05:01,142 ERR anaconda: required package: libpanel-applet-2.so.0()(64bit) is needed by gnome-pilot-2.32.0-4.fc15.x86_64
05:05:01,143 ERR anaconda: required package: libgucharmap.so.7()(64bit) is needed by (installed) gnome-applets-1:2.32.0-1.fc14.x86_64
05:05:01,143 ERR anaconda: required package: libpanel-applet-2.so.0()(64bit) is needed by (installed) gnome-python2-applet-2.32.0-1.fc14.x86_64
05:05:01,143 ERR anaconda: required package: libpanel-applet-2.so.0()(64bit) is needed by (installed) libpanelappletmm-2.26.0-2.fc12.x86_64
05:05:01,144 ERR anaconda: required package: libpanel-applet-2.so.0()(64bit) is needed by (installed) gnome-applets-1:2.32.0-1.fc14.x86_64
05:05:01,144 ERR anaconda: required package: libpanel-applet-3.so.0()(64bit) is needed by (installed) gnome-applets-1:2.32.0-1.fc14.x86_64
05:05:01,144 ERR anaconda: required package: system-config-network-tui = 1.6.1-1.fc14 is needed by (installed) system-config-network-1.6.1-1.fc14.noarch
05:05:01,144 ERR anaconda: required package: policycoreutils-python = 2.0.83-28.fc14 is needed by (installed) policycoreutils-gui-2.0.83-28.fc14.x86_64
05:05:01,145 ERR anaconda: required package: setools-libs = 3.3.7-7.fc14 is needed by (installed) setools-console-3.3.7-7.fc14.x86_64
05:05:01,145 ERR anaconda: required package: libgweather.so.1()(64bit) is needed by (installed) gnome-applets-1:2.32.0-1.fc14.x86_64
05:05:01,145 ERR anaconda: required package: libnotify.so.1()(64bit) is needed by (installed) krb5-auth-dialog-0.16-1.fc14.x86_64
05:05:01,146 ERR anaconda: required package: libnotify.so.1()(64bit) is needed by (installed) gnome-applets-1:2.32.0-1.fc14.x86_64
Comment 6 Panu Matilainen 2011-02-22 08:04:15 EST
Ok so the only actual conflict was the systemd thing which as already been fixed by obsoleting upstart (bug 676815). The rest look like simply real, broken dependencies in the repository (looking at the curren branched-reports, there are TONS of broken dependencies around libpanel-applet and friends so no big surprise). In other words, those packages need fixing.

Or is anaconda actually supposed to continue despite such broken dependencies, but doesn't do so with rpm 4.9.x?
Comment 7 Chris Lumens 2011-02-22 10:23:30 EST
On upgrade, anaconda should catch the broken dependency case and keep going I believe.  On install, it should catch this and offer to let you change package selections, exit, or continue.  Upgrades don't get that choice because there's no package selection.
Comment 8 James Laska 2011-02-22 10:48:55 EST
I retested this upgrade issue last week, with kickstart and a custom repository that included the proper systemd packages.  The installer still stopped at broken dependencies.

Bug#678321 tracks an issue related to the empty error dialog, but the attachment on that bug has additional logs showing dependency problems on upgrade.
Comment 9 Panu Matilainen 2011-02-23 02:19:29 EST
Created attachment 480360 [details]
Wipe out pre-existing problems before transaction

Ahhat, I see where the difference in behavior with rpm 4.9.x comes from... This is just another characteristically convoluted rpm issue (sigh)

Older versions silently wiped out any pre-existing problems in the transaction at the start of ts.run(), regardless of whether they could be filtered or not, and ts.setProbFilter() never supported filtering out dependency problems. The assumption is that if you call ts.check(), you care about its results - there's no poing calling it if you dont, so "normal" callers dont hit this issue at all.

I'll need to consider whether to make 4.9.x behave like older versions in this corner-case, but the attached patch should fix the issue here, and as an added bonus, save a bit of memory (nothing too dramatic but a few megs anyway on larger installs).
Comment 10 Panu Matilainen 2011-02-23 02:32:50 EST
Hrmph, bugzilla seems to mangle patch attachments, making a mess out of git-format-patch generated patch comments :-/

Anyway, in addition to the above patch, you might want to consider one of these

1) don't bother calling ts.check() at all on upgrades, since we dont care about the results
@@ -1004,7 +1004,8 @@ class AnacondaYum(yum.YumBase):
             else:
                 return DISPATCH_BACK
 
-        self.ts.check()
+        if not self.anaconda.upgrade:
+            self.ts.check()
         self.ts.order()
         self.ts.clean()
 
2) always call ts.check(), but (optionally) let upgrade continue despite problems (more of a pseudo-patch):
@@ -1005,6 +1005,13 @@ class AnacondaYum(yum.YumBase):
                 return DISPATCH_BACK
 
         self.ts.check()
+        if self.ts.problems():
+            if self.anaconda.upgrade:
+                # let user know there are problems and choose to continue
+                # or abort?
+            else: 
+                # on install we should bail out right here, although this
+                # is unlikely to happen
         self.ts.order()
         self.ts.clean()
Comment 11 Chris Lumens 2011-02-23 10:54:50 EST
Looking at just the minimal patch from comment #9, James - can you retest with the F15 alpha containing anaconda-15.20.1-1 and updates=http://clumens.fedorapeople.org/678201.img?

Panu - thanks for the patches.  Much appreciated.
Comment 12 James Laska 2011-02-23 11:58:10 EST
(In reply to comment #11)
> Looking at just the minimal patch from comment #9, James - can you retest with
> the F15 alpha containing anaconda-15.20.1-1 and
> updates=http://clumens.fedorapeople.org/678201.img?

Seems to do the trick.  Tested upgrades from F-14-i386 @base and F-14-x86_64 --default.  No conflicts dialogs were presented.

The pre-upgraded F-14-x86_64 was exposed to the same potential dependency conflict (libpanel-applet) noted earlier, and I was not prompted about the problem while using the updates.img.  I'll review the system post-upgrade, but this appears to do the right thing.
Comment 13 James Laska 2011-02-23 12:02:49 EST
Confirmed, there were package dependency problems present on the post-upgraded systems.  Those were resolved by packaged in updates-testing, but the good news is that the updates.img seems to have worked.  Good bug report Hongqing, thanks all!
Comment 14 James Laska 2011-02-23 13:01:05 EST
Proposing for F15 Beta since this blocks the following criteria:

"The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation of the previous stable Fedora release, either via preupgrade or by booting to the installer manually "

https://fedoraproject.org/wiki/Fedora_15_Beta_Release_Criteria
Comment 15 Chris Lumens 2011-02-23 13:29:48 EST
I'll consider the patches in comment #10 for post-f15, but for now I'm only pushing the minimum amount required to fix the problem.
Comment 16 Chris Lumens 2011-02-28 10:01:09 EST
*** Bug 680820 has been marked as a duplicate of this bug. ***
Comment 17 Chris Lumens 2011-02-28 10:03:10 EST
*** Bug 680851 has been marked as a duplicate of this bug. ***
Comment 18 Hongqing Yang 2011-02-28 21:33:39 EST
reproduced in fedora 15 alpha rc2.
Comment 19 Hongqing Yang 2011-02-28 21:35:35 EST
Created attachment 481482 [details]
F-15 Alpha RC2 anaconda log
Comment 20 Hongqing Yang 2011-03-03 01:38:46 EST
The duplicate bug 676815 has been closed as Errata.
Comment 21 James Laska 2011-03-03 10:16:20 EST
(In reply to comment #20)
> The duplicate bug 676815 has been closed as Errata.

Let's keep this bug open until a new anaconda is built that includes the anaconda fix to ignore package deps/conflicts on upgrade.
Comment 22 James Laska 2011-03-03 10:20:57 EST
Fix included in anaconda.git, will be in next F-15 anaconda build.

http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=18d0b27146ffe328df9ace3984d601ad7bac19c6
Comment 23 James Laska 2011-03-11 14:41:31 EST
Discussed at 2011-03-11 blocker review meeting.  This issue is fixed and available for testing in anaconda-15.21-1.  The issue has been accepted as a beta blocker.
Comment 24 Fedora Update System 2011-03-29 16:51:55 EDT
anaconda-15.26-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/anaconda-15.26-1.fc15
Comment 25 Fedora Update System 2011-03-29 22:25:27 EDT
Package anaconda-15.26-1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-15.26-1.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/anaconda-15.26-1.fc15
then log in and leave karma (feedback).
Comment 26 Fedora Update System 2011-04-05 17:37:22 EDT
anaconda-15.26-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

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