Re: 9.1 upgrade fails: Shared object"libc.so.12" not found

[uwe%stderr.spb.ru@localhost (Valery Ushakov)]

Bob Bernstein <poobah%ruptured-duck.com@localhost> wrote:

> Shared object "libc.so.12" 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/libc.so.42.256 from the -current you had installed.
Then you installed the relase that had /lib/libc.so.42.128.  So before
the upgrade you had in your /lib something like:

lrwxr-xr-x  1 root  wheel ... Dec 31  2019 libc.so -> libc.so.42.256
lrwxr-xr-x  1 root  wheel ... Dec 31  2019 libc.so.42 -> libc.so.42.256
-r--r--r--  1 root  wheel ... Dec 31  2019 libc.so.42.256

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

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


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

lrwxr-xr-x  1 root  wheel ... Jan  1  2020 libc.so -> libc.so.42.128
lrwxr-xr-x  1 root  wheel ... Jan  1  2020 libc.so.42 -> libc.so.42.128
-r--r--r--  1 root  wheel ... Jan  1  2020 libc.so.42.128   # 9.x
-r--r--r--  1 root  wheel ... Dec 31  2019 libc.so.42.256   # 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 libc.so -> libc.so.42.128
lrwxr-xr-x  1 root  wheel ... Jan  1  2020 libc.so.42 -> libc.so.42.128
-r--r--r--  1 root  wheel ... Dec 31  2019 libc.so.42.256

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

That's where you would get Shared object "libc.so.12" not found

Christos committed a fix for this in postinstall.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
above.

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 :)

-uwe