[jaunty] last update broke some libraries (libnss3-1d, libnspr4-0d)

Bug #316452 reported by Bogdan Butnaru on 2009-01-12
20
Affects Status Importance Assigned to Milestone
nspr (Ubuntu)
High
Unassigned
Jaunty
High
Unassigned
nss (Ubuntu)
High
Unassigned
Jaunty
High
Unassigned

Bug Description

Hello! I'm running an (almost) up-to-date Jaunty here.

Earlier today I did an "aptitude safe-upgrade", and I didn't check the output very carefully. After a restart, I got a report that the clock applet crashed, which I ignored (it happens); then I noticed my network wasn't running, and Firefox refused to start.

So I looked around a bit and noticed the boot log (in the console) complained that NetworkManager can't start because of a missing libnss3.so.1d. Indeed, when I checked the package libnss3-1d was there and was supposed to have that file, but the file wasn't there (libnss3.so existed, though).

I started the network manually and did an "aptitude reinstall libnss3-1d", which created the correct link. Firefox still wasn't starting and it wasn't telling me why, so I installed epiphany-gecko which complained about a missing libnspr4.so.0d. So I did the same thing, now Firefox is running (I'm sending this report with it).

I've no idea why those two links were missing, maybe somebody should look into it. Anyone have any idea how to find out if I've got other missing files?

I attached the contents of /var/log/apt/term.log, starting with the upgrade I did that triggered all this (I left all operations I did afterwards in there).

Bogdan Butnaru (bogdanb) wrote :
Bogdan Butnaru (bogdanb) wrote :

Just in case somebody needs this, the script below will display missing files from your computer (in the sense that dpkg believes a package supplies a certain file, but the file either doesn't exist or is a dangling symlink). It found quite a few problems, but I didn't have time to figure out what's wrong with each and report them.

#!/bin/bash
for PAK in `dpkg-query -W -f='${Package} '`; do
 dpkg-query -L $PAK \
  | sed 's/diverted by [^:]*: //;s/package diverts others to: //' \
  | xargs -I {} \
   bash -c '\
    if [ ! -e "$0" ] ; then \
     if [ -L "$0" ]; then \
      echo Dangling link "$0" in package '"$PAK"';\
     else
      echo File "$0" missing from package '"$PAK"';\
     fi;\
    fi'\
   {}
 #break
done

Alexander Sack (asac) wrote :

you probably cannot reproduce this by downgrading and upgrading agian?

Alexander Sack (asac) wrote :

Could you also post the full list of problems you found? I dont really have a good understanding what could have caused this exceptional situation for you, but maybe seeing the other problems will give a hint in what state your system is. Thanks!

Bogdan Butnaru (bogdanb) wrote :
Download full text (8.5 KiB)

I'm not sure how to even do a downgrade, and I'm too busy this month to learn.

About the missing files, I doubt it's exactly related to the above problem (and some of them may note be exactly bugs), but I put below a list of what the script above reports. I don't think I'll have time to do a thorough investigation soon, but if you have some specific test I might squeeze that in somewhere.

Dangling link /usr/share/java/ant-bootstrap.jar in package ant
Dangling link /usr/share/doc/bash/README.bash_completion.gz in package bash-completion
Dangling link /usr/share/doc/bash/completion-contrib in package bash-completion
Dangling link /usr/share/locale/af/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/be/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/bg/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/ca/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/cs/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/da/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/de/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/el/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/es/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/et/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/eu/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/fi/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/fr/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/ga/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/gl/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/hu/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/it/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/ja/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/ko/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/ms/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/nb/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/nl/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/pl/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/pt/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/pt_BR/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/ru/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/rw/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/sk/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/sl/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/sv/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/tr/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/uk/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/vi/LC_TIME/coreutils.mo in package coreutils
Dangling link /usr/share/locale/...

Read more...

hoffmajs (hoffmajs) wrote :

I had the same problem that firefox no longer worked after upgrade.
(at least in my case) it was because /usr/lib/libnss3.so.0d (from libnss3-0d) was a dangling symlink to
/usr/lib/libnss3.so.1d.
After i saw that there is a package libnss3-1d, i installed that and firefox worked again..
so the real problem was that libnss3-1d was needed but no other package depended on it.

Bogdan Butnaru (bogdanb) wrote :

I've no idea why, but I'm almost sure libnss3-1d _was_ installed in my case. It was just missing that link, and a simple reinstall added it.

Alexander Sack (asac) wrote :

definitly a blocker.

Changed in nspr:
importance: Undecided → High
status: New → Confirmed
Changed in nss:
status: New → Confirmed
Michael Vogt (mvo) wrote :

I can reproduce the breakage of nspr with the automatic upgrade tester for a intrepid -> jaunty upgrade.
It fails to upgrade with the message:

/usr/lib/xulrunner-1.9.0.5/xulrunner-bin: error while loading shared libraries: libplds4.so.0d: cannot open shared object file: No such file or directory

This is from a stock intrepid->jaunty upgrade. Indeed the symlink for libplds4.so.0d are missing, just the regular files are there (.so)

Changed in nspr:
milestone: none → jaunty-alpha-3
status: Confirmed → Triaged
Alexander Sack (asac) wrote :

seems to happen when doing intrepid to jaunty upgrades.

Changed in nss:
importance: Undecided → High
milestone: none → jaunty-alpha-3
status: Confirmed → Triaged
Alexander Sack (asac) wrote :

another interesting message is:

/sbin/ldconfig.real: /usr/lib/libnssutil3.so is not a symbolic link

Alexander Sack (asac) wrote :

for convenience i pasted ldconfig source here: http://paste.ubuntu.com/104781/

Ara Pulido (ara) wrote :

It happened to me when upgrading intrepid -> jaunty.

Workaround:

$ sudo dpkg -i /var/cache/apt/archives/libnspr4<tab>
$ sudo dpkg -i /var/cache/apt/archives/libnss3<tab>
$ sudo dpkg --configure -a

James Westby (james-w) wrote :

I hit this as well.

For me it seems like /usr/lib/libnss3.so.0d (and libnssutil3.so.0d) were not
present, though apparently the packages were installed.

I used dpkg to install the packages from /var/cache/apt/archives/ and it
said "Preparing to replace libnss3-0d <version> (using <same version>)"
but the files appeared afterwards. /var/log/dpkg.log confirms that the package
was installed before I did that.

Thanks,

James

Alexander Sack (asac) wrote :

Current understanding is:

1. Seems that ldconfig recreates the link that i tried to move away in .preinst:

11:39 < mvo> asac: hm, right now (upgrade sitll running) I have libplc4.so.0d ->
             libplc4.so.0d.new-migration

2. Then when unpack happens the link already exists and is not retargetted to the right file (libplc4.so) because of that.

3. later .new-migration is removed and ldconfig removes the then broken link leading to the broken situation we have here.

Current approach is to prevent ldconfig from recreating the link (step 1.) fixing the unpack (step 2.). Lets see if we can verify that this works.

Alexander Sack (asac) wrote :
Changed in nspr:
status: Triaged → Fix Committed
Alexander Sack (asac) wrote :
Changed in nss:
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nss - 3.12.2~rc1-0ubuntu2

---------------
nss (3.12.2~rc1-0ubuntu2) jaunty; urgency=low

  * LP: #316452 - ldconfig breaks/removes legacy links for
    previously versioned library names during upgrade; the fix
    prevents ldconfig from treating the transitional/backup files
    as "libs" by using a prefix ("XNOLDCONFIG_")
    - debian/libnspr4-0d.postinst
    - debian/libnspr4-0d.postrm
    - debian/libnspr4-0d.preinst
    - debian/libnspr4-0d.prerm

 -- Alexander Sack <email address hidden> Wed, 14 Jan 2009 13:27:07 +0100

Changed in nss:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nspr - 4.7.3-0ubuntu2

---------------
nspr (4.7.3-0ubuntu2) jaunty; urgency=low

  * LP: #316452 - ldconfig breaks/removes legacy links for
    previously versioned library names during upgrade; the fix
    prevents ldconfig from treating the transitional/backup files
    as "libs" by using a prefix ("XNOLDCONFIG_")
    - debian/libnspr4-0d.postinst
    - debian/libnspr4-0d.postrm
    - debian/libnspr4-0d.preinst
    - debian/libnspr4-0d.prerm

 -- Alexander Sack <email address hidden> Wed, 14 Jan 2009 13:27:43 +0100

Changed in nspr:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers