Alternative OpenGL lib's not updated when using closed drivers

Bug #1182677 reported by nukedathlonman
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
dpkg (Ubuntu)
New
Undecided
Unassigned

Bug Description

I have two computers, both are now running run Kubuntu 13.04 x86-64 editions (the desktop also has Ubuntu Studio 13.04 x86-64), both use closed source drivers (laptop has nVidia 9600M GS adapter, desktop has AMD Radeon HD 6770). Before upgrading, both system's and three *buntu's ran fine with all OpenGL lib's being pointed to correctly. After upgrading, the video library paths got cleared leaving me with virtually all my wine games seg faulting as well as native Linux games and programs (Skype 4.1, Doom 3, Quake Arena, etc). The problem really highlights it's self if the software wants to use OpenGL drivers.

I found a temperary fix by adding the video paths to these files:

/etc/ld.so.conf.d/i386-linux-gnu_GL.conf :

/usr/lib32/fglrx (On the desktop)
/usr/lib32/nvidia-313-updates (On the laptop)

/etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf :

/usr/lib/fglrx #(On the desktop)
/usr/lib/nvidia-313-updates (On the laptop)

I tried updating the alternatives before I edited these files, and I just got a message back on the terminal saying there were no alternative's to configure.

This workaround works, but will need to be changed if these paths change at any time. Now this shouldn't pose a problem for FireGL Catalyst drivers, but it will pose problems for the nVidia drivers since the driver series and type (ie 313 series Updates driver) is noted in the directory.

After these two simple mod's, all my OpenGL programs (both native 64-bit and 32-bit Linux apps, and Wine programs) worked flawlessly.

This does not effect the open source nVidia and AMD drivers, the issue only shows up when using the closed nVidia and AMD binary blob's on *buntu 13.04.

Tags: bot-comment
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1182677/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
Revision history for this message
nukedathlonman (areginato) wrote :

sorry I didn't list a specific package, it's cause I'm not sure if it's the nVidia/AMD packages, or related to another package. I did deinstall/reinstall the video drivers numerous times over the weekend (first thought was drivers didn't install properly, then started thinking bug in the actual drivers, and then a realization the the issue when I looked at the library paths with ldconfig), and went so far as to try the AMD driver from there web site and removed it again, as well as made use of Neuvoux and Gallium3D drivers (I didn't stick with open drivers as they don't meet my needs). I spent hours debugging wine before I realized what was happening and how it related to Wine, and several programs. I then spent several hours testing and coming up with the pesudo fix posted above. I am not sure if this effects the 32 bit editions, and can only fully confirm this is effecting Kubuntu and Ubuntu Studio 13.04 (earlier releases are fine).

Revision history for this message
nukedathlonman (areginato) wrote :

Starting my tracing... But I think the bug is in a script of a package that uses libc-bin, and it isn't a bug in libc-bin.

affects: ubuntu → eglibc (Ubuntu)
Revision history for this message
nukedathlonman (areginato) wrote :

Sorry, this is not a libc-bin bug... But looking through the postinst scripts for the package's for both the ATI and nVidia drivers, it appears that for some reason when the script is executed, the script's in the 64-bit packages are skipping neumerous update-alternative lines, hence ldconfig isn't setting up the directories. So it appears to be the packages affected are fglrx, fglrx-updates, nvidia-173, nvidia-304, nvidia-310, & nvidia-313-updates, and possibly others.

affects: eglibc (Ubuntu) → ubuntu
Revision history for this message
nukedathlonman (areginato) wrote :

I know, this is taking me a while - I'm not a script kitty or a programmer, so I'm not the swiftest at picking out on what's happening - it's study-study, and rip appart and slowly nit pick my way through the scripts while I'm jugling other tasks). ;-)

At any rate, with the AMD fglrx-updates driver, it looks like when the postinst script executes "$1" is not equaling "configure" on line 93.

<--* QUOTE:
if [ "$1" = "configure" ]; then
*-->
So the updates in the if statment aren't being applied to the system.

With the nvidia-313-updates driver, it looks like when the postinst script executes, case "$1" is not configure on line 108 and 109

<--* QUOTE:
case "$1" in
         configure)
*-->

So once again the updates aren't being applied to the system.

Revision history for this message
nukedathlonman (areginato) wrote :

Given that dpkg is passing a parameter ("$1") onto the scripts, I beleive the target package is dpkg.

affects: ubuntu → dpkg (Ubuntu)
Revision history for this message
nukedathlonman (areginato) wrote :

Better more effective work around - extract the postinst files from the appropriate deb files and then execute them as root:

******@********:~/temp$ ./postinst configure

That got it!

Revision history for this message
nukedathlonman (areginato) wrote :

Err, no it didn't - not on my Laptop or Ubuntu Studio build (forgot to remove the lines from the ld.so.conf files). Command line parameters (in this case configure) are not being passed into the scripts. I really hope this isn't affecting other packages or distro's. :-(

Revision history for this message
nukedathlonman (areginato) wrote :

Okay, I added a whole pile of debugging statments into it, and kept running it as root - it is picking up the parameter configure, but the files aren't updating. So next I tried executing a direct command from the postinst file, to explicitly update the i386 file (as root): update-alternatives --force --install /etc/ld.so.conf.d/i386-linux-gnu_GL.conf i386-linux-gnu_gl_conf /usr/lib/nvidia-313-updates/alt_ld.so.conf 9702

The result was /etc/ld.so.conf.d/i386-linux-gnu_GL.conf updated. So, now I'm scratching my head - why does it work from a command line but it will not work from inside the script (it was a cut and paste with one minor change (so it would execute as root). Well, I'm confused enough and think it's time I hit the sack.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.