Ruminations on Udev, null and console

alupu at verizon.net alupu at verizon.net
Mon Feb 28 18:50:42 PST 2011


SYSTEM
~~~~~~
 "ASUS P5E-VM HDMI" with Intel G35/ICH9R.
 Intel Core2 Duo CPU E8400 @ 3.00GHz, 4GB
 (B)LFS i686-pc-linux-gnu, 2.6.37.1, Udev-166

PROBLEM
~~~~~~~
No problems.  I'm just trying to recap and maybe bring
this thread to a merciful end.
In the following, I'm trying to present a time-line on
my system showing the "console" and "null" activities.
(i.e., back to the OP, but hopefully in a cleaner, logical
fashion.:)
So I ran a boot-up test with a few strategically placed
time stamps in "setclock", "moutkernfs" and "udev" scripts,
a summary of the results shown below.
The text can also serve as preparatory course for beginning
students in 101 Udev :).  Prerequisites: /sys and tmpfs.

NOTES
~~~~~
No 'cp -a /lib/udev/devices/ ...' _whatsoever_ in "udev" script.
The dates/times are shown in sequence (when applicable).
The times are node/file _modification_ time.  The creation and/or
access times would just clutter up the text without bringing
anything interesting to the table (IMHO).

TIME STAMPS
~~~~~~~~~~~
1. "metal" /dev:

2011-02-22 13:26:28.000000000 +0000 console
2011-02-23 11:28:02.000000000 +0000 null

2. Machine booting up.

At start of "mountkernfs" (before the /proc and /sys mounts):

2011-02-28 14:43:58.000000000 -0500 console
2011-02-23 06:28:02.000000000 -0500 null

3. "udev" script (before 'mount ... tmpfs /dev ...'):

2011-02-28 14:43:58.000000000 -0500 console
2011-02-23 06:28:02.000000000 -0500 null

4. "udev" (after 'mount ... tmpfs /dev ...'):

Nothing.  The two "metal" /dev nodes are hidden now.

5. "udev" (after '/sbin/udevd --daemon').  All existing /dev nodes:

2011-02-28 14:43:58.285999850 -0500 stdout -> /proc/self/fd/1
2011-02-28 14:43:58.285999850 -0500 stdin -> /proc/self/fd/0
2011-02-28 14:43:58.285999850 -0500 stderr -> /proc/self/fd/2
2011-02-28 14:43:58.295999850 -0500 shm
2011-02-28 14:43:58.295999850 -0500 pts
2011-02-28 14:43:58.295999850 -0500 null
2011-02-28 14:43:58.331999850 -0500 kmsg
2011-02-28 14:43:58.285999850 -0500 fd -> /proc/self/fd
2011-02-28 14:43:58.285999850 -0500 core -> /proc/kcore
2011-02-28 14:43:58.295999850 -0500 console

6. "udev" (after '/sbin/udevadm trigger --action=add')
Same as 5. above (i.e., no time changes, no new devices)

7. "udev" (after '/sbin/udevadm settle')
Note:  Practically most /dev nodes are now in place.
Only our important friends, "console" and "null", are shown:

2011-02-28 14:43:58.374999850 -0500 console
2011-02-28 14:43:58.375999850 -0500 null

8. For reference only:

8.1.  After "INIT: version 2.86 booting"
Before "mountkernfs":        2011-02-28 14:43:58.039068843

8.2.  "setclock", after
Setting system clock...      2011-02-28 19:44:01.000687543

8.3.  Just before the prompt
 (last line in "rc.local"):  2011-02-28 19:44:03.472291634

8.4.  Last reboot:           Mon Feb 28 19:44:01

FINAL WORDS
~~~~~~~~~~~

A.  Please notice that the date of "console" changes between
(1) and (2) above to boot date and time.
My only explanation (a little weak) is that happens when
the kernel creates the "console".

- Excerpt from console log:
 ...
NR_IRQS:320
Console: colour VGA+ 80x25
console [tty0] enabled
Fast TSC calibration using PIT
Detected 3005.093 MHz processor.
 ...

- This seems to be confirmed by 'sys.log' and 'kernel.log'
Feb 28 19:44:01 localhost kernel: NR_IRQS:320
Feb 28 19:44:01 localhost kernel: CPU 0 irqstacks, ...
Feb 28 19:44:01 localhost kernel: Console: colour VGA+ 80x25
Feb 28 19:44:01 localhost kernel: console [tty0] enabled
Feb 28 19:44:01 localhost kernel: hpet clockevent registered
Feb 28 19:44:01 localhost kernel: Fast TSC calibration using PIT
Feb 28 19:44:01 localhost kernel: Detected 3005.251 MHz processor.

B.  According to my tests, the "metal" console is needed.
Without it, for reasons unknown, there's no LFS console display
(NO boot_mesg() output, OK, etc) at boot.  After that, the 
display mysteriously becomes active.  Say,
/etc/rc.d/init.d/gpm restart
 Stopping gpm...      [  OK  ]
 Starting gpm...      [  OK  ]

This one I cannot explain, even weakly.  

C.  As nit-pickings (no urgency, we know how long it takes to change
"will" with "must" in the next (almost) daily revision of the book:)

C.1.  6.2.21 should say "must" instead of "will"

C.2.  The whole "Create some devices and directories ..." in
 "udev-1xx" should go.  Misleading, outdated and nonsensical.

C.3.  Instead, users should be urged to boot their /dev partition
for somewhere else (another partition, LiveCD) and make sure
they have these two, and preferably only these two nodes set up.

Thanks you all for your contributions,
-- Alex



More information about the lfs-support mailing list