NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: 9.1 upgrade fails: Shared object"" not found

Bob Bernstein <> wrote:

> Shared object "" not found
> The message shown is what appeared as I finished what appeared 
> to be an uneventful upgrade from an old 'current' netbsd (May 
> of last year) to amd64 9.1.
> trouble appeared:
> panic init died (signal 0, exit 1)

As people pointed out you updated your system to something that is
newer in terms of time, but older in terms of versioning.

Before the installation you had (using random numbers for the sake of
the example) /lib/ from the -current you had installed.
Then you installed the relase that had /lib/  So before
the upgrade you had in your /lib something like:

lrwxr-xr-x  1 root  wheel ... Dec 31  2019 ->
lrwxr-xr-x  1 root  wheel ... Dec 31  2019 ->
-r--r--r--  1 root  wheel ... Dec 31  2019

The link is for ld(1) to link new programs.

The link is for for ld.elf_so(1) to run dynmaically linked
programs that have recorded as NEEDED dependency.

After upnacking the 9.x sets your /lib looked like:

lrwxr-xr-x  1 root  wheel ... Jan  1  2020 ->
lrwxr-xr-x  1 root  wheel ... Jan  1  2020 ->
-r--r--r--  1 root  wheel ... Jan  1  2020   # 9.x
-r--r--r--  1 root  wheel ... Dec 31  2019   # current

Now, postinstall(8) has code to delete unused minor versions.  It
*used* to be naive and only checked for the minor number, so in a
situation like the above (system downgrade) it would see 128 and 256,
conclude the 128 is less than 256 and must be older, and delete it.
So you would end up with

lrwxr-xr-x  1 root  wheel ... Jan  1  2020 ->
lrwxr-xr-x  1 root  wheel ... Jan  1  2020 ->
-r--r--r--  1 root  wheel ... Dec 31  2019

with the symlinks dangling and dynamic binaries (including init) that
depend on effectively dead.

That's where you would get Shared object "" not found

Christos committed a fix for this in rev 1.5:

revision 1.5
date: 2019-06-15 16:07:09 +0300;  author: christos;  state: Exp;  lines: +33 -10;  commitid: E0z7TwCLRxb8MhrB;
branches:  1.5.2;
exclude shared libraries that are currently in use from removal.

and seeing that 1.5 is the netbsd-9-base your 9.1 should have that
fix.  Yet it looks like somehow you managed to get yourself in a
situtation like the one described above.  I don't think you posted the
list of files from the hdd's /lib (I've only seen the one done for the
installation media by mistake).  So the first thing you need to
confirm is that you are indeed in the deal symlink situtation like the

I'm not sure how did you manage to end up with the situtation like
this if it's indeed that case.  The postinstall you have from 9.*
should be ok.

To fix this (if that's indeed your problem) you can boot either with
an installation media or from the installed system but with -a and use
static (crunched) /rescue/init when it asks you.  Then you can unpack
base.tgz again to restore the necessary minor versions of the shared
libraries. if you feel adventurous, you can run postinstall fix
obsolete and see what if you can reproduce the problem :)


Home | Main Index | Thread Index | Old Index