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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
