Ruminations on Udev, null and console

alupu at verizon.net alupu at verizon.net
Tue Mar 1 13:01:53 PST 2011


Bruce Dubbs wrote:
 
> When I rebooted, I got the following messages:
> cannot open /dev/null
>  ...
> FATAL: Module LNXSYTEM: not found
>  ...
> When I added null back to /lib/udev/devices/ and reenabled
> the copy in the bootscripts, I got none of these messages.
>  ...

> I don't have any modules to load.  No console to update either.
> I agree that the /dev/null entries in mountkernfs could be removed
> by using the -q option for mountpoint.
> I suspect that option was added after the bootscript was written.

> Actually, on my system, those errors appeared to come up before any 
> bootscripts were started.  They came about 4 seconds into the boot.
> It takes about 8 or 9 seconds to get to the boot prompt.

> I think those 'module' errors are being generated by drivers built into 
> the kernel.  Note that LNXSYTEM is an ACPI device.

> Since the instruction to copy null to /dev occurs after the error 
> message, I have no idea why they are coming up.

Hi Bruce,

1.  One thing at a time.
To RE-recap the conclusions about null/console situation
from my OP and the "time-line" post:

1.1. The "null" and "console" nodes MUST exist in the "metal" /dev
directory before start-up.

1.2 If one follows the LFS script order, the null/console coverage
is practically perfect.  No gaps.

1.2.1. The "metal" null disappears after the line
 if ! mountpoint /dev
while heroically taking the last direct hit:
 > /dev/null

1.2.2. "null" reappears (practically reborn), through some mysterious
machinations (more about that later) while still in "udev" (time-line,
sections 5-7), which makes it impossible to be missed by anybody else:

The "udev" script, what with 'udevadm settle' and all, makes sure that
unless and until it is done, no other script, program, bash construct,
etc. can start and potentially miss "null".

A corollary of this whole 1.2. is that no scripts ahead of "udev"
can fail, be it the much maligned (by me) "rc", or the others,
even in their original form (without the "-q", _with_ ">/dev/null").
In other words, "null" (here, in the "metal" avatar) will always
be there, for example to gracefully absorb any blows of the form
 "... > /dev/null".

2.  I wish I could help/explain your problem(s) including your
suspicion that the "udev" null copy (or rather the lack of it)
has something to do with the errors.
I've been wrong before (so many times!).

In the beginning of my tests/ruminations, as I mentioned, I made
sure I use copies of the latest scripts in their exact sequence:

>>> LFS book: Version SVN-20110218
>>> Script activation order in '... rcsysinit.d/':
>>>   mountkernfs
>>>   consolelog
>>>   modules (no modules to install, in my case)
>>>   udev
>>>   ...

Note:  I always boot to INIT level 3.  (id:3:initdefault:)
       That may matter.

If you find any similarities, I'd be more than willing to compare
notes on this subject.
It's definitely an intriguing project.

3. As a general comment, we are all aware that Udev has been a
moving target, ever since its inception.  No problem with that.
It's just that you have to aim more carefully, but there's the
risk of being hit right in the face when you become complacent
and not continuously on the ball.

My parents always told me to be careful with people who say
'if SoAndSo=="?*" then ...' instead of 'if SoAndSo!="" then ...',
which _is_ the the same thing, true, but shows those people might
not talk straight.

3.1.  I have NO idea how all those devices (null, etc.) appear
in my main-line section 5, as if out of thin air.

Does udevd take a peak in my forgotten directory '/lib/udev/devices'
(we _know_ Udev _knows_ about '/lib/udev/', for the rules)?
Does it have its own internal rules?

On a personal level, this is to me the last missing piece of my
otherwise pretty airtight (I think) coverage of Udev activities
on _my_ system and _my_ hardware.
I'll be away from the test machine for a couple of days.
As soon as I'm back, you can be sure I'll start looking hard into
this quandary and the copy implications.

By way of an example, if you do
   'strings udevd | egrep "console|null"'
you get only
<<
/dev/null
cannot open /dev/null
open /dev/null failed: %m
>>
and no "console", although the "console" node is there (in Sec. 5).

Nor if you grep for "console" among the rules.

Best regards,
-- Alex



More information about the lfs-support mailing list