[OpenIndiana-discuss] Recreate /dev/null

[James Carlson]

On 04/25/13 08:03, Richard Jones wrote:
> On Thu, Apr 25, 2013 at 01:30:35PM +0200, Jim Klimov wrote:
>> How about removing both /devices/pseudo/mm at null* and /dev/null and
>> then trying devfsadm?
> 
> # rm /dev/null
> rm: cannot remove `/dev/null': No such file or directory
> # rm /devices/pseudo/mm at 0:null
> rm: cannot remove `/devices/pseudo/mm at 0:null': Operation not applicable
> # devfsadm
> devfsadm: cannot create link: /dev/null -> ../devices/pseudo/mm at 0:null.
> max attempts exceeded

You can't manually whack things in /dev or /devices, because those
things don't exist in a disk-based file system, in exactly the same way
that the contents of /proc is purely a fiction in memory.  See dev(7FS),
devfs(7FS) and proc(4) for the gory details of those.  There are others
of these ilk around, such as objfs(7FS), which mounts on /system/object,
ctfs(7FS) on /system/contract, and mnttab(4) on /etc/mnttab.  (No, I
can't readily explain why the man pages are scattered like that.  :-/)

Things are not as they were ages ago, when /dev and /devices were actual
directories on disk with real files in them that had to be periodically
maintained (sometimes with the "reconfiguration reboot" which is
similarly gone).  This all changed with PSARC/2003/246 "Filesystem
Driven Device Naming".  (As a side note, this means that due to that
project, if you once had a habit of doing something like "ln -s cua/a
mymodem", that simply does not work following the introduction of that
project; you can't write to a file system that doesn't exist.)

If the contents of /dev or /devices is wrong, then it means that the
information backing the devfs driver is bad.  Part of this information
is kept in /etc/devices/, at least for dynamic devices (e.g., SCSI
disks).  But that's not how a pseudo (virtual) device like /dev/null is
populated.

Unfortunately, that's where my knowledge of the system (based on my
years in PSARC) ends.  I don't know how to repair damage like you're
describing.  I just know that the people telling you to "rm" these fake
files or run mknod are misinformed.  That'll never work.

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>