Bug 485133

Please attach /var/log/anaconda.log and /root/upgrade* to this bug report.  Thanks.

Created attachment 331678 [details]
/var/log/anaconda.log

Created attachment 331679 [details]
/root/upgrade.log.syslog

This may not contain what you need.   I had to rerun upgrade to get 
grub to work.   First time, system was not bootable.

This sounds like a packaging bug to me - perhaps something funny going on with scriptlets.  anaconda doesn't do anything special with these packages, and you aren't on x86-64 so there's no multilib weirdness going on here.

This just happened to me also.  Upgrade F8 to F10 using DVD anaconda upgrade install.  Solution was same as Curt's, using loopback mounts off the DVD images: not something a newbie could figure out!  With yum and rpm dead, this is a tricky one to resolve.

I see no useful info in the logs you request, but I will attach anyhow.

My guess is in F8 they are symlinks and in F10 they are real files in /usr/lib.  The upgrade is failing as it tries to overwrite the symlinks with files.  Just a guess.

Created attachment 332852 [details]
anaconda log from the botched upgrade

Created attachment 332853 [details]
upgrade.log.syslog from the botched upgrade

In Fedora 8, the NSPR shared library (.so) files were placed in 
  /usr/lib

On Fedora 9 we started to place them in
  /lib

On Fedora 10, the same logic is still in place.

No symlinks used on Fedora 8.
On Fedora 9 + 10, as part of the nspr-devel package, we provide symlinks in /usr/lib that point to the new location.

I wonder why you see this problem when going to from 8 to 10 (only), because I haven't heard about failures when upgrading from 8 to 9.

Maybe rpm.fc9 did not depend on nspr, but rpm.fc10 does?

The symbolic links are not created using rpm scripts. Instead they are stored directly in the rpm package.

(In reply to comment #0)
> 3. /usr/lib/libplc4.so was a broken link to /lib/libplc4.so
>    same for libplds4.so and libnspr4.so

This sounds like
- nspr-devel was installed
  (because you have the links)
- nspr was not installed
  (because you don't have files in /lib

Maybe during the upgrade, the nspr-devel package got installed first?
This wiped the .so files, and replaced them with broken links.

Subsequent install of nspr may have failed, because the new rpm depends on the nspr .so files, which were gone.

I would have expected that the nspr packages gets installed first, because nspr-devel requires nspr.

I did/do have nspr-devel installed.  Unfortunately it looks like anaconda doesn't log the individual package installs to see the order?

Do you have /root/anacdump.txt ?
Does it tell you the order?

I have one from an upgrade to Fedora 9.
It tells me that nspr gets installed first, much earlier than nspr-devel.

No anacdump.txt, but I did find a upgrade.log.

line 438 nspr-devel-4.7.2-2.fc10.i386
--- and NO line for nspr!  So nspr wasn't installed at all?  Sounds fishy, as my F8 box certainly had nspr on it before the upgrade.

@Curt, in your initial description you said, you manually copied the .so files contained in nspr.rpm from a different location.

Do you know what
  rpm -qi nspr
said afterwards?

Did it report "nspr" was installed or missing?


@Trevor, what do you get?


It sounds really strange, because nspr-devel requires the nspr package.

jkeating:

when upgrading from f9 to f10, 
  both nspr and nspr-devel get updated

when upgrading from f8 to f10, 
  it appears that "nspr-devel" gets updated, 
  but "nspr" package is skipped
    (or fails => but no entry in logfile,
     or even gets removed (pending feedback from Curt/Trevor))

We don't understand why.

nspr-devel always requires nspr

rpm -qi nspr
Name        : nspr                         Relocations: (not relocatable)
Version     : 4.7.3                             Vendor: Fedora Project
Release     : 1.fc8                         Build Date: Wed 19 Nov 2008 12:37:07 PM EST
Install Date: Thu 04 Dec 2008 07:46:33 PM EST      Build Host: xenbuilder4.fedora.phx.redhat.com
Group       : System Environment/Libraries   Source RPM: nspr-4.7.3-1.fc8.src.rpm
Size        : 250676                           License: MPLv1.1 or GPLv2+ or LGPLv2+
Signature   : DSA/SHA1, Mon 01 Dec 2008 04:48:30 PM EST, Key ID 62aec3dc6df2196f
Packager    : Fedora Project
URL         : http://www.mozilla.org/projects/nspr/
Summary     : Netscape Portable Runtime
Description :
NSPR provides platform independence for non-GUI operating system
facilities. These facilities include threads, thread synchronization,
normal file and network I/O, interval timing and calendar time, basic
memory management (malloc and free) and shared library linking.

rpm -qi nspr-devel
Name        : nspr-devel                   Relocations: (not relocatable)
Version     : 4.7.2                             Vendor: Fedora Project
Release     : 2.fc10                        Build Date: Wed 22 Oct 2008 11:36:57 PM EDT
Install Date: Mon 09 Feb 2009 10:30:29 PM EST      Build Host: xenbuilder4.fedora.phx.redhat.com
Group       : Development/Libraries         Source RPM: nspr-4.7.2-2.fc10.src.rpm
Size        : 523967                           License: MPLv1.1 or GPLv2+ or LGPLv2+
Signature   : DSA/SHA1, Wed 29 Oct 2008 12:15:56 AM EDT, Key ID bf226fcc4ebfc273
Packager    : Fedora Project
URL         : http://www.mozilla.org/projects/nspr/
Summary     : Development libraries for the Netscape Portable Runtime
Description :
Header files for doing development with the Netscape Portable Runtime.


Since nspr is there from FC8, it would appear that the nspr-devel upgrade is happy with the FC8 4.7.3 version of nspr.  But, since it has a different location for the shared libs, it won't work later.

Looks like the F8 version of nspr you had installed is NVR higher than the version shipped with F10, so it wouldn't "upgrade" to a lower version.

Yet another problem when updating without taking updates into account.

Some of the required info is lost in time, I think.  When I had this problem upon upgrading, I manually added those so's, then did yum installs/updates to get it back to normal.  I can't recall if nspr was in (ie: I did an update) or out (ie: I did an install).

However, yum.logs going back a year reveal some details:

Jun 22 00:11:50 Updated: nspr - 4.7.1-0.8.1.fc8.i386
Dec 08 18:56:23 Updated: nspr-4.7.3-1.fc8.i386
Feb 21 08:27:29 Updated: nspr-4.7.3-2.fc10.i386
Feb 21 08:31:43 Updated: nspr-devel-4.7.3-2.fc10.i386
** Feb 21 is the F8->F10 upgrade date

The version on the stock F10 DVD is: nspr-4.7.2-2.fc10.i386.rpm.  Therefore, it appears that the F8 update 4.7.3-1 would stay in when anaconda runs.  That is probably what is breaking things.  In most cases, the next yum update would fix things, but in this case nspr breaks in a bad way that messes everything up.

The solution, I think, is to have the F10 aspect of the version number take precedence over all other version numbers.  ie: nspr-f10-4.7.3-2.  Then a f10 package will always take precedence over a f8 package.  There seems to be no other way.

Either that, or the official recommended upgrade path should be yum upgrade and not anaconda upgrade.  I yum upgrade most of my boxes remotely and it almost seems a better way than local DVD anaconda.  Kind of counter-intuitive.

Having the F release number take precedence in the versioning also sounds good, but that will probably be a major change for the Fedora team.

*** Bug 490758 has been marked as a duplicate of this bug. ***

*** Bug 490758 has been marked as a duplicate of this bug. ***

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  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 WONTFIX if it remains open with a Fedora 
'version' of '10'.

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 prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.

Thank you for reporting this bug and we are sorry it could not be fixed.