Page: Previous  1, 2, 3, 4, 5, 6, 7  Next

Chris M
Status: Contributor
Joined: 11 Aug 2013
Posts: 62
Reply Quote
This is a bit off topic, since I purged nvidia and installed "debian's" 375 last weekend. 378 dropped into sid this week, and it installed fine. Then 384.98-2 dropped into sid this morning, and it also installed without an issue.

I'm still having the glxinfo issue/error, but again, I'm pretty sure this will shake out when mesa is updated.

The bottom line is that because I'm good right now, I'm not inclined to install the latest nvidia driver (387.34, last I checked) with sgfxi with the added flag fix. I might do it this weekend, but maybe not until I have to deal with an upgraded kernel. If anyone else has had this installation issue, please post your results after running the updated sgfxi.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 3882
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
I'm curious what happens with the flag fix, I haven't tested it, been busy with work, can't do heavy testing at this point.

I don't believe it's a good solution, nor is it a solution I want to leave in inxi because I'm unclear what happens on removal, etc, and I'm unclear what the packages in question even do.

Unfortunately smxi/sgfxi were hit with the wget bug, which I've fully corrected now in both (as well as in a much more robust fix in inxi), but the nvidia issue was unclear, and didn't get much attention beyond my adding an auto add flag to the nvidia installer which should have in theory corrected your issues.

note that technically speaking, all you'd need to do to restore fully from a test is to use apt to reinstall the package that owns the file in question. Reinstalls in debian do not check the actual binaries, they apparently do in Arch, but not in debian, which is convenient, it means it doesn't matter what something does to a specific library, you can just reinstall it and go on.

The real sad part of this is that I can never trust gnu wget again, because they uploaded a new version WITHOUT TESTING IT AT ALL!!

And yes, I'm aware of the irony of my releasing a fix without testing it, but sgfxi does not have many users compared to wget, which is basically in every linux system in the world, so it's a bit different to not test a core utility than to not test a user addon that's not even a package in any distribution. inxi for example is always tested.

Since -O is a standard option, any reasonable testing script would have detected the failure instantly, so this tells me the programmers working on that are not testing it, it's not possible they are, with a consistent test set before release. Which means I can't trust it anymore.

Note that once you write a simple shell script that simply runs your wget build using most of the standard options, and combinations, and exits on failure, testing it would take a minute or two, literally.
Back to top
Chris M
Status: Contributor
Joined: 11 Aug 2013
Posts: 62
Reply Quote
For the libglvnd issue, follow this bug thread: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879041

There's a conflict between libglvnd0-nvidia and libglvnd0:i386. I think the nvidia driver wants to install libglvnd0-nvidia, but I'm not exactly sure about that.

Updated mesa didn't solve this, and this issue was re-assigning to nvidia-graphics-drivers.

https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=nvidia-graphics-drivers

I still haven't tried to install the driver via sgfxi, but this is what's up, FWIW.

Update/Edit:

:: Quote ::
From: Andreas Beckmann <anbe@debian.org>
To: Chris Manougian <cmanougian@gmail.com>, 879041-done@bugs.debian.org
Subject: Re: Bug#879041: libglvnd0-nvidia
Date: Sat, 16 Dec 2017 19:11:38 +0100

On 2017-12-16 18:50, Chris Manougian wrote:
> libglvnd0-nvidia is version 384.98-3, and it makes sense that it should be
> installed.

No, you don't want that to be installed.
And it's intentional that it can't be installed if you want a working
setup in buster/sid. (But it's kept around since it's needed for
backporting to stretch.)
Nvidia ships an ancient version of libglvnd with their driver, it just
has the driver's version.


Andreas

Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 3882
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
It would be easier to see what's up if you try the sgfxi install.

It's now set to default install those nvidia libs, so the question is, if that flag is used, does the install work.

this takes a few minutes to determine, and you can always apt reinstall the lib package anyway if things don't quite work.

I don't have any information on this beyond what you have told me, so the only way to verify if it works is to simply install via sgfxi the nvidia driver, which will then install with the use nvidia libs in the install.

It's always very difficult to know what exactly debian maintainers mean when they talk about packages overwriting some debian lib, usually there's an unhappy reaction to that fact, but what there usually and sadly is not is a verification that such an overwrite fixes the issue.
Back to top
Chris M
Status: Contributor
Joined: 11 Aug 2013
Posts: 62
Reply Quote
:: techAdmin wrote ::
Note, by simply querying the nvidia run package, with --help, then -A for advanced options, I found the right flag, so I've added --install-libglvnd as default nvidia install, and added -g which turns it OFF, that is, uses the -no-install-libglvnd flag on the install. The default is to install it.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879041

If you take a look at Dirk Lehmann's original post, he'is running the installer in a way that allows full control over his installation.

:: Dirk Lehmann wrote ::
During installing the Nvidia Geforce driver version 384.90 the
following error occurs:

"An incomplete installation of libglvnd was found. Do you want to
install a full copy of libglvnd? This will overwrite any existing
libglvnd libraries."

After choosing to NOT overwrite the installation ...


... he gets the libGL errors (same errors). And given Andreas Beckmann's final comments, I don't think you want to answer "yes, install install a full copy of libglvnd". I'm 99% sure you'd be installing what Beckmann says is Nvidia's "ancient version of libglvnd".

Is that what you've done with the script? I do not want to install nvidia's version. I want to answer "no", not "abort".

h2, ask Santa for this: https://www.newegg.com/Product/Product.aspx?Item=9SIA2F85ST7915
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 3882
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
It would be easier to see what's up if you try the sgfxi install.

It's now set to default install those nvidia libs, so the question is, if that flag is used, does the install work.

this takes a few minutes to determine, and you can always apt reinstall the lib package anyway if things don't quite work.

I don't have any information on this beyond what you have told me, so the only way to verify if it works is to simply install via sgfxi the nvidia driver, which will then install with the use nvidia libs in the install.

It's always very difficult to know what exactly debian maintainers mean when they talk about packages overwriting some debian lib, usually there's an unhappy reaction to that fact, but what there usually and sadly is not is a verification that such an overwrite fixes the issue.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 3882
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
If you want to see what happens with the nvidia installer, you'd have to run the .run package, which is in I think /usr/src/sgfxi and then see what happens.

Technically speaking, I can't test stuff I don't have.

I could also reverse the option, to default to not using that thing, which might get rid of the question, I don't know.
Back to top
Chris M
Status: Contributor
Joined: 11 Aug 2013
Posts: 62
Reply Quote
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879041

:: Andreas Beckmann wrote ::
I think I found it. You have some cruft MESA libGL that is being used:

On 2017-12-18 16:14, Chris Manougian wrote:
> /usr/lib/mesa-diverted/x86_64-linux-gnu/:
> total 1172
> lrwxrwxrwx 1 root root 10 Nov 18 14:31 libGL.so -> libGL.so.1
> lrwxrwxrwx 1 root root 14 Nov 18 09:01 libGL.so.1 -> libGL.so.1.2.0
> -rw-r--r-- 1 root root 567624 Nov 9 05:14 libGL.so.1.0.0
> -rw-r--r-- 1 root root 463424 Apr 25 2017 libGL.so.1.2.0

This should fix it:

ln -sf libGL.so.1.0.0 /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
rm /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0

While we try to clean up a lot of libGL.so.* mess from nvidia-installer
(in package nvidia-installer-cleanup), we may not cover your
installation path. And I doubt you want to dig into finding a
reproducible path to get to your setup :-)

That would also explain the error message, since this is not a GLVND
libGL, it misses some specific entrypoints and therefore the
installation is considered "incomplete".
And it was probably already messed up long before the glx-diversions
package moved the files to /usr/lib/mesa-diverted ...


Andreas


This issue is done for me.

1) The wget issue is solved.

2) Installing the nvidia-driver the debian way solved most of my issue, and this is probably due to the way debian packages the driver to proceed with the installation, even though the Open GL issue was not solved by a successful driver installation.

3) h2, I would reverse the flag fix in sgfxi. This issue obviously impacted a few people, but not enough to warrant a universal script fix.

I've been messing with this for 6 weeks, and I'm over it. No one else has complained, so I'm going to chalk this up to a personal one-off. If anyone else is having the same type of issue, there's plenty of info in this thread to fix the problem, or to post sgfxi run results to effect change in sgfxi if needed.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 3882
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
Reversed the -g option, now -g turns ON that nvidia install feature, and default is now to disalbe the install, which should I believe also get rid of the question in the install process I think.
Back to top
Chris M
Status: Contributor
Joined: 11 Aug 2013
Posts: 62
Reply Quote
An updated wget came into sid today: https://tracker.debian.org/pkg/wget

1.19.2-2 over 1.19.2-1

:: Code ::
root@asus:/home/chris# wget -O - smxi.org/sm/sm-versions
--2018-01-04 16:54:45--  http://smxi.org/sm/sm-versions
Resolving smxi.org (smxi.org)... 216.92.31.53
Connecting to smxi.org (smxi.org)|216.92.31.53|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://smxi.org/sm/sm-versions [following]
--2018-01-04 16:54:45--  https://smxi.org/sm/sm-versions
Connecting to smxi.org (smxi.org)|216.92.31.53|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 433
Saving to: ‘STDOUT’

-                     0%[                    ]       0  --.-KB/s               smxi=8.15.26:2017-11-25
sm-lib-apt-tools=1.23.43:2015-11-25
sm-lib-clean-up=2.10.15:2012-02-08
sm-lib-distro-conversion=3.3.17:2014-03-29
sm-lib-du-fixes=1.4.12:2015-11-16
sm-lib-graphics=2.6.2:2014-12-19
sm-lib-kde4-updater=0.7.39:2013-11-19
sm-lib-kernel=2.7.1:2017-12-11
sm-lib-kernel-install=2.12.14:2016-05-12
sm-lib-misc-tweaks=1.24.7:2017-11-25
sm-lib-package-install=3.4.39:2016-11-25
sm-lib-package-removal=1.4.2:2011-02-10
sm-lib-warning=2.0.3:2017-11-25
sm-lib-2006-fixes=1.2.2:2008-06-08
sm-lib-2007-fixes=1.3.20:2008-11-17
sm-lib-2008-fixes=1.4.2:2008-12-26
sm-lib-2008-fixes-s=1.0.1:2008-11-17
sm-lib-2008-fixes-t=1.0.2:2008-11-18
sm-lib-2009-fixes=1.1.25:2010-09-16
sm-lib-2009-fixes-s=1.0.1:2009-04-07
sm-lib-2009-fixes-t=1.1.19:2009-12-02
sm-lib-2011-fixes=1.1.0:2011-07-14
sm-lib-2011-fixes-s=1.0.0:2011-02-10
sm-lib-2011-fixes-t=1.1.0:2011-07-14
sgfxi=4.25.06:2017-12-19
svmi=2.8.72:2017-07-27
inxi=2.3.53:2017-12-07
rbxi=2.7.4:2016-12-20
sm-main-version=8.42.04:2017-12-11

###**EOF**###
-                   100%[===================>]     433  --.-KB/s    in 0s     

2018-01-04 16:54:45 (5.24 MB/s) - written to stdout [1008]

root@asus:/home/chris#


Looks good to me.
Back to top
Display posts from previous:   
Page: Previous  1, 2, 3, 4, 5, 6, 7  Next
All times are GMT - 8 Hours