> Feb 25, 2011 04:26:29 AM, Simon Geard wrote:
> On Wed, 2011-02-23 at 12:24 -0600, [email protected] 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:
<< SYSTEM
(B)LFS i686-pc-linux-gnu, 2.6.37.1, 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/':
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
...
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
AND
# 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.
Thanks,
-- 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
BLFS ?
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
