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 <[email protected]> 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" <[email protected]> Message-ID:
>> <[email protected]>
>>
>> | 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
>
