Re: repeated failure to properly shutdown

[bch <brad.harder%gmail.com@localhost>]

Wow -- there -is- a tmpfs on /dev

kamloops# mount
        /dev/wd0a on / type ffs (log, local)
->      tmpfs on /dev type tmpfs (union, local)
        /dev/wd0e on /var type ffs (log, local)
        /dev/wd0f on /usr type ffs (log, local)
        /dev/wd0g on /home type ffs (log, local)
        kernfs on /kern type kernfs (local)
        ptyfs on /dev/pts type ptyfs (local)
        procfs on /proc type procfs (local)
        tmpfs on /var/shm type tmpfs (local)


But no entry for it in fstab...

# NetBSD /etc/fstab
# See /usr/share/examples/fstab/ for more examples.
/dev/wd0a		/	ffs	rw,log		 1 1
/dev/wd0b		none	swap	sw,dp		 0 0
/dev/wd0f		/usr	ffs	rw,log		 1 2
/dev/wd0e		/var	ffs	rw,log		 1 2
/dev/wd0g		/home	ffs	rw,log		 1 2
kernfs		/kern	kernfs	rw
ptyfs		/dev/pts	ptyfs	rw
procfs		/proc	procfs	rw
/dev/cd0a		/cdrom	cd9660	ro,noauto

tmpfs	/var/shm	tmpfs	rw,-m1777,-sram%25



How does that happen, how does one fix it ?




On 7/22/16, Ian D. Leroux <idleroux%fastmail.fm@localhost> wrote:
>
>
> On Fri, Jul 22, 2016, at 14:00, Robert Elz wrote:
>>     Date:        Fri, 22 Jul 2016 07:11:50 -0400 From:        "Ian D.
>>     Leroux" <idleroux%fastmail.fm@localhost> Message-ID:
>>     <20160722071150.5248712b562feea8d5c89980%fastmail.fm@localhost>
>>
>>   | Might this be a good moment to test them out and commit them?
>>
>> Perhaps, but not really as a fix for the current problem -- we already
>> know, from what we have been told, that not doing the tmpfs umount
>> avoids the crash ... what I, at least, would like to find is why the
>> crash happens at all, rather than just work around it.
>
> Fair enough.
>
>> That won't make umounting a tmpfs /dev any more rational to do though
>> (but just a tmpfs that happens to contain a device node is perhaps not
>> the right test for what to avoid, and manual specification when that
>> fails to DTRT isn't a great alternative.)
>
> I'm not sure there *is* a truly correct test for what to avoid, given
> the nature of what's being done at swapoff, but there may well be better
> heuristics.  I don't want to derail this thread though, so we can take
> that up separately at a later date.
>
> Good luck fixing the crash!
>
> -- IDL
>