Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: repeated failure to properly shutdown



mknod null c 2 2 did the trick, things boot/reboot alright now.

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

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

Clearly some things didn't fully work. I've got some shutdown msgs that seem new (though in situations like this (suspect system), under hard scrutiny a lot of things start looking "new")... I'll post that in a new thread, as I think it's out of scope for this threads intended purpose...

Thanks everyone for the help. I learned a bit more, and had fun.

-bch

On Jul 22, 2016 12:32 PM, "bch" <brad.harder%gmail.com@localhost> wrote:

For some reason /dev/null is just a regular file... looking for its device special numbers to put it in by mknod...

I see what you're saying, did it (and do have a console device), but now my etc/defaults/rc.d is barfing on: cannot create /dev/null: read only file system

On Jul 22, 2016 11:41 AM, "Martin Husemann" <martin%duskware.de@localhost> wrote:
On Fri, Jul 22, 2016 at 11:37:56AM -0700, bch wrote:
> How does that happen, how does one fix it ?

It is created by init if there is no /dev/console.

Boot some install media, mount your root file system (say on /mnt)
then:

        cd /mnt/dev
        sh MAKEDEV all

(hoping there is a MAKEDEV script there, if not: extract it from etc.tgz
from the install sets)

Then reboot and check mount again.

Martin


Home | Main Index | Thread Index | Old Index