interesting times installing 2.4.17 in Woody...
Joey Hess
> I'm new to Debian; an old fart in UNIX and X, and using RH and Mandrake
> the last few years...
Hi Jim, we've met breifly before (you won't remember my name), and I
think I've seen you kicking around the compaq play area at linuxworld,
though my memory of your face is not 100%. Anyway, if you are there, I'd
love to chat about Debian sometime tomorrow, you should drop by the
Debian booth.
> So I got the basic install done, and loaded a pile of packages (I'd kept
> a list of what I'd likely need from my previous install). Modulo the fact
> that the tasks are broken in tasksel, per previous discussion
I must have missed that discussion. I hope this is being resolved? There
were some issues with tasksel not installing a window manager and xterm but
I fixed this in my last upload.
> o My wireless card didn't work. Memory on previous 2.4 installs warned
> me about the transition to the ornioco driver, but of course, details
> are not in my cache. With alot of wandering around, figuring out the
> changes required to /etc/pcmcia/config for the orinoco was solved,
> along with the change needed to get the system to DHCP on the card.
>
> o The really obscure problem I could not have solved easily without
> Keith Packard's help was the need for the file /etc/default/pcmcia,
> with the line PCIC=yenta_socket.
This is all related to the mess of the pcmcia-cs modules vs the kernel
modules. I don't think we can ship a pcmcia/config that works for both
since they use different names for the orinoco driver (argh!). It's very
hard to try to keep that file synced with whatever kernel the user has
booted at the time, too. Maybe this is fixable by throwing some module
symlinks into one or the other package.
I wasn't aware that the standard debian 2.4 kernel includes the kernel
pcmcia modules; if it does this surely needs to be dealt with since you
have a point about thing being a common upgrade path.
And the yenta_socket thing is just completly undocumented, isn't it? It
suffers from a lot of the same problems as pcmcia/config, and I don't see
an easy way out here. However, perhaps we could make the pcmcia init script
DTRT depending on which pcmcia modules were being used? Any thoughts,
Brian?
--
see shy jo
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Brian Mays
> > o My wireless card didn't work. Memory on previous 2.4 installs
> > warned me about the transition to the ornioco driver, but of course,
> > details are not in my cache. With alot of wandering around,
> > figuring out the changes required to /etc/pcmcia/config for the
> > orinoco was solved, along with the change needed to get the system
> > to DHCP on the card.
> >
> > o The really obscure problem I could not have solved easily without
> > Keith Packard's help was the need for the file /etc/default/pcmcia,
> > with the line PCIC=yenta_socket.
Joey Hess <jo...@kitenet.net> wrote:
> This is all related to the mess of the pcmcia-cs modules vs the kernel
> modules. I don't think we can ship a pcmcia/config that works for both
> since they use different names for the orinoco driver (argh!). It's
> very hard to try to keep that file synced with whatever kernel the
> user has booted at the time, too. Maybe this is fixable by throwing
> some module symlinks into one or the other package.
>
> I wasn't aware that the standard debian 2.4 kernel includes the kernel
> pcmcia modules; if it does this surely needs to be dealt with since
> you have a point about thing being a common upgrade path.
>
> And the yenta_socket thing is just completly undocumented, isn't
> it? It suffers from a lot of the same problems as pcmcia/config, and
> I don't see an easy way out here. However, perhaps we could make the
> pcmcia init script DTRT depending on which pcmcia modules were being
> used? Any thoughts, Brian?
Strangely enough, your message has excellent timing, since I am
currently in the building and testing process for the next version
of the pcmcia packages, which (I hope) will solve this problem. My
solution is as follows. I would appreciate any feedback.
This solution requires a couple of hacks to the pcmcia-cs software.
First, the probe utility is modified to report that the "yenta_socket"
module should be used for the CardBus chips (ISA-to-PCMCIA bridges
will still be correctly reported as using "i82365"). This means that
new installations should correctly have PCIC=yenta_socket set in
/etc/default/pcmcia. To handle upgrades from older packages, I have
added an option during the upgrade (using debconf) to have the postinst
script automatically fix the PCIC entry in the /etc/default/pcmcia file.
Of course, the stand-alone drivers (in the pcmcia-modules packages)
don't have a yenta_socket module. Therefore, I have added an additional
file in /etc/default to the pcmcia-modules packages that is sourced (if
it exists) by /etc/init.d/pcmcia and changes PCIC from "yenta_socket" to
"i82365", which is appropriate for the stand-alone drivers.
Next, I have made the appropriate changes to the /etc/pcmcia/config file
to support the kernel drivers. An additional workaround was required to
also support the stand-alone drivers. Therefore, I modified the cardmgr
program to support the following construct in its config file:
source ./config-`uname -r`.fix
In this way, I can include an additional config file, named
config-xxx.fix, in each pcmcia-modules-xxx package, which remaps the
some of the binding to the stand-alone drivers.
Thus, everything should be done automatically. If the pcmcia-modules
package has not been installed, the pcmcia-cs package is configured
to use the kernel drivers. If the pcmcia-modules package has been
installed, then the configuration of pcmcia-cs is changed to use the
stand-alone drivers.
- Brian
P.S. The problems caused by the PCMCIA drivers in the 2.4 kernel are
documented. A summary of the problems caused by these drivers is in
/usr/share/doc/pcmcia-cs/README-2.4.gz.
Joey Hess
> o someone, somewhere along the line installed gpm on me: this caused
> various trouble in my X hacking along the way.
>
> In general, gpm should *NOT* be the default (if you install an X desktop,
> anyway, which can be used as a signal you aren't likely to want cut and
> paste on the consoles). It only makes interactive behavior of the system
> worse by interposing a user process.
Jim's convinced me that gpm should not be in standard, the benefits of
not having the repeater going are woth it for all the people who want a
desktop, and it's easy enough to install gpm if you need it. Another
task could also continue to pull it in. Anyway, of all the potato
installs (which all lacked gpm by default), I only got three or four
comments from people who would have preferred it install gpm, and the
potential improvement outweighs that.
--
see shy jo
Michael Stone
> task could also continue to pull it in. Anyway, of all the potato
> installs (which all lacked gpm by default), I only got three or four
Huh? I always had to manually remove gpm when I installed potato.
--
Mike Stone
Zephaniah E. Hull
> > o someone, somewhere along the line installed gpm on me: this caused
> > various trouble in my X hacking along the way.
> >
> > In general, gpm should *NOT* be the default (if you install an X desktop,
> > anyway, which can be used as a signal you aren't likely to want cut and
> > paste on the consoles). It only makes interactive behavior of the system
> > worse by interposing a user process.
>
> Jim's convinced me that gpm should not be in standard, the benefits of
> not having the repeater going are woth it for all the people who want a
> desktop, and it's easy enough to install gpm if you need it. Another
> installs (which all lacked gpm by default), I only got three or four
> potential improvement outweighs that.
I've been on the edge of putting it in optional for a while now, if the
general consensus is that it should not be standard then my next upload
(which should fix the current big bugs, though they are VERY much kernel
bugs as well.).
Zephaniah E. Hull.
(gpm maintainer.)
>
> --
> see shy jo
--
1024D/E65A7801 Zephaniah E. Hull <wa...@babylon.d2dc.net>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.
"Microsoft is a cross between the Borg and the Ferengi. Unfortunately,
they use Borg to do their marketing and Ferengi to do their
programming."
-- Simon Slavin in asr
Brian Mays
> > Of course, the stand-alone drivers (in the pcmcia-modules packages)
> > don't have a yenta_socket module. Therefore, I have added an
> > additional file in /etc/default to the pcmcia-modules packages
> > that is sourced (if it exists) by /etc/init.d/pcmcia and changes
> > PCIC from "yenta_socket" to "i82365", which is appropriate for the
> > stand-alone drivers.
To this, Joey Hess <jo...@debian.org> asked:
> Does this support the case where the user has 2.2 and 2.4 kernels
> installed, boots back and forth between them, and wants pcmcia to
> continue to work either way?
Yes. This is why everything is tied to the kernel version number. For
the 2.2 kernel, a pcmcia-modules package must be installed (there are no
kernel drivers in 2.2). Therefore, the config-2.2.x.fix file will be
present to correctly configure cardmgr. For the 2.4 kernel, the
pcmcia-modules package is optional. If it is absent, the standard
/etc/pcmcia/config file will work with the kernel drivers (note that the
config-2.2.x.fix file will not be sourced when a 2.4 kernel is running);
if it is present, then a config-2.4.x.fix file will be present to tell
cardmgr to use the stand-alone modules instead. This scheme also works
when different subversions of the 2.4 kernel (say, 2.4.16 and 2.4.17)
are being used.
The only problem that remains is that modprobe prefers to load the
modules in the kernel/drivers/pcmcia subdirectory *before* any modules
in the pcmcia subdirectory. Herbert Xu and I have discussed this, and
we decided to move the kernel drivers out of kernel/drivers/pcmcia.
This problem occurs because it is not possible to *prepend* directories
to module paths. Another possibility would be to hack our version of
modprobe, etc. to search the pcmcia subdirectory before the kernel
subdirectory when searching for modules.
- Brian
Jim Gettys
me down a path into configuration hell. I don't fully understand what
went wrong, but I did not have a functional X server after the install.
Once in configuration hell, many/most of the problems I had were not
Debian specific, but really botches
in XFree86 and/or XFree86 device drivers. As I have ways of twisting
XFree86 developer's arms, I intend to follow up further. I figure if I have
(major) trouble, gawd forbid this happen to some Linux newbie.
For example, there exists code in the TinyX server that automagically
detects what flavor mouse you have, which, if moved into the
main XFree86 server would prevent many installation configuration
problems in the mouse area, and I'll twist Keith Packard's arm to do it
(though a volunteer to do it would also be welcome and it could happen faster that way; I'm unwilling to twist hard until Keith's finished with his Xft
rewrite).
- Jim
--
Jim Gettys
Cambridge Research Laboratory
Compaq Computer Corporation
j...@pa.dec.com