Bug#876033: primusrun doesn't find libGL.so.1

[Bernd Vaske]

Hello,

the problem comes from the transition of mesa to glvnd.
A workaround is to link the missing libs from

/usr/lib/x86_64-linux-gnu/libGL.so.1 to
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
and
/usr/lib/i386-linux-gnu/libGL.so.1 to
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1

That will result in primusrun starting again but most likely resulting
in a black window for the application which is started.

To get primusrun to work properly you have to start it with
__GLVND_DISALLOW_PATCHING=1

example:

__GLVND_DISALLOW_PATCHING=1 primusrun glxgears

Best regards

[Luca Boccassi]

On Sun, 2017-09-17 at 18:17 +0200, Luigi wrote:
> Package: primus
> Version: 0~20150328-4
> Severity: grave
> Justification: renders package unusable
>
> i installed primus, bumblebee and bumblebee-nvidia; i launched
> primusrun but i obtained this output:
> $ primusrun glxgears -info
> /usr/bin/primusrun: riga 41: attenzione: command substitution:
> ignored null byte in input
> primus: fatal: failed to load any of the libraries: /usr/lib/x86_64-
> linux-gnu/nvidia/libGL.so.1:/usr/lib/i386-linux-
> gnu/nvidia/libGL.so.1:/usr/lib/nvidia/libGL.so.1
> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1: cannot open shared
> object file: No such file or directory
> /usr/lib/i386-linux-gnu/nvidia/libGL.so.1: cannot open shared object
> file: No such file or directory
> /usr/lib/nvidia/libGL.so.1: cannot open shared object file: No such
> file or directory
>
> In my system libGL.so.1 is located in these directories:
> ~$ locate libGL.so.1
> /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu
> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.0.0
> /usr/lib/x86_64-linux-gnu/libGL.so.1
> /usr/lib/x86_64-linux-gnu/primus/libGL.so.1 
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (50, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
> LANGUAGE= (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages primus depends on:
> ii  bumblebee          3.2.1-16
> ii  primus-libs        0~20150328-4
> ii  socat              1.7.3.2-1
> ii  xserver-xorg-core  2:1.19.3-2
>
> Versions of packages primus recommends:
> pn  primus-libs-ia32  <none>
>
> primus suggests no packages.
>
> -- no debconf information

Hi,

Could you please try again with nvidia-driver 375.82-4 that was just
uploaded to unstable? There are some fixes w.r.t. compatibility with
mesa+glvnd

--
Kind regards,
Luca Boccassi

[Luigi Curzi]

this solution works.

Thank you.

[Emilio J. Padrón]

Package: primus
Version: 0~20150328-4
Followup-For: Bug #876033

Dear Maintainer,

I obtain the same error when trying primusrun (or optirun) in my system:

% primusrun glxinfo
/usr/bin/primusrun: line 41: warning: command substitution: ignored null byte in input

primus: fatal: failed to load any of the libraries:

/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1:/usr/lib/i386-linux-gnu/nvidia/libGL.so.1:/usr/lib/nvidia/libGL.so.1

/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1: cannot open shared object file: No such file or directory
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1: cannot open shared object file: No such file or directory
/usr/lib/nvidia/libGL.so.1: cannot open shared object file: No such file or directory

The '__GLVND_DISALLOW_PATCHING=1' workaround did not work for me :-?
(same error messages).

By the way, I suppose it is not really related, but I'm not able to install
nvidia glvnd packages, libgl1-glvnd-nvidia-glx 375.82-4 and
libglvnd0-nvidia 375.82-4, due to dependency problems. The metapackage
libgl1-nvidia-glvnd-glx 375.82-4 is installed ok, since the libgl1
dependency is provided by other packages. Is it also a bug? :-?

-- System Information:
Debian Release: buster/sid
APT prefers unstable

APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores)

Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages primus depends on:
ii bumblebee 3.2.1-16
ii primus-libs 0~20150328-4
ii socat 1.7.3.2-1
ii xserver-xorg-core 2:1.19.3-2

ii xserver-xorg-video-intel 2:2.99.917+git20161206-1

Versions of packages primus recommends:
pn primus-libs-ia32 <none>

primus suggests no packages.

% dpkg -l | grep -E 'libe?gl'
ii libegl-mesa0:amd64 17.2.1-1
ii libegl-nvidia0:amd64 375.82-4
ii libegl-nvidia0:i386 375.82-4
ii libegl1:amd64 0.2.999+git20170802-4
ii libegl1:i386 0.2.999+git20170802-4
ii libegl1-mesa:amd64 17.2.1-1
ii libegl1-mesa-dev:amd64 17.2.1-1
ii libgl1:amd64 0.2.999+git20170802-4
ii libgl1:i386 0.2.999+git20170802-4
ii libgl1-mesa-dev:amd64 17.2.1-1
ii libgl1-mesa-dri:amd64 17.2.1-1
ii libgl1-mesa-glx:amd64 17.2.1-1
ii libgl1-nvidia-glvnd-glx:amd64 375.82-4
ii libgl1-nvidia-glvnd-glx:i386 375.82-4
ii libglapi-mesa:amd64 17.2.1-1
ii libgles-nvidia1:amd64 375.82-4
ii libgles-nvidia1:i386 375.82-4
ii libgles-nvidia2:amd64 375.82-4
ii libgles-nvidia2:i386 375.82-4
ii libgles1-glvnd-nvidia:amd64 375.82-4
ii libgles1-glvnd-nvidia:i386 375.82-4
ii libgles2:amd64 0.2.999+git20170802-4
ii libgles2:i386 0.2.999+git20170802-4
ii libglew-dev:amd64 2.0.0-5
ii libglew2.0:amd64 2.0.0-5
ii libglib2.0-0:amd64 2.54.0-1
ii libglib2.0-bin 2.54.0-1
ii libglib2.0-data 2.54.0-1
ii libglib2.0-dev:amd64 2.54.0-1
ii libglib2.0-dev-bin 2.54.0-1
ii libglibmm-2.4-1v5:amd64 2.54.1-1
ii libgltf-0.1-1:amd64 0.1.0-2
ii libglu1-mesa:amd64 9.0.0-2.1
ii libglu1-mesa-dev:amd64 9.0.0-2.1
ii libglvnd-core-dev 0.2.999+git20170802-4
ii libglvnd-dev 0.2.999+git20170802-4
ii libglvnd0:amd64 0.2.999+git20170802-4
ii libglvnd0:i386 0.2.999+git20170802-4
ii libglx-mesa0:amd64 17.2.1-1
ii libglx-nvidia0:amd64 375.82-4
ii libglx-nvidia0:i386 375.82-4
ii libglx0:amd64 0.2.999+git20170802-4
ii libglx0:i386 0.2.999+git20170802-4

-- no debconf information

[Andreas Beckmann]

[ Cc:ing the libglvnd maintainer ]

On 09/25/2017 04:38 PM, Emilio J. Padrón wrote:
> I obtain the same error when trying primusrun (or optirun) in my system:
>
> % primusrun glxinfo
> /usr/bin/primusrun: line 41: warning: command substitution: ignored null byte in input
> primus: fatal: failed to load any of the libraries:
> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1:/usr/lib/i386-linux-gnu/nvidia/libGL.so.1:/usr/lib/nvidia/libGL.so.1
> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1: cannot open shared object file: No such file or directory
> /usr/lib/i386-linux-gnu/nvidia/libGL.so.1: cannot open shared object file: No such file or directory
> /usr/lib/nvidia/libGL.so.1: cannot open shared object file: No such file or directory
>
> The '__GLVND_DISALLOW_PATCHING=1' workaround did not work for me :-?
> (same error messages).

The question is: how should primusrun/optirun work in a GLVND
environment? There is no longer the "vendor" libGL.so.1 that has to be
loaded instead of the system libGL.so.1
As I understand it, GLVND is supposed to provide a better solution to
the underlying problem addressed by primusrun/optirun.

Note: if libgl1-nvidia-glvnd-glx is used (instead of libgl1-nvidia-glx)
and libgl1 (from src:libglvnd) is installed instead of
libgl1-glvnd-nvidia-glx, there is no longer a nvidia-provided
/usr/lib/*/nvidia/libGL.so.1

(Note for Timo: for the nvidia drivers we still need to divert the
system libGL.so.1 (and much more) since the legacy 304xx, 340xx drivers
don't support GLVND and we therefore still need to use the nested
alternatives, and we want to have them co-installable with the current
drivers)

> By the way, I suppose it is not really related, but I'm not able to install
> nvidia glvnd packages, libgl1-glvnd-nvidia-glx 375.82-4 and
> libglvnd0-nvidia 375.82-4, due to dependency problems. The metapackage
> libgl1-nvidia-glvnd-glx 375.82-4 is installed ok, since the libgl1
> dependency is provided by other packages. Is it also a bug? :-?

That is intentional to allow the nvidia packages into testing which
still has mesa 13.x and no libglvnd. You should be fine with the libgl1,
... packages from src:libglvnd in sid.


Andreas

[Bernd Vaske]

On Mon, 25 Sep 2017 20:50:53 +0200 Andreas Beckmann <an...@debian.org> wrote:
> [ Cc:ing the libglvnd maintainer ]
>
> On 09/25/2017 04:38 PM, Emilio J. Padrón wrote:
> > I obtain the same error when trying primusrun (or optirun) in my system:
> >
> > % primusrun glxinfo
> > /usr/bin/primusrun: line 41: warning: command substitution: ignored null byte in input
> > primus: fatal: failed to load any of the libraries:
> > /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1:/usr/lib/i386-linux-gnu/nvidia/libGL.so.1:/usr/lib/nvidia/libGL.so.1
> > /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1: cannot open shared object file: No such file or directory
> > /usr/lib/i386-linux-gnu/nvidia/libGL.so.1: cannot open shared object file: No such file or directory
> > /usr/lib/nvidia/libGL.so.1: cannot open shared object file: No such file or directory
> >
> > The '__GLVND_DISALLOW_PATCHING=1' workaround did not work for me :-?
> > (same error messages).
>
> The question is: how should primusrun/optirun work in a GLVND
> environment? There is no longer the "vendor" libGL.so.1 that has to be
> loaded instead of the system libGL.so.1
> As I understand it, GLVND is supposed to provide a better solution to
> the underlying problem addressed by primusrun/optirun.

Doesn't it only address part of the problem? Don't see a lot in regards
of turning the dedicated card on/off.
The dispatching to a specific vendor GLX is per x screen? At least thats
how it is described in https://github.com/NVIDIA/libglvnd. Which seems
to mirror the nvidia PRIME way.

So maybe primusrun/optirun will still bring up the card but only "fake"
the context to be nvidia for a specific application and thus forcing the
gldispatch to divert to the nvidia gl.

> Note: if libgl1-nvidia-glvnd-glx is used (instead of libgl1-nvidia-glx)
> and libgl1 (from src:libglvnd) is installed instead of
> libgl1-glvnd-nvidia-glx, there is no longer a nvidia-provided
> /usr/lib/*/nvidia/libGL.so.1
>
> (Note for Timo: for the nvidia drivers we still need to divert the
> system libGL.so.1 (and much more) since the legacy 304xx, 340xx drivers
> don't support GLVND and we therefore still need to use the nested
> alternatives, and we want to have them co-installable with the current
> drivers)
>
> > By the way, I suppose it is not really related, but I'm not able to install
> > nvidia glvnd packages, libgl1-glvnd-nvidia-glx 375.82-4 and
> > libglvnd0-nvidia 375.82-4, due to dependency problems. The metapackage
> > libgl1-nvidia-glvnd-glx 375.82-4 is installed ok, since the libgl1
> > dependency is provided by other packages. Is it also a bug? :-?
>
> That is intentional to allow the nvidia packages into testing which
> still has mesa 13.x and no libglvnd. You should be fine with the libgl1,
> ... packages from src:libglvnd in sid.
>
>
> Andreas

BTW the workaround I posted still seems to work. But you must not forget
to link the libGL.so.1 into the nvidia subdirectory in addition to the
__GLVND_DISALLOW_PATCHING=1.

[Gunman]

On 04.10.2017 00:22, Luca Boccassi wrote:
> Unfortunately the problem can't be reproduced on Stretch given there's
> no glvnd there. At the moment I do not have a Sid installation on
> hardware that supports optimus, unfortunately, sorry. I'll try to find
> time to install it on one of my laptops in the next couple of weeks.
Would probably be interesting to install Stretch and then update to SID.

> Instead of symlinking the file, could you please try to edit the
> LibraryPath line in /etc/bumblebee/bumblebee.conf and add
>
> :/usr/lib/x86_64-linux-gnu:/usr/lib/i386-linux-gnu
>
> to it? Then systemctl restart bumblebeed.service
That works too, with the __GLVND_DISALLOW_PATCHING=1. Without it, it
still gives a black screen/window.

> It would be tricky to ship it in the packages, as without the glvnd it
> would actually break it.
Would it be easier/cleaner to create a second package? primus-glvnd for
example? So for the legacy drivers one still could use primus and for
the mesa-glvnd one would have to use primus-glvnd.

> What if, as an interim solution to avoid breakages, I added a Conflicts
> with libgl1-glvnd-nvidia-glx on primuslibs, so that the non-glvnd
> packages will get pulled in automatically when using bumblebee?
For me that package is not installed and pretty much uninstallable
anyway. Or did you mean libgl1-nvida-glvnd-glx?

Best regards

[Andreas Beckmann]

On 10/11/2017 11:46 AM, Luca Boccassi wrote:
> Andreas,
>
> Long term, the only easy to maintain solution I can see (until there is
> proper support upstream for GLVND) would be to change the config in a
> postinst, depending on what package is installed. But that feels very
> wrong (changing config files) and very fragile.
> What do you think?

Clear NACK for modifying conffiles. You would also need triggers to
change this if some package is installed/removed later on.

I think primus needs two searchpatch variables (classic and glvnd) and
needs to detect at runtime which one to use. Well, the second one could
be "empty", since it uses system libs instead of driver dependent ones.
How ever this runtime detection could look like.


Andreas

[Luca Boccassi]

On Wed, 2017-10-11 at 11:57 +0200, Andreas Beckmann wrote:
> On 10/11/2017 11:46 AM, Luca Boccassi wrote:
> > Andreas,
> >
> > Long term, the only easy to maintain solution I can see (until
> > there is
> > proper support upstream for GLVND) would be to change the config in
> > a
> > postinst, depending on what package is installed. But that feels
> > very
> > wrong (changing config files) and very fragile.
> > What do you think?
>
> Clear NACK for modifying conffiles. You would also need triggers to
> change this if some package is installed/removed later on.

Yep fully agree.

> I think primus needs two searchpatch variables (classic and glvnd)
> and
> needs to detect at runtime which one to use. Well, the second one
> could
> be "empty", since it uses system libs instead of driver dependent
> ones.
> How ever this runtime detection could look like.

The additional problem is that the change would involve bumblebee too,
since that's what sets up these paths.

Given it's a non-trivial amount of work, I wonder if it's better to
keep the workaround in place (assuming it doesn't cause problems) and
then wait for server-side GLVND to happen?

I've seen movement in the past few weeks, apparently support in Xorg is
about to land:

https://github.com/kbrenneman/libglvnd/commits/server-libglx-tag-data
https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-XDC17-GLVND
https://www.phoronix.com/scan.php?page=news_item&px=Xorg-Server-1.20-Features
https://lists.x.org/archives/xorg-devel/2017-July/054118.html

[devfra]

On martedì 17 ottobre 2017 20:53:49 CEST Luca Boccassi wrote:
> What's the output of:
>
> dpkg -l | grep 375.82-5

$ dpkg -l | grep 375.82-5
ii libegl-nvidia0:amd64 375.82-5 amd64 NVIDIA binary EGL library
ii libegl-nvidia0:i386 375.82-5 i386 NVIDIA binary EGL library
ii libgl1-nvidia-glx:amd64 375.82-5 amd64 NVIDIA binary OpenGL/GLX...
ii libglx-nvidia0:amd64 375.82-5 amd64 NVIDIA binary GLX library
ii libglx-nvidia0:i386 375.82-5 i386 NVIDIA binary GLX library
ii libnvidia-eglcore:amd64 375.82-5 amd64 NVIDIA binary EGL core l...
ii libnvidia-eglcore:i386 375.82-5 i386 NVIDIA binary EGL core l...
ii libnvidia-glcore:amd64 375.82-5 amd64 NVIDIA binary OpenGL/GLX...
ii libnvidia-glcore:i386 375.82-5 i386 NVIDIA binary OpenGL/GLX...
ii libnvidia-ml1:amd64 375.82-5 amd64 NVIDIA Management Librar...
ii nvidia-alternative 375.82-5 amd64 allows the selection of ...
ii nvidia-egl-common 375.82-5 amd64 NVIDIA binary EGL driver...
ii nvidia-egl-icd:amd64 375.82-5 amd64 NVIDIA EGL installable c...
ii nvidia-egl-icd:i386 375.82-5 i386 NVIDIA EGL installable c...
ii nvidia-kernel-dkms 375.82-5 amd64 NVIDIA binary kernel mod...
ii nvidia-kernel-support 375.82-5 amd64 NVIDIA binary kernel mod...
ii nvidia-legacy-check 375.82-5 amd64 check for NVIDIA GPUs re...
ii nvidia-vdpau-driver:amd64 375.82-5 amd64 Video Decode and Present...
ii xserver-xorg-video-nvidia 375.82-5 amd64 NVIDIA binary Xorg driver

Thanks.

[Luca Boccassi]

I think there's a couple missing i386 packages, try to install the
nvidia-driver-libs:i386 metapackage to pull them in