Ruminations on Udev, null and console

alupu at alupu at
Tue Feb 22 16:44:24 PST 2011


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

 While my system has worked well for a long time,
 a few lines (actually, two commands) in the 'udev' script like
   # Mount a temporary file system over /dev, so that any devices
   # made or removed during this boot don't affect the next one.
   if ! mountpoint /dev > /dev/null; then
       mount -n -t tmpfs tmpfs /dev -o mode=755
 and later on
   # Copy the only static device node that Udev >= 155 doesn't
   # handle to /dev
   cp -a /lib/udev/devices/null /dev

 started to puzzle me more and more as time passed.

 The results of my reflections and relatively
 extensive testing are presented in the following SUBJECT.
 Of course, I can be totally or partially wrong
 in my conclusions (no surprise here:).
 However, maybe there's something for some of us to learn
 if a gentle, knowledgeable soul (or two) will take the time
 to look at my words and make some useful comments and/or
 straighten me out if need be.

1.  Based on the basic UDEV philosophy (and reiterated in
 the 'udev' script comments (above, the # lines)),
 /dev should be populated with only nodes for devices
 existing on or strictly needed by the particular system
 when active.
While not specifically stated, one can assume that before
 booting, the machine's "metal" /dev should be totally empty.
 By "metal" /dev, I mean the main '/dev' directory as it
 sits passively on the pure "metal", as seen from, say,
 a booted LiveCD.
 As an example, for my Linux system on /dev/sda3:
   mount ... /dev/sda3 /mnt
   ls -l /mnt/dev
 The output should show an empty '/mnt/dev' (again, if one
 reads the main Udev concept correctly).

 In this case the construct "> /dev/null" in the mount
 is wrong, especially as the second command confirms
 we do need a '/dev/null' node, not present as yet.
 (the smoking gun is a console message complaining that
  "... rcsysinit.d/S10udev: ... /dev/null: Read-only file system"
  More about "console" later)
 The irony here is that 'mountpoint' offers a "-q" option.       
2. "mountkernfs" script coming before "udev" in the boot
 sequence (_has_ to mount 'sys') has two offending lines
 with ">/dev/null".  Can be corrected with a "-q".

 A bigger problem is presented by "rc".
 "rc" is the first in line, so to speak, so it can get ugly.
 Has two "for" lines with "2> /dev/null".
 My system hangs, with two error lines around INIT:
  "... init.d/rc: ... /dev/null: Read-only file system"
 I deleted the two "2> /dev/null"'s, and damn the torpedoes.
 So far, I've lived to tell this story here.
3. However, two questions I agonized the most over:

3.1. How come, despite all these problems I found on my machine
 people reboot their systems day in and day out without any
 reported complaints?  If they had any grievances on this subject,
 they'd be out in the streets like anybody else these days.
 Am I the only confused fella here ?!

3.2. How come people are not missing the beautiful (and useful)
 console boot displays [boot_mesg() in "functions"] which, on
 my system would not appear unless my "metal" /dev contained
 the "console" node.

 A partial explanation, I said (to myself) would be the
 introduction of KMS on all "modern" Linux releases.
 We've already seen some of the benefits of this invention;
 the first section of the boot console log vanishes forever
 (with all the juicy stuff) at the point the KLM module is
 loaded (late), so if the machine comes up good, who cares!?
 (based on the old adage, what you don't see can't hurt you)
 Note:  "dmesg" and other logs do not show these pesky
  "Read-only file..." lines, and who in his right mind
   checks the "dmesg" on a good start-up anyway?.

 But how about the "rc" hangs, the console logs and the like?

 Here I think I finally came to the big, all-encompassing answer:)

 Unaware, many people still carry a lot of old stuff (including
 "console" and "null") on their "metal" /dev.
 So they don't see (even if they'd want to) those nasty messages.
 All the ">dev/null" errors are gone, the console log messages
 look as pretty as ever (in color too), etc.

 As I implied in the beginning, I also feel good and the reason
 for that is I set up my "metal" /dev with the good, old
  crw------- ... 5, 1 ... /dev/console 

 and also swallowed my pride and added a nice
  crw-rw-rw- ... 1, 3 ... /dev/null
 for good measure.

 Notes:  1. "cp ... console /dev" in 'udev' script doesn't work.
         (apparently, too late in the boot sequence.)

         2. For reasons unknown, even if I start with the
         "metal" /dev empty, I end up with both "null"
         and "console" nodes in /dev at the end of boot.
         Go figure.

 The Udev police may get me one day but in the meantime I can
 have my full, CLEAN console log _and_ still use the excellent
 scripts Mr. Beekmans and all the other collaborators worked
 hard to design for our use and enjoyment.  Thank you all.

-- Alex

More information about the lfs-support mailing list