Re: 8.1; sbin/postinstall 'fix' removes libc.so.12

[Van L <van@scratch.space>]

maya%netbsd.org@localhost 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