Re: repeated failure to properly shutdown

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 22 Jul 2016 12:52:58 -0700
    From:        bch <brad.harder%gmail.com@localhost>
    Message-ID:  <CABfrOT-qp37sZWwfRj+ZeDJqXf5E2TRoXMH0LMQC+DcKB0KR7g%mail.gmail.com@localhost>

  | I think that biggest concern (unclean shutdown/reboot) is solved (collision
  | of /dev and a tmpfs mount, caused by default behavior of init in face of
  | missing /dev/console).

Yes, and now we know what the cause is, we should be able to duplicate the
problem, and work out what is really happening.   The system is supposed to
work with a tmpfs /dev, it should not panic during shutdown.   What's more,
this panic is probably not related to it being /dev - any tmpfs mounted
with -o union on a mount point that is using WAPBL (-o log) will probably
panic the same way.

  | This disk was prepared remotely (I.e. from another running NetBSD box) by
  | partitioning the disk (disklabel), formatting (newfs), then mounting all
  | partitions appropriately under /mnt and running ./build.sh ... install=/mnt

That builds enough for the system to install, but it does not make a
fully runnable system - there's more that sysinst  normally does (like
populating /dev - but also making a basic rc.conf (including all network
config, setting hostname) and fstab, that don't get built by build.sh
either (and nor should they).   Those you must have done later.  Running
MAKEDEV is just another of the steps that one needs to perform.

That /dev/null turned into a regular file is another bug - it is being
created before the tmpfs /dev is made, I have seen that before as well,
but just corrected and ignored the problem until now.   (This turns out
to be a bug in MAKEDEV which is run by init to make the tmpfs /dev when
/dev/console is not present.)

Your solution to that was correct.   (MAKEDEV did not fix it as it never
replaces anything that already exists, only makes what does not - even if
what exists is nonsense, and even if it created the nonsense itself.)

It is good that your problems are overcome now - and thanks for bring it to
our attention, and for being willing to suffer through getting enough info
to allow the problem to be better understood.

kre