You are not logged in.
Hi, wondering if someone can help me get to the bottom of an error that happened after I did an upgrade.
google-chrome and chromium both give a runtime error:
$ google-chrome-stable
/opt/google/chrome/google-chrome: symbol lookup error: /usr/lib/libgbm.so.1: undefined symbol: drmGetDevice2
Everything seems to up to date, including libdrm:
$ yaourt -Q | grep drm
multilib/lib32-libdrm 2.4.101-1
extra/libdrm 2.4.101-1
Was scratching my head for hours now... google is not helpful, or maybe I can't find a place where to look...
Any suggestions are appreciated
Thanks in advance
Last edited by megabeaver (2020-05-23 00:07:44)
Offline
Paste your pacman.log
Offline
Offline
Why are you habitually using -Rdd to remove packages?
Offline
you are right, I should probably not... should read the docs to see the difference
Offline
┌─[Centurion ~]
└─╼ pacman -F /usr/lib/libgbm.so.1
usr/lib/libgbm.so.1 is owned by extra/mesa 18.0.4-1
Offline
yes, mesa is up to date as well, or are you suggesting to downgrade?
$ yaourt -Q | grep mesa
multilib/lib32-mesa 20.0.7-3
extra/mesa 20.0.7-3
Offline
you are right, I should probably not... should read the docs to see the difference
That's an enormous understatement. Regularly using -Rdd is will cause all sorts of problems that will gradually crop up over time until you fix everything you broke. One of the main purposes of a package manager is to manage dependencies - by using -Rdd your completely preventing pacman from being able to do this. I had to just tinker a bit to even figure out a way to find all the things that may be broken by regularly using those flags. There is no option in pacman to really check for this ... presumably because no one should ever get themselves in this situation in the first place. I came up with two potential solutions (to the various still hidden problems, not just the one in this thread). First, you could reinstall all packages (but this is not the best approach):
pacman -Qnq | pacman -S -
This will pull in any missing dependencies, but it's a bit overkill (perfectly safe, but it will do a lot of needless work).
Another would be to reinstall as dependencies anything you removed with -Rdd, then check which are actually unneeded (orphans) and remove those:
sed -n "s/.*-Rdd \([^']*\).*/\1/p" /var/log/pacman.log | sort -u | pacman -S --asdeps -
pacman -Qdtq | pacman -Rsn -
Alternatively, you could just go about as you are, and a few days or weeks from now you'll be "scratching your head" for hours again, then you'll post another thread, and patch up that incident too only for it to come up again days or weeks later, etc, etc.
EDIT: despite the -Rdd's causing problems, there may be (additional) sources of trouble here. Please post the output of the following:
ldd /usr/lib/libgbm.so.1
Last edited by Trilby (2020-05-22 23:58:10)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
thanks guys, I get the point. no more pacman -Rdd.
Reading up through the docs right now
$ ldd /usr/lib/libgbm.so
linux-vdso.so.1 (0x00007ffcf67e4000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fe73178e000)
libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x00007fe73157f000)
libwayland-server.so.0 => /usr/lib/libwayland-server.so.0 (0x00007fe731569000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fe731563000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007fe73141e000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007fe7313ee000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007fe7319c6000)
libffi.so.7 => /usr/lib/libffi.so.7 (0x00007fe7313e0000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fe7313be000)
Thank you for the help
Offline
There's your problem. What is /usr/local/lib/libdrm.so.2? Where is it from and can you remove it?
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
thanks so much guys!!!
$ pacman -F /usr/lib/libdrm.so.2.4.0
usr/lib/libdrm.so.2.4.0 is owned by extra/libdrm 2.4.101-1
$ pacman -F /usr/local/lib/libdrm.so.2.4.0
$
Offline
No package should ever own anything in /usr/local - certainly no package in the repos, so `pacman -F` could never return a result for anything under /usr/local. The question is, how'd it get there in the first place? Presumably you were installing things with `sudo make install`. If so, you should get rid of everything else you installed that way or - as with -Rdd - it will come back to bite you again later.
Get to the root of the problem, don't just patch up the current symptom.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
ok will do thanks so much
Last edited by megabeaver (2020-05-23 00:13:17)
Offline
Hi, another important point is that you still using yaourt, that is depecrated from a while, with many security and others issues including manage dependencies, you can read about it, and choice another AUR helper (or not, you can install your AUR packages manually)
Requesting official statement from developers · Issue #382 · archlinuxfr/yaourt · GitHub
KF5 & Plasma5 (git versions) - Awesome WM
ASUS Sabertooth 990FX - AMD FX8350 - ATI Radeon HD 7970
[testing] repo
Offline
good to know, thank you!
Offline
I had to just tinker a bit to even figure out a way to find all the things that may be broken by regularly using those flags. There is no option in pacman to really check for this ... presumably because no one should ever get themselves in this situation in the first place. I came up with two potential solutions (to the various still hidden problems, not just the one in this thread). First, you could reinstall all packages (but this is not the best approach):
pacman -Qnq | pacman -S -
This will pull in any missing dependencies, but it's a bit overkill (perfectly safe, but it will do a lot of needless work).
Another would be to reinstall as dependencies anything you removed with -Rdd, then check which are actually unneeded (orphans) and remove those:
sed -n "s/.*-Rdd \([^']*\).*/\1/p" /var/log/pacman.log | sort -u | pacman -S --asdeps - pacman -Qdtq | pacman -Rsn -
The only thing I can think of to check for this is:
paccheck --quiet --depends
Hi, another important point is that you still using yaourt, that is depecrated from a while, with many security and others issues including manage dependencies, you can read about it, and choice another AUR helper (or not, you can install your AUR packages manually)
Requesting official statement from developers · Issue #382 · archlinuxfr/yaourt · GitHub
Counterpoint: most AUR helpers aren't actively developed, and very few of them were written by people who have any idea how the AUR works. Case in point: people are always suggesting to move from yaourt to, of all insane recommendations, *pacaur*. At least yaourt hasn't ever deliberately said "screw users, let's deliberately do the stupidest, most incorrect thing possible just for the lulz".
And to be brutally honest, every AUR helper seems to be a badly designed yaourt clone.
The exception is, as always, aurutils, which instead forces people to undergo allergic reactions by reading manpages.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Hi, another important point is that you still using yaourt, that is depecrated from a while,
And to be brutally honest, every AUR helper seems to be a badly designed yaourt clone.The exception is, as always, aurutils, which instead forces people to undergo allergic reactions by reading manpages.
yeah... personally I prefers manually option ... Download pkg files from AUR and then makepkg and install ;-) ... is cleaner and safest way to known my system and what I do with unnoficial packages.
KF5 & Plasma5 (git versions) - Awesome WM
ASUS Sabertooth 990FX - AMD FX8350 - ATI Radeon HD 7970
[testing] repo
Offline
What I'm actually trying to say is it is perfectly fine for people to use yaourt... the only crime it's committed is having been declared EOL by its developers. In all other respects it's neither better nor worse than other AUR helpers.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline