Bob Bernstein <poo...@ruptured-duck.com> 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