On removing hotplug from LFS

Bryan Kadzban bryan at kadzban.is-a-geek.net
Thu Oct 13 15:04:16 PDT 2005

Alexander E. Patrakov wrote:
> We do need the new "blacklist" keyword, in order to emulate the old 
> "hotplug blacklist" functionality. It is a different question whether
> LFS targets only "single-machine" installations (where blacklists are
> never useful) or also allows to tar up LFS and untar it on a different
> computer.

You've already commented that this isn't 100% accurate (because of the
livecd), but I'd like to add a case where a single-machine installation
*does* require support for a blacklist.

My machine uses an nvidia-chipset 3D card.  I therefore have their
(binary only) driver kernel module installed.  This module has a device
table in it, so current LFS coldplug based module-loading *does* load
the driver at boot time.  (It gets added to modules.pcimap, and "modinfo
nvidia" shows an alias to "pci:v000010DEd*sv*sd*bc03sc00i00*".)

But I don't want the module loaded automatically at boot time.  Most of
the time, my machine boots up only to record some video off my TV card,
then sits doing very little for most of the day (until I come home from
work and startx).  I was seeing a few kernel oopses while doing heavy FS
activity during this recording, so I blacklisted the nvidia driver to
get it to stop auto-loading, so I could see whether the oopses continued.

(They did, BTW.  I think the culprit may have been a race condition in
the ext3 driver, because a later kernel update has cut down on the
oopses dramatically.  But I still want the nvidia driver blacklisted,
because it might still cause other issues.)

Yes, this means I have to manually load one module before I startx.  But
that was a small price to pay for removing non-open-source code from my
kernel at the time the oopses were happening.

So in general: A case where a single-machine installation requires
blacklist support would be where the machine's admin specifically wants
hotplug (or whatever) to ignore a certain module, so the admin can load
it manually only when it's needed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20051013/38ba824f/attachment.sig>

More information about the lfs-dev mailing list