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