Ruminations on Udev, null and console

alupu at alupu at
Fri Feb 25 11:21:54 PST 2011

> Feb 25, 2011 04:26:29 AM, Simon Geard wrote:

> On Wed, 2011-02-23 at 12:24 -0600, alupu at wrote:

>> BTW, there is a [rant][/rant] I'm skipping, although the idea
>> is not the first time to come up, where people "grow" from LFS
>> to BLFS and become confused and/or _misunderstood_ about "falling
>> behind" on the latest and greatest developments in LFS
>> (my LFS system was built early 2005).

> I'm guessing you don't run a 'modern' desktop then?
> It's pretty much impossible to build and run a modern
> Gnome desktop without using udev - mostly because udev
> these days isn't just about populating /dev nodes,
> it's also how you identify what hardware is present.

Hi Simon,

There's a very unfortunate misunderstanding here.  Maybe
in debating with Neil and Bruce lately on my thread
you forgot who started the thread, _why_ and how.
However, it may be mostly my fault here, what with my rambling and
incoherent style of mine;  whatever, I'll try my level best
to restate the situation as clearly as I can, and to avoid
redundancy, to use mostly cut-and-paste sections from my original
statements (made in my only _two_ posts).
Enclosed in double angle brackets.

1.  The _very first_ paragraph of my OP:

(B)LFS i686-pc-linux-gnu,, Udev-166
LFS book: Version SVN-20110218 >>

Does it look like I 
> don't run a 'modern' desktop?

It's for you to decide. :)

> without using udev?:

<<  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
started to puzzle me more and more as time passed
 ... >>

It's for you to decide :)

2.  _Strictly_ for the record and completeness:
I do no use Gnome.  Never have. 
I use KDE (3.5.10) and Fluxbox (1.1.1).
However, IMHO this is absolutely irrelevant as far as the thread
subject is concerned.
Unfortunately, the above admission might trigger another unrelated
debate :(  I'm resigned to it, though;  you win a few lose a few.

3. Now, for my main subject, restated and summarized differently,
in desperate hopes of making it clearer.

3.1.  Don't remember exactly what Udev I started with and when.
I came across some e-mails to Kay Sievers (of April, 2007):
" ...
 686-pc-linux-gnu (B)LFS 2.6.20
 UDEV upgrade from 105 (OK) to 108.
 ... "

I also don't remember if 6.2.21 was in the exact, clear form you
cited to me (excerpt here),

> When the kernel boots the system, it requires the presence of a
> few device nodes, in particular the console and null devices.
> The device nodes will be created on the hard disk so that they
> are available before udevd has been started, and additionally
> when Linux is started with init=/bin/bash. Create the devices by
> running the following commands:
>  ...

(while we're talking about clarity here, a little nitpick:
"will be created" should be replaced with "must be created")

It wouldn't matter anyway, because as I said
<< I had had those two nodes [on the "metal" /dev]
all along (instinctively) >>

<< I set up my "metal" /dev with ...
  crw------- ... 5, 1 ... /dev/console

 and also ...
  crw-rw-rw- ... 1, 3 ... /dev/null >>

3.2.  The PROBLEM (the actual object of the OP) has been

<< my worries started recently when _finally_ a [light] bulb went
  [off] in my head on reading

   # Create some devices and directories that Udev cannot handle
   # due to them being required very early in the boot process,
   # or by Udev itself:
      mknod -m0666 /lib/udev/devices/null c 1 3

 in the LFS udev-166 procedure


   # Copy the only static device node that Udev >= 155 doesn't
   # handle to /dev
       cp -a /lib/udev/devices/null /dev

 in the latest "udev" script. >>

In other words, the above two commands are in contradiction to 6.2.21
(as cited by you), and << redundant (and _misleading_) >>.
I.e., in yet some other words, the author(s) of the "udev" script and
"udev" installation procedure (this fallacy goes back quite a few
iterations from 166) should re-read 6.2.21 even harder than me.
In delicate terms, there should be a co-ordination somewhere.

<< So I ... started testing (and ruminating) hard. >>

3.3.  Speaking of co-ordination, and my
 << [rant][/rant] ... skipping >>
in a few words, it appears that for some reason, in some quarters
it can be incomprehensible the fact that one can simply "graduate"
from LFS to BLFS (_on the same system_, no less!) while being "forced"
to keep up with Udev, Kernel versions and latest scripts, and/or
"electing" to partake of some other goodies that LFS offers.

The post I'm responding to seems to be an example of that.

-- Alex

PS  Could it be I write (B)LFS and there's another shortcut more
accepted and better conveying the fact that I'm talking about a
system that started as LFS (in 2005, as I said) and << grew >> to

More information about the lfs-support mailing list