[unstable] xorg-server libglx.so file conflict during mesa 17.0 update

[peaveyman]

Here it is again:

Proceed with installation? [Y/n]
(61/61) checking keys in keyring [####################################################] 100%
(61/61) checking package integrity [####################################################] 100%
(61/61) loading package files [####################################################] 100%
(61/61) checking for file conflicts [####################################################] 100%
error: failed to commit transaction (conflicting files)
nvidia-utils: /usr/lib/nvidia/xorg/libglx.so exists in filesystem
nvidia-utils: /usr/lib/nvidia/xorg/libglx.so.1 exists in filesystem
Errors occurred, no packages were upgraded.

[Rocky-IV]

@artoo
Great solution -- Working for me

Life is Great on Manjaroo

[peaveyman]

I took a chance and removed the two offending files, updated, rebooted, all is good.

[sueridgepipe]

Just updated, and whilst VM system boots and runs fine, on closer inspection things don't look so fine.

$ sudo mhwd-gpu --status
Using default
Default lib32 support: true
:: status
  lib32-libGl: '/usr/lib32/mesa/libGL.so.1.2.0'
  lib32-libGLESv1: '/usr/lib32/mesa/libGLESv1_CM.so.1.1.0'
  lib32-libGLESv2: '/usr/lib32/mesa/libGLESv2.so.2.0.0'
  lib32-libEGL: '/usr/lib32/mesa/libEGL.so.1.0.0'
  libGl: '/usr/lib/mesa/libGL.so.1.2.0'
  libGLESv1: '/usr/lib/mesa/libGLESv1_CM.so.1.1.0'
  libGLESv2: '/usr/lib/mesa/libGLESv2.so.2.0.0'
  libEGL: '/usr/lib/mesa/libEGL.so.1.0.0'
warning: could not find '/etc/X11/xorg.conf.d/90-mhwd.conf'!

[manjaro-vm xorg.conf.d]$ ll /etc/X11/xorg.conf.d
total 12
drwxr-xr-x 2 root root 4096 Nov 15 14:08 .
drwxr-xr-x 5 root root 4096 Nov 12 22:05 ..
-rw-r--r-- 1 root root  266 Nov 15 14:08 00-keyboard.conf

Any reason why I am missing should be missing /etc/X11/xorg.conf.d/90-mhwd.conf, or why /etc/X11/xorg.conf.d is missing config files?

Do I need to re-generate these by removing and re-installing my video driver, or is this a product of running in a VM and using video-virtualbox driver?

$ pacman -Qi mesa
Name            : mesa
Version         : 17.0.0-1

$ glxinfo | grep core
    Max core profile version: 3.3
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.0.0

Shouldn't this be OpenGL 4.5 now, or is this dependent on installed video driver and related gpu supports?

[saxonbeta]

After the storm of few hours ago , everything is working OK in my system

[johnvan54]

I guess I was lucky - went to work this morning saw this issue with update. When I came back and updated all appears to be working well.

[Odysseus]

Damn, I just got through spending hours trying to recover my machine... I should have listened to my own advice I gave previously, and just waited for the update. I backed up and renamed the offending file as suggested after I had posted earlier. Doing so left me unable to get to my desktop with my old legacy Nvidia-304.xx setup.

I thought, no problem it's happened before, just part of the price of running unstable. So I put in my installation disk and figured I'd just chroot from it and get things straightened out...wrong!!! My freaking disc wouldn't boot! I guess I must have scratched it and I didn't have a spare (or so I thought). I scrambled around trying to find a friend with a machine I could burn a new disc off of, which took me across town and I had to wait for him to get off of work.

He rushed home, I burned a new disc, then I hustled back to my place to repair my system, not! My laptop wouldn't boot up the new disc either! I tried everything, cleaning the lazar, took the drive out and reseated it, tried cleaning the contacts...it still wouldn't boot! It turned out my drive had crapped out. Damn!!!

Lucky for me, that there's a Dell wholesale parts place that stocks parts for old laptops like mine, because there's demand still in South America and the Caribbean, but it's back across town near where my friend lives. So I hopped back in my car, managed to get there 5 mins before they closed and I was able to get a replacement drive that was pulled from a year newer model that fits my laptop..

I got the new drive home, installed it, then put in the disc and crossed my fingers. Thankfully it worked! I was able to chroot back into my system, and in the intervening hours @philm had released his updated solution into the repo. I was able to get my baby back up and running...So on the bright side, now I have Blu-ray DVD burner combo, which I didn't have before.

I just don't know If I'll be able to use it to watch Blu-ray discs though, I don't think I have enough CPU or GPU power, and I don't have any discs to try....

Anyhow the moral of the story is just like I had said in my previous post, if an update comes into the repo that won't update on it's own, don't mess with it!!! Just wait until the Devs come up with a workable solution. It's not worth hosing a working machine experimenting!!!

[philm]

@peaveyman

nvidia-utils: /usr/lib/nvidia/xorg/libglx.so exists in filesystem
nvidia-utils: /usr/lib/nvidia/xorg/libglx.so.1 exists in filesystem

These symlinks got created with my first attempt to adopt to the xorg-server changes. I removed it then and had to do some couple more fixes to get it running: manjaro-system, catalyst/nvidia-utils.

[BS86]

@sueridgepipe

Shouldn't this be OpenGL 4.5 now,

It is here:

glxinfo | grep core Preferred profile: core (0x1) Max core profile version: 4.5 OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.0.0

[FadeMind]

Ivybridge

[fademind@manjaro ~]$ glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.0.0
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 17.0.0
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 17.0.0
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

[sueridgepipe]

I assume OpenGL 4.5 support is predicated on gpu / driver support?

Virtualbox VM with mesa 17.0...

$ glxinfo | grep OpenGL
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.9, 256 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.0.0
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 17.0.0
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 17.0.0
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

Bare metal Optimus system running mesa 13.0.4 on Haswell gpu...

$ glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
OpenGL core profile version string: 3.3 (Core Profile) Mesa 13.0.4
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 13.0.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 13.0.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:

Will mesa 17.0 support OpenGL 4.5 on an intel Haswell gpu?

Bare metal Optimus system running mesa 13.0.4 on nvidia gpu...

$ primusrun glxinfo | grep OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 965M/PCIe/SSE2
OpenGL core profile version string: 4.5.0 NVIDIA 375.26
OpenGL core profile shading language version string: 4.50 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.5.0 NVIDIA 375.26
OpenGL shading language version string: 4.50 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:

Already supports OpenGL 4.5.

[philm]

Nvidia seems to work. Anyone still using Catalyst in our community?

[artoo]

@philm

Nvidia seems to work. Anyone still using Catalyst in our community?

Make poll with users visible.

[philm]

Seems Catalyst is totally broken due this change. Maybe I've to patch the old Xorg-Server also ...

[Testing Update] 2017-02-19 - Kernels, Mesa, Deepin, Haskell, ZFS, Nvidia

Thx for the report. This clarifies that fglrx driver has to go at some point. We added a new feature to have nvidia and mesa libglx files in parallel installed on the system. Followed patch does it: diff --git a/hw/xfree86/common/xf86platformBus.c b/hw/xfree86/common/xf86platformBus.c index fc17d15..0b5795f 100644 --- a/hw/xfree86/common/xf86platformBus.c +++ b/hw/xfree86/common/xf86platformBus.c @@ -40,6 +40,7 @@ #include "hotplug.h" #include "systemd-logind.h" +#include "loaderProcs.h" …

[philm]

We have to see now if a modified fglrx-outputclass.conf might solve the issue and games are still play-able. Seems the catalyst-server 1.17.4-4 does not result in the affect as expected by me ...

[kernelKurtz]

It would seem that this is solved, sort of.

I reinstalled today using aaditya's manjaro-xfce-openrc-17.0-rc-x86_64.iso of three weeks ago.

Going to update first thing, I got the error:
error: failed to commit transaction (conflicting files)
xorg-server: /usr/lib/xorg/modules/extensions/libglx.so exists in filesystem

... I followed artoo's advice upthread:

"Delete the symlink, upgrade packages, and run afterwards sudo mhwd-gpu --check"

The update completed and the check returned:
Using default
Default lib32 support: true
xorg configuration symlink valid...
libGl symlinks valid...

Also, during updating, the following appeared halfway through:

xorg configuration symlink valid...
libGl symlinks valid...
==> use mhwd-gpu to set catalyst as default: 'mhwd-gpu --setgl catalyst'
==> use mhwd-gpu to set mesa as default: 'mhwd-gpu --setgl mesa'

I haven't rebooted yet, but it looks like everything's cool.

[Christbkk]

Hi Guys,

I am new to Manjaro and have a new Lenovo Thinkpad with Manjaro on it. I let my IT Guy install it but now he is 6000KM away so I have to solve my problems alone. I get the follow error:

"Libglx.so exists already in the datasystem" ...

I am fine using the terminal and so on, but I want to put the right stuff inside to not kill my system.

Can anyone tell me what to do in 1. , 2. , 3.?

Thanks,
Christian

[Simorgh]

Hi all.

I have been away for more than 50 days so my system has not been updated during this time.
Ran the update by:
sudo pacman -Syyu
got

xorg-server: /usr/lib/xorg/modules/extensions/libglx.so exists in filesystem

did:
sudo pacman-mirrors -g && sudo pacman -Syyu

same result.

Any ideas?

Thank you in advance.

[kazuya]

Hi,
I finally got this error solved. Was going nuts.
I followed advices from this forum, especially this one [unstable] xorg-server libglx.so file conflict during mesa 17.0 update

I deleted the libglx.so in the /usr/lib/xorg/modules/extensions/ folder. And after this my update went successful. Some people are renaming this file libglx.so, which might be a safer alternative (I wouldn't know)

In KDE I just right clicked the file and chose root actions --> delete.
In Deepin I went back one folder to the modules folder, right clicked on extensions folder and chose 'open as administrator'. After this you can rename or delete.

[sueridgepipe]

@Simorgh

xorg-server: /usr/lib/xorg/modules/extensions/libglx.so exists in filesystem

Manually remove this link and update again.