Kernel page, once again

Jeremy Utley jeremy at
Wed Jun 16 02:18:03 PDT 2004

On Wed, 2004-06-16 at 00:32, Alexander E. Patrakov wrote:
> Jeremy Utley wrote:
> > The problem I see is, instead of constructive suggestions as to how to 
> > fix the problem, you are wanting to just take them out.  If we did that 
> > every time we have problems, we'd have never gotten past LFS 4.0 and the 
> > NSS libs issues.  A lot of the confusion with the recent questions is 
> > because the OP was posting to the incorrect list for his question 
> :)
> > (BLFS-Support instead of LFS-Hackers), and many people didn't realize 
> > that the OP was on a udev-driven system, and therefore were giving 
> > suggestions that would NOT work in that enviornment.  I think the 
> > community needs to come together and try to work these issues out, not 
> > go running away from bringing the book forward to where it should be.
> Very true, but I want to add some words.
> We cannot work these issues out if only two or three editors (known: 
> Jeremy Utley and myself) actually use udev+hotplug+modules, and the 
> others just read white papers, README files, ads, ask "what's the 
> problem", and continue using static /dev.

Judging from the reponse we got with the initial development of BE-LFS,
there's a LOT of people who are using unstable.  Unfortunately, none of
those people are here on LFS-Dev lending their experiences (good or
bad).  So we have the precious few of us who have been experimenting
with it, trying to bring along the people that for whatever reason, are
afraid of doing so.

Just for the record, here are the "gotcha's" I have found working with
my 2.6/udev/hotplug systems:

1) Stock Nvidia drivers do not register themselves in sysfs - 2
different work-arounds are available - either by using Nathan and Zack's
/etc/sysconfig/createfiles to create /dev/nvidia0 and /dev/nvidiactl, or
alternately by using a patch to the nvidia drivers that causes them to
register with sysfs (Roel Neefs is using this method successfully

2) Same situation with VMWare kernel modules - again, using createfiles
is an acceptable short-term solution to this where it's necessary

3) Alsa's OSS compatibility modules do not autoload.  Fixed with a
one-line addition to /etc/modprobe.conf as already outlined by Alexander
- personally, I consider this a bad thing, because given the current
state of linux software, I don't see why anyone would really want to use
ALSA without OSS compatibility, but that's IMHO.

4) Some older hardware such as old ISA stuff doesn't auto-load.  The fix
for this is to just manually load the driver if needed.  At some point,
we'll probably have to implement a bootscript that loads kernel modules
at boot, or trust that our users are intelligent enough to use the
modprobe command themselves.

> {ad}
> If you don't want to poison your known-good host system, build in chroot 
> and then transfer the image into qemu (free but slow) or vmware 
> (expensive and fast, but don't use 4.5.x versions because of bugs).
> {/ad}

I agree with Alexander 100%.  I get the feeling that most of the people
who are so against this modernization of LFS are people who haven't even
TRIED the stuff yet.  So, they're essentially passing judgement on
something they really know nothing about as of yet.


More information about the lfs-dev mailing list