Bug 485133 - missing shared libs after upgrade from Fedora 8 to Fedora 10
missing shared libs after upgrade from Fedora 8 to Fedora 10
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
10
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
: 490758 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-11 14:30 EST by Curt Fiene
Modified: 2013-01-10 00:03 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 02:53:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/anaconda.log (14.44 KB, text/plain)
2009-02-12 06:23 EST, Curt Fiene
no flags Details
/root/upgrade.log.syslog (2.12 KB, text/plain)
2009-02-12 06:27 EST, Curt Fiene
no flags Details
anaconda log from the botched upgrade (16.64 KB, text/plain)
2009-02-22 08:26 EST, Trevor Cordes
no flags Details
upgrade.log.syslog from the botched upgrade (3.95 KB, text/plain)
2009-02-22 08:27 EST, Trevor Cordes
no flags Details

  None (edit)
Description Curt Fiene 2009-02-11 14:30:16 EST
Description of problem:
During a upgrade from Fedora 8 to Fedora 10 from DVD,
3 shared libraries were missing that thinks like ssh and rpm from working.
I was able to reproduce this on my desktop and laptop.

I do not have the bandwidth to upgrade via network, so have used boot media
burned at work.

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

iso image obtained from:

http://mirrors.kernel.org/fedora/releases/10/Fedora/i386/iso/Fedora-10-i386-DVD.iso           20-Nov-2008 00:56  3.4G 


How reproducible:
 2 for 2

Steps to Reproduce:
1. Upgrade Fedora 8 to Fedora 10 by booting from DVD.
2. try to run rpm or ssh, will report missing shared libraries
3. /usr/lib/libplc4.so was a broken link to /lib/libplc4.so
   same for libplds4.so and libnspr4.so
4. was able to copy libs from another system to resolve
  
Actual results:


Expected results:


Additional info:
Comment 1 Chris Lumens 2009-02-11 14:36:59 EST
Please attach /var/log/anaconda.log and /root/upgrade* to this bug report.  Thanks.
Comment 2 Curt Fiene 2009-02-12 06:23:52 EST
Created attachment 331678 [details]
/var/log/anaconda.log
Comment 3 Curt Fiene 2009-02-12 06:27:23 EST
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.
Comment 4 Chris Lumens 2009-02-20 14:00:09 EST
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.
Comment 5 Trevor Cordes 2009-02-22 08:25:37 EST
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.
Comment 6 Trevor Cordes 2009-02-22 08:26:39 EST
Created attachment 332852 [details]
anaconda log from the botched upgrade
Comment 7 Trevor Cordes 2009-02-22 08:27:27 EST
Created attachment 332853 [details]
upgrade.log.syslog from the botched upgrade
Comment 8 Kai Engert (:kaie) 2009-02-26 12:49:06 EST
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.
Comment 9 Kai Engert (:kaie) 2009-02-26 12:53:22 EST
(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.
Comment 10 Trevor Cordes 2009-02-27 09:57:20 EST
I did/do have nspr-devel installed.  Unfortunately it looks like anaconda doesn't log the individual package installs to see the order?
Comment 11 Kai Engert (:kaie) 2009-02-27 11:58:55 EST
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.
Comment 12 Trevor Cordes 2009-02-27 12:49:35 EST
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.
Comment 13 Kai Engert (:kaie) 2009-03-05 21:45:16 EST
@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.
Comment 14 Kai Engert (:kaie) 2009-03-05 21:49:14 EST
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
Comment 15 Curt Fiene 2009-03-06 09:03:18 EST
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.
Comment 16 Jesse Keating 2009-03-06 12:44:49 EST
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.
Comment 17 Trevor Cordes 2009-03-08 19:52:28 EDT
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.
Comment 18 Chris Lumens 2009-03-18 10:52:14 EDT
*** Bug 490758 has been marked as a duplicate of this bug. ***
Comment 19 Chris Lumens 2009-10-28 11:12:52 EDT
*** Bug 490758 has been marked as a duplicate of this bug. ***
Comment 20 Bug Zapper 2009-11-18 06:05:28 EST
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
Comment 21 Bug Zapper 2009-12-18 02:53:51 EST
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.

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