Re: segmentation fault with NVIDIA 32bit part
lee a wrote :
> On Tue, Oct 06, 2009 at 12:17:53AM +0200, thveillon.debian wrote:
>> lee a wrote:
>>> On Mon, Oct 05, 2009 at 07:41:47PM +0200, thveillon.debian wrote:
>>>
>>>>> cat:/home/lee# /emul/ia32-linux/usr/lib/libGLcore.so.1
>>>>> Segmentation fault
>>>>> cat:/home/lee#
>>>> the ia32-libs got seriously reworked has I understand, you can use the
>>>> Sid version of nvidia's packages, and install the "Debian way" using
>>>> "module-assistant".
>>> You mean to install an older Debian package that has the nvidia
>>> drivers? I looked for nvidia packages, but there doesn't seem to be
>>> one that would compile things for the kernel I'm using. And I don't
>>> know what "module-assistant" is.
>> No, you said you are using testing (Squeeze), just like I do, so I am
>> not advising to install an older package but the current unstable (Sid)
>> nvidia packages set that suit your hardware.
>
> Yeah, sorry, I don't keep track of the release names and get confused
> with them. I'm just using testing, it doesn't matter what its current
> name is ...
>
>> The minimum you should have would be nvidia-kernel-common,
>> nvidia-kernel-source (to build the kernel module with module-assistant),
>> and after the module is built install also nvidia-glx[-ia32].
>
> Which version of the driver do these contain? Would this compile the
> right things for the kernel I'm using?
>
I currently have 185.18.36-2 from Sid installed, my package list look like :
aptitude search ~S~i~nnvidia
i nvidia-glx
i nvidia-glx-ia32
i nvidia-kernel-2.6.31.2-vanilla64 << this is the kernel module built
with "module-assistant", you won't find this one in your package manager
i nvidia-kernel-common
i nvidia-kernel-source
i nvidia-libvdpau1
i nvidia-libvdpau1-ia32
i nvidia-settings
i nvidia-xconfig
Off course if you want the Sid version you need Sid "main" and
"non-free" in your sources.list, and do package (or rather level)
pinning to prevent a global switch to Sid. In simple words, create a
/etc/apt/apt.conf file (or in /etc/apt/apt.conf.d/), and put in it :
APT::Default-Release "testing";
You can also do more fine-grained "pinning" in /etc/apt/preferences (to
be created) OR /etc/apt/apt.conf.d/00preferences (to be created).
Something like :
Package: *
Pin: release a=unstable
Pin-Priority: 101
Should give you manual control over what's installed from Sid/unstable.
Just google around for "apt package pinning"
> Why can't I just use the nvidia installer? What's the difference?
>
>> If you do that directly it will build the default testing version, if
>> you install Sid packages first, you can use m-a to build the Sid
>> version, that's what I am using now on my Squeeze amd64 box.
>
> But I'm not using a Debian kernel.
Neither am I, 2.6.31.2 here.
>
>>>> It's working here, I tried the Nvidia (beta) script and it fails even in
>>>> expert mode where you can choose install paths.
>>> Yeah, the nvidia installer seems to work just fine and puts the
>>> libraries into the right place. But the libraries are not executable
>>> anymore without yielding a segmentation fault.
>> How do you test this, so that I can reproduce the tests here ?
>
> Well, just run the nvidia installer, it will say that some libraries
> cannot be found. When you look them up, they are available where they
> are supposed to be, but when you execute them, you get segmentation
> faults.
>
> Then run the nvidia installer again, but choose to not install the
> 32bit libs this time. That goes through without errors, and the libs
> that caused the problem before are gone.
Nvidia installer complains, then goes on spreading bogus links all over
the place, then the program tries to use 64bits libs in place of 32bits
compat ones and fails. I am not a specialist in Nvidia driver internals,
but it looks like it's seriously out of sync with Debian amd64
development right now.
>> I am afraid it's more a problem with the proprietary nature of the
>> Nvidia driver. If it sucks big time it will always be in last resort
>> Nvidia's fault... Debian doesn't have to be tailored around proprietary
>> programs just to meet their needs.
>
> It doesn't help users when things suddenly quit working.
Sure it's frustrating, I hate when Skype or GoogleEarth go "boom" after
an upgrade, but you've got to put the blame where it belongs. And all
the more when running Testing or Sid, development and testing are what
they are meant for.
>
>>> The web browsers don't work right anymore either and tend to crash now
>>> :( Instead of being improved, they got worse. What happened to the
>>> mozilla that included the email client and irc?
>>>
>> Well, that's another problem, iceweasel works mostly OK here, maybe
>> clean up your extensions/plugins ?
>
> There are way too many to do that --- or is there a list of all the
> packages I'd have to remove for that while somehow keeping the things
> I might want to keep installed and not have them removed due to
> dependencies? I'm not so sure if this is actually "another problem"
> rather than another symptom of the quality of Debian going down: First
> there isn't a web browser that works right anymore (since quite a
> while), then things that used to work just fine for like a decade
> (nvidia drivers) suddenly quit working and the web browsers got even
> worse at the same time.
>
>> I think what you are looking for is the "iceape" program in Debian
>> jargon, not sure about this since I have never used it.
>
> There doesn't seem to be an iceape package in testing. Perhaps the
> developers making mozilla stopped making it, but that leaves Debian
> without a working web browser. Neither galeon, nor iceweasel or
> firefox (which seems to be the same), let alone konqeror really
> work. And when you try to file a bug report, you're told not do it but
> to go to ridiculous lengths to figure out what's wrong yourself.
Iceape is available in Sid only for now :
apt-cache policy iceape
iceape:
Installed : (none)
Candidat : 1.1.17-2
Table de version :
1.1.17-2 0
500 http://ftp.fr.debian.org sid/main Packages
It has been deprecated for a while in Testing, should reenter anytime
(by popular demand as I understand ?).
If you don't feel like doing full-blown bug reports, open a specific
topic on the relevant list (here for instance) for each problem you
encounter (one per program), give as much specifics as you can so that
others can try to reproduce the problem, or confirm the exact same
setting is working for them (then you know it's probably a local
configuration problem). Most of the time you will find help and be able
to solve the problem. Otherwise you'll have material for your bug
report, or if a more experienced user is able to reproduce the problem
he might file the bug himself.
Take a look at the "reportbug" program, it helps. IMHO testing or sid
users should be (at least a bit) familiar with bug reports, that's the
way to go with free opensource software.
I use Iceweasel mostly, I have Konqueror and Opera installed too, mostly
for decoration purpose ;-), I don't feel restrained in my choice. They
all work well mostly, most crashes I encountered by the past where
linked to bad behaving extensions, or proprietary flash plug-in.
> Things used to just work in Debian, but they do that less and
> less. That isn't good.
>
>
Well, if stable doesn't meet your needs and other levels "bugs" you, you
can always try another Debian famous derivative where semi-automatic bug
reporting is well integrated... (there's no bitter irony here, freedom
of choice is what free software is about). If you want to carry on you
can find help, and documentation too. But ranting about Debian's quality
going down is just the way to attract flames, not helping hands...
(Sorry for the length of the message, hoops! Just got worst.)
Tom
Reply to: