You are not logged in.
Hey,
I ran pacman -Syu today but there's a problem with the nvidia driver:
Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
warning: dependency cycle detected:
warning: nvidia-libgl will be installed before its nvidia-utils dependency
Packages (6) lib32-libglvnd-0.0.0.20160210-1 lib32-nvidia-libgl-361.28-2 lib32-nvidia-utils-361.28-2 libglvnd-0.0.0.20160210-1
nvidia-libgl-361.28-2 nvidia-utils-361.28-2
Total Installed Size: 218.58 MiB
Net Upgrade Size: -0.16 MiB
:: Proceed with installation? [Y/n]
(6/6) checking keys in keyring [################################################] 100%
(6/6) checking package integrity [################################################] 100%
(6/6) loading package files [################################################] 100%
(6/6) checking for file conflicts [################################################] 100%
error: failed to commit transaction (conflicting files)
libglvnd: /usr/lib/libGL.so.1 exists in filesystem
lib32-libglvnd: /usr/lib32/libGL.so.1 exists in filesystem
Errors occurred, no packages were upgraded.
Any idea how to solve this?
Last edited by Barghest (2016-02-10 19:42:47)
Offline
Offline
Thank you!
I took a long break from Arch (new job, no more linux etc.) and I'm impressed/overwhelmed how the wiki has changed. So much more information.
Offline
Came here for this issue aswell.
$ pacman -Qo /usr/lib/libGL.so.1
error: No package owns /usr/lib/libGL.so.1
$ pacman -Qo /usr/lib32/libGL.so.1
error: No package owns /usr/lib32/libGL.so.1
However, libGL.so.1 is a symlink to libGL.so.361.28, which is owned by nvidia
$ pacman -Qo /usr/lib/libGL.so.361.28
/usr/lib/libGL.so.361.28 is owned by nvidia-libgl 361.28-1
As the wiki page explains, I renamed these two links then ran the update. It went well, and now it sais this:
$ pacman -Qo /usr/lib/libGL.so.1
/usr/lib/libGL.so.1 is owned by libglvnd 0.0.0.20160210-1
$ pacman -Qo /usr/lib32/libGL.so.1
/usr/lib32/libGL.so.1 is owned by lib32-libglvnd 0.0.0.20160210-1
Edit: I rebooted the system, all went well. Went to delete the renamed files I just made, but I think they were autodeleted? Oh well, problem solved!
Last edited by raggerv8 (2016-02-11 08:07:10)
Brottweiler@#archlinux
Offline
I had the same experience as raggerv8 with this issue. It made me a little bit nervous seeing files in /usr/lib which were showing as being unowned an in conflict with pacman but I didn't get any issues after moving them. The backup versions also removed themselves in my case. A little hiccup with something or another but I guess not too bad since everything seems to be working fine now.
If quantum mechanics hasn't profoundly shocked you, you haven't understood it yet.
Niels Bohr
Offline
I just wonder how come more people have the /usr/{lib,lib32}/libGL.so.1 present in their filesystem but not owned by any package. So for all of us the pacman database got corrupted in the same way that the same file was left over in our systems? Sounds unlikely to me.
mesa-libgl, lib32-mesa-libgl, nvidia-libgl<=361.18-2 and lib32-nvidia-libgl<=361.18-2 created the libGL.so.1 links, I wonder which package forgot to clean that file up. How can a file that was created on package install get left over on package removal/update anyway? Just out of curiosity.
Offline
I'm in the same boat, it's not owned by any package. Is it safe to remove the symlinks?
Last edited by jerbear64 (2016-02-11 12:57:05)
Offline
I just wonder how come more people have the /usr/{lib,lib32}/libGL.so.1 present in their filesystem but not owned by any package. So for all of us the pacman database got corrupted in the same way that the same file was left over in our systems? Sounds unlikely to me.
mesa-libgl, lib32-mesa-libgl, nvidia-libgl<=361.18-2 and lib32-nvidia-libgl<=361.18-2 created the libGL.so.1 links, I wonder which package forgot to clean that file up. How can a file that was created on package install get left over on package removal/update anyway? Just out of curiosity.
Likely created by ldconfig. If a library sets an soname but threre's no symlink for it present, ldconfig will created it. Since that's being done outside of pacman, pacman has no way to track it.
Last edited by Scimmia (2016-02-11 14:57:46)
Offline
Whoops, I was so focused on the packages I totally forgot about ldconfig. Thanks Scimmia!
jerbear64: if these files are not owned by any package, then yes. if they are owned by a package (such as mesa-libgl because you're using for example bumblebee) and you ran into https://bugs.archlinux.org/task/48123, then you shouldn't remove them, that got fixed with the latest {lib32-,}nvidia-utils, {lib32-,}libglvnd.
Offline
Whoops, I was so focused on the packages I totally forgot about ldconfig. Thanks Scimmia!
jerbear64: if these files are not owned by any package, then yes. if they are owned by a package (such as mesa-libgl because you're using for example bumblebee) and you ran into https://bugs.archlinux.org/task/48123, then you shouldn't remove them, that got fixed with the latest {lib32-,}nvidia-utils, {lib32-,}libglvnd.
Well, I'm not using bumblebee, so I'll delete them and see how it goes.
Offline
unlink /usr/lib32/libGL.so.1
unlink /usr/lib/libGL.so.1
pacman -Syyu
Offline
unlink /usr/lib32/libGL.so.1
unlink /usr/lib/libGL.so.1
pacman -Syyu
I can't believe that solution is so easy - i have the same problem with nvidia on another Arch machine. Will try it. Thanks.
In fact, it is not my first time with "something exists in filesystem" but always i could update, remove it. Now removing does nothing.
Last edited by firekage (2016-03-29 14:49:17)
Offline