Ruminations on Udev, null and console

alupu at verizon.net alupu at verizon.net
Mon Mar 7 07:03:05 PST 2011


As promised, I ran a number of tests to clarify Udev
interaction with '/lib/udev/devices/' and the creation
of some essential nodes during a boot-up.

PRELIMINARIES

A.  [/sbin]$ strings udevd | grep devices
       /lib/udev/devices
       /devices/

So, 'udevd' is aware of '/lib/udev/devices/' directory and,
as we will see later, has a keen interest in its contents.

B.  Excerpt of '/etc/rc.d/init.d/udev' script used 
during the tests.
I inserted six "Sample" lines in the original script
(their position in the "udev" script code is shown
preceded by a "+++" string, so as to stand out.

<<
    start)
+++ "/dev" content Sample No 1.
        boot_mesg "Populating /dev with device nodes..."
        ...
        if ! mountpoint /dev > /dev/null; then
            mount -n -t tmpfs tmpfs /dev -o mode=755
        ...
+++ "/dev" content Sample No 2.
        ...
        echo > /proc/sys/kernel/hotplug
 
+++ "/dev" content Sample No 3.
        ...
####    cp -a /lib/udev/devices/null /dev
        ...
        /sbin/udevd --daemon
+++ "/dev" content Sample No 4.
        ...
        /sbin/udevadm trigger --action=add
+++ "/dev" content Sample No 5.
        ...
        /sbin/udevadm settle
        evaluate_retval
+++ "/dev" content Sample No 6.
        ;;
>>

C.  The "cp -a ...null /dev" line above was commented out
at all times.  Actually, nothing ever changed in B.

D.  In Sample No 1. (i.e., the "metal" /dev) the 'null'
node is always the same.  Example (shown here in full),

crw-rw-rw- 1 root root 1, 3 2011-02-23 06:28:02.000000000 null
crw--w--w- 1 root root 5, 1 2011-03-04 13:14:57.000000000 console

Consequently, Sample No 1. will not be covered further.

Note:  As already mentioned, I think 'console' is handled by
the kernel itself (somehow).
BTW, unlike 'null', the 'console' time and date always change.

E. The Samples have been edited for conciseness, so
only the node time is shown in what follows (i.e., no type,
permissions, ownership, or major/minor numbers).

F.  System
 (B)LFS i686-pc-linux-gnu, 2.6.37.1, Udev-166
 LFS book: Version SVN-20110218
 Script activation order in '... rcsysinit.d/':
   mountkernfs
   consolelog
   modules (no modules to install, in my case)
   udev
   ...

 FWIW, an excerpt of my 'fstab':
  devpts  /dev/pts devpts  gid=4,mode=620  0  0
  shm     /dev/shm tmpfs   defaults        0  0

 Obviously, other people's mileage may vary.

TEST RESULTS ============================

>>>> Test No 1. >>>>>>>>>>>>>>>>>>>>>>

Missing (no) '/lib/udev/devices/' directory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Excerpt from console log:

Remounting root file system in read-write mode...  [  OK  ]
Recording existing mounts in /etc/mtab...                [  OK  ]
Mounting remaining file systems...
mount: mount point /dev/pts does not exist
mount: mount point /dev/shm does not exist           [ FAIL ]

------
'null' and 'console' presence:

'null':
Sample No 5.:  2011-03-04 13:14:57.413999850
Sample No 6.:  2011-03-04 13:14:57.413999850

'console':
Sample No 5.:  2011-03-04 13:14:57.416999850
Sample No 6.:  2011-03-04 13:14:57.416999850

>>>> Test No 2. >>>>>>>>>>>>>>>>>>>>>>

'/lib/udev/devices/' with 'pts', 'shm' and 'null  (no console)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

NO console log problems.

-------
'null' and 'console' presence:

'null':
Sample No 4.:  2011-03-04 13:45:14.343999850
Sample No 5.:  2011-03-04 13:45:14.417999850
Sample No 6.:  2011-03-04 13:45:14.417999850

'console':
Sample No 6.:  2011-03-04 13:45:14.431999850

Note:  In '/lib/udev/devices/', 'pts' and 'shm'
 directories are empty.

>>>> Test No 3. >>>>>>>>>>>>>>>>>>>>>>

'/lib/udev/devices/' with 'pts', 'shm' and 'console'  (no null)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Excerpt from console log:

Populating /dev with device nodes...
cannot open /dev/null
udevd[513]: cannot open /dev/null

udevd-work[518]: open /dev/null failed: No such file or directory
 ...
 same for udevd-work[537],
  [538],[539],[540],[542],[545],[550],[575],[578],[588] and [605]
 ...
FATAL: Module acpi:LNXSYSTM: not found.
FATAL: Module pci:v00008086d00002983sv... not found.
FATAL: Module pci:v00008086d00002930sv... not found.
FATAL: Module pci:v00008086d00002940sv... not found.
FATAL: Module pci:v00008086d0000244Esv... not found.
insmod /lib/modules/2.6.37.1/kernel/drivers/char/agp/agpgart.ko
Linux agpgart interface v0.103
insmod /lib/modules/2.6.37.1/kernel/drivers/char/agp/intel-gtt.ko
insmod /lib/modules/2.6.37.1/kernel/drivers/char/agp/intel-agp.ko
agpgart-intel 0000:00:00.0: Intel G35 Chipset
agpgart-intel 0000:00:00.0: detected gtt size: 524288K total, ...

Notes:
 our mutual friend, LNXSYSTM, is being sorely missed here :).

 lines like "insmod ... driver.ko", out in the open, look
a little unusual to me, but what do I know ...
------

'null' and 'console' presence:

Sample No 4:   2011-03-05 06:51:01.344999850 console

Sample No 5:   2011-03-05 06:51:01.405999850 console

Sample No 6:   2011-03-05 06:51:01.417999850 null
               2011-03-05 06:51:01.420999850 console

Note:  'null' makes its re-entrance after all
 (a little tardy, though).
------

>>>> Test No 4. >>>>>>>>>>>>>>>>>>>>>>

'/lib/udev/devices/' with only 'pts' 'shm' (no null, no console)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Excerpt from console log:

Populating /dev with device nodes...
cannot open /dev/null
FATAL: Module pci:v00008086d00002983sv... not found.
FATAL: Module pci:v00008086d00002930sv... not found.
FATAL: Module acpi:LNXSYSTM: not found.
FATAL: Module pci:v00008086d00002940sv... not found.
FATAL: Module pci:v00008086d0000244Esv... not found.

-------
'null' and 'console' presence:

'null':
Sample No 6.:  2011-03-04 13:31:48.447999850

'console':
Sample No 6.:  2011-03-04 13:31:48.448999850

>>>> Test No 5. >>>>>>>>>>>>>>>>>>>>>>

'/lib/udev/devices/' in existence but empty.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Excerpt from console log:

Populating /dev with device nodes...
cannot open /dev/null
udevd-work[630]: open /dev/null failed: No such file or directory
 ...
Real Time Clock Driver v1.12b
FATAL: Module acpi:LNXSYSTM: not found.
FATAL: Module pci:v00008086d00002983sv... not found.
FATAL: Module pci:v00008086d0000244Esv... not found.
FATAL: Module pci:v00008086d00002930sv... not found.
FATAL: Module pci:v00008086d00002940sv... not found.
insmod /lib/modules/2.6.37.1/kernel/drivers/char/agp/agpgart.ko
 ...
Mounting remaining file systems...
mount: mount point /dev/pts does not exist
mount: mount point /dev/shm does not exist    [ FAIL ]
Retrying failed uevents, if any...                       [  OK  ]

------

Sample No 4:
2011-03-05 06:27:52.324999850  stdout -> /proc/self/fd/1
2011-03-05 06:27:52.324999850  stdin -> /proc/self/fd/0
2011-03-05 06:27:52.324999850  stderr -> /proc/self/fd/2
2011-03-05 06:27:52.387999850  kmsg
2011-03-05 06:27:52.324999850  fd -> /proc/self/fd
2011-03-05 06:27:52.324999850  core -> /proc/kcore

Notice the absence of 'null' and 'console'

------
'null' and 'console' presence:

Sample No 6 only (no 'null' or 'console' in Sample No 5 either):
2011-03-05 06:27:52.439999850 null
2011-03-05 06:27:52.440999850 console

>>>> Test No 6. (Das grosse Finale) >>>>>>>>>>>>>>>>>>>>>>

'/lib/udev/devices/' with its full complement of nodes, dirs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(i.e., the normal situation)

For completeness:
[/lib/udev/devices]$ ls -l 
crw--w--w- 1 root root 5, 1 2011-02-25 17:09 console
crw-rw-rw- 1 root root 1, 3 2011-02-22 12:18 null
drwxr-xr-x 2 root root 4096 2010-05-31 20:04 pts
drwxr-xr-x 2 root root 4096 2010-05-31 20:04 shm
------

Everything clean (finally).  NO console log problems.
Nor in dmesg, sys.log or kern.log
(i.e., no muss, no fuss :).

------
'null' and 'console' presence:

'null':
Sample No 4.:  2011-03-04 14:05:19.362999850
Sample No 5.:  2011-03-04 14:05:19.362999850
Sample No 6.:  2011-03-04 14:05:19.457999850

'console':
Sample No 4.:  2011-03-04 14:05:19.362999850
Sample No 5.:  2011-03-04 14:05:19.362999850
Sample No 6.:  2011-03-04 14:05:19.459999850

------

As a reminder, all the "basic" nodes are created at
Sample No 4 time (shown below with all its nodes,
during a different reboot): 

2011-03-04 15:57:28.335999850  stdout -> /proc/self/fd/1
2011-03-04 15:57:28.335999850  stdin -> /proc/self/fd/0
2011-03-04 15:57:28.335999850  stderr -> /proc/self/fd/2
2011-03-04 15:57:28.364999850  shm
2011-03-04 15:57:28.363999850  pts
2011-03-04 15:57:28.364999850  null
2011-03-04 15:57:28.417999850  kmsg
2011-03-04 15:57:28.335999850  fd -> /proc/self/fd
2011-03-04 15:57:28.335999850  core -> /proc/kcore
2011-03-04 15:57:28.364999850  console

Note:  I included 'console' in '/lib/udev/devices'
for completeness.  As can be seen in Test No 2., and
after relatively extensive tests, I haven't noticed
any ill effects due to the missing 'console'.
It's just that 'console' is created "late" in Sample No 6
in Test No 2.  Whatever that means.  In short, 'console'
can go from '/lib/udev/devices/' (which I assume is the
present LFS thinking, anyway).

Moral of the story:  you DO need a 'null' node in
`/lib/udev/devices/' but NOT the "udev" script copy
(which is redundant and misleading).

==========================================

CONCLUSIONS

Udev doesn't expect the user to perform any node copies.
However, it does expect a fully and properly populated
'/lib/udev/devices/' directory.
It does its node creation magic ('null', etc.) all by itself.

Note:  some old record of '/lib/udev/devices/' content:

   Jun 25  2009 core -> /proc/kcore
   Jun 25  2009 fd -> /proc/self/fd
   Jun  6  2008 kmsg
   Jun  6  2008 null
   Jul 12  2007 pts
   Jul 12  2007 shm
   Jun 25  2009 stderr -> /proc/self/fd/2
   Jun 25  2009 stdin -> /proc/self/fd/0
   Jun 25  2009 stdout -> /proc/self/fd/1

------

I suppose user independence has been one of the goals of Udev
all along.

I think the Udev "paradigm" above (user, you just make sure
there's a nice '/lib/udev/devices/' on your system and I'll
take care of the rest) has been in place for a while (i.e.,
since well before 166 - maybe, post 156? ).
It may change in the future, though.
Like I said, you just have to be on your toes at all times.

-- Alex



More information about the lfs-support mailing list