A /usr partition and mountfs script issue
dagmar.wants at nospam.com
Mon Jan 26 18:03:30 PST 2004
On Mon, 2004-01-26 at 08:58, Bill's LFS Login wrote:
> On Sun, 25 Jan 2004, Dagmar d'Surreal wrote:
> > On Sat, 2004-01-24 at 18:43, Greg Schafer wrote:
> > > On Fri, Jan 23, 2004 at 11:15:37PM -0600, Dagmar d'Surreal wrote:
> > > > Is anyone planning on adding hotplugd to LFS 5.1?
> > >
> > > Not that I know of.
> > >
> > > > I think I might
> > > > actually have a functional case for adding it to LFS and not BLFS. USB
> > > > keyboard loves to keep numlock on by default, which breaks 9 of the
> > > > qwerty keys from the default map when you have a tiny USB keyboard like
> > > > the Zippy. (Hey, at night in my room anything important lights up,
> > > > including the keyboard.) Considering the ubiquity of USB nowadays, it
> > > > and might well be advisable to add into the book, simply because of the
> > > > awesome functionality provided by the package.
> > >
> > > Sorry, but this has BLFS written all over it. Or maybe even a hint if it's
> > > semi-complicated (as a precursor to getting it into BLFS). It may be become
> > > important enough one day to warrant direct LFS inclusion but not now IMHO.
> I don't know the technical considerations, but I would look at it this
> way. For KVM issues, can LFS get *basic* operation without adding more
> functionality? Will it allow the user to continue to BLFS (I ignore issues of
> convenience and even all "correct" operation here). If so, then I would
> see a lot of resistance to adding to LFS for these things. That's based
> on the expressed desire (in many areas) to avoid "unnecessary" packages
> (nasm for Lilo comes to mind).
Oh that much seems perfectly reasonable to me--but with the upcoming
kernel 2.6.x using hotplugging (so it's almost certainly going to be
added eventually), and with it so thoroughly eliminating the messages to
the support lists about ethernet cards not working (usu. because they're
loading the wrong module) it seemed like it was a pretty good
> > So LFS isn't scoped to own module loading? Seriously, tho'. The
> *chuckle* Yep. I don't always agree with that, but past behvior
> indicates that LFS wants to avoid it wherever possible.
> > <snip good reasons to include hotplugd>
> > The problem with USB keyboards is a bit more pressing because without
> > formally loading all the modules, the keymap stays fairly broken when
> > the numlock defaults to on for a terminal... you can't actually turn it
> > off without the keymap being fixed.
> With usb KM becoming more common, this would justify LFS inclusion *if*
> it can't be adequately addressed in the book. I presume it is not a
> major issue as I don't recall seeing a lot of help requests and there
> *must* be beau coup usb configs using LFS. I do recall some requests and
> an extensive discussion of hotplug and related.
Offhand I'd chalk that up to the apparent fact that if one can wade
through LFS and do all is asks, then strolling over to the Linux-USB
project and doing the few things it asks is a 5 minute job that can't be
mucked up. USB keyboards are (normally, when one has a full-sized
keyboard) handled silently by the kernel once the proper modules are
loaded, with the input from the USB keyboard being stealthily injected
into the "normal" input stream. A problem arises with mini keyboards
that have no separate numpad, since when numlock defaults to on
(Mandrake is driving me nuts with this, BTW) the u, i, o, j, k, l, m,
and etc keys wind up in number-pad mode, and most systems have no r66t
or r^[C^[Ct account. ;)
The email address above is phony because the people making archives of list
traffic publicly available on the web aren't taking measures to protect the
email addresses from filthy spammers.
AIM: evilDagmar Jabber: evilDagmar at jabber.org
More information about the lfs-dev