[email protected] writes: > On Thu, Jun 06, 2019 at 09:16:31PM +1000, Van L wrote:
[ What happens is libc.so is lost ] > > Unrelated to this, to recover: > > Boot single user (wiht a boot menu, or drop to boot prompt and 'boot-s') > export PATH=/rescue > mount -a # so it's read-write / > this provides ifconfig, route to connect to the internet, and ftp and > tar to unpack a new base.tgz. --8<---------------cut here---------------start------------->8--- https://www.netbsd.org/docs/current/index.html vvv ; to recover , drop to boot prompt and 'boot-s' for single-user , 'export PATH=/rescue' , 'mount -a' for read-write access to filesystem , use ifconfig, route to unpack base.tgz ... : why does this happen . say you have lib.so.12 -> lib.so.12.212 on nb8.1-rc . the machine gets stuck and you unpack sets from nb8.0 . lib.so.12 -> lib.so.12.207 is created . then postinstall discovers "older minors to dispose of" _^_ --8<---------------cut here---------------end--------------->8--- > Most likely, you had: > libc.so.12.207, libc.so.12.208 > From unpacking older sets, you gained a symlink to an older minor: > libc.so.12 -> libc.so.12.207 > Postinstall apparently sees, "old minors! I can get rid of it!" > > It should probably check that it's not in use. > It would be helpful to update https://www.netbsd.org/docs/current/index.html with the above clipping Also, the guide to create a bootable USBkey has pitfalls. -- © 2019 Van L gpg using EEF2 37E9 3840 0D5D 9183 251E 9830 384E 9683 B835 "you have to be Albert Einstein to figure it out" - Donald J. Trump
