xfree86 packages upgrade to 4.3.0.dfsg.1-9 from 4.3.0.dfsg.1-8 for 2.6.9 kernels fail

[Lithorus]

Do you have the "nvidia-glx" package installed? If so try and remove it, since it's only used for the debian packaged nvidia-kernel-source. I've had some bad experience when using this with manually installed nvidia drivers(non-debian packaged). After this try and re-install the driver (yeah, I know again )

About the localeconf package you can try and reinstall that too. (Btw. thanks for mentioning it, been looking for a package like that for ages )

[freelsjd]

No, I don't have the debian-based nvidia packages installed. Sort of like kernels, I prefer to install the vanilla brand I guess.

[freelsjd]

My son brings home his machine from school for the semester break. His machine is set up similar to mine. He has trouble after the xfree86 upgrade, but he figures out a way to change things (mostly glx libraries he says) set up to work with the 2.6.9 kernel, but only after much work. We will work on it sometime during the next couple of days and report back in to this thread.

[Lithorus]

It seems xfree86 4.3.0.dfsg.1-10 just arrived, you might wanna try with that...

There seems to be fixed a bug in xdm that prevents from starting X if you are using startx.

/etc/X11/xdm/Xstartup:
    exec sessreg -a -l "$DISPLAY" -u /var/run/utmp
                 -x /etc/X11/xdm/Xservers "$USER"

there must be a \ at the end of the first line:
    exec sessreg -a -l "$DISPLAY" -u /var/run/utmp \
                 -x /etc/X11/xdm/Xservers "$USER"

[Lithorus]

Check out this thread, seems similar to your problem
http://www.nvnews.net/vbulletin/showthread.php?t=36572

[freelsjd]

Problem resolved (somewhat). I commented out glx load in the XF86Config-4 and it works fine under 2.6.9. Then I went back and reinstalled the nvidia driver from scratch; this time making sure I did it WITHOUT the "--force-tls=classic" switch enabled. And now it works.

The application I have that requires this switch (or rather requires not using the newer tls) also cannot run under 2.6.9 (or at least it will not install under 2.6.9). Is there a way to run 2.6.9 with new tls and 2.4.28 with old tls without reinstalling the nvidia drivers ?

I am going to remove the bug report on debian. This is an nvidia-specific problem.

[zander]

@freelsjd: you could set LD_ASSUME_KERNEL so something like 2.2.5 in the application's environment; out of curiosity, which application is this? Also, please make sure that you don't have any Debian NVIDIA packages installed or partially installed, I seem to recall they perform boot-time symlink magic that interferes with the correct runtime selection of the appropriate libnvidia-tls library.

[freelsjd]

Problem fixed. Here is my work around:

Install first with the 2.6.9 kernel with default settings; i.e.,

./NVIDIA-Linux-x86-1.0-6629-pkg1.run

Then reboot under the 2.4.28 kernel and install without deleting existing libraries

./NVIDIA-Linux-x86-1.0-6629-pkg1.run -K --force-tls=classic

Then things will work as desired. When new kernels come out, pain in the rear.

I don't have any debian-based nvidia packages installed on my systems for reasons like this.

The application that needs classic tls is a commercial code called FEMLAB developed by comsol (www.comsol.com). It relys heavily on java. Great code for engineering analysis.

Thanks all for the tips and patience. If there is a better way to do this, please advise.

[freelsjd]

I was mistaken slightly here. If you want to run 2.6.9, you must reinstall the nvidia drivers without the "--force-tls=classic". Then if you want the 2.4.28 kernel with applications that cannot use the new tls, you must include the "--force-tls=classic" option. Basically, you must reinstall the nvidia drivers every time you want to switch kernels. This will discourage me from using the 2.6.x kernels until such time as the applications I need to use catch up. I guess this is basically what is going on with all linux users who use older applications.