[SOLVED] Can you upgrade Slackware 14.2's video driver without breaking the entire x/?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Can you upgrade Slackware 14.2's video driver without breaking the entire x/?
Hello. I just bought a new laptop, ASUS TUF FX505DU and, obviously, wanted to install Slackware on it. I just took the SSD from my old laptop, tweaked some settings, and successfully booted the system. Unfortunately, stock Slackware 14.2 kernel doesn't seem to support a lot of things on the new laptop. But when I booted alienBOB's Slackware Live everything seemed to work just fine, so I just took the kernel from there and the result was better. However, I still couldn't start X, so I started investigating.
On stock kernel even KMS didn't work, so I assumed it was the kernel module. And indeed, after upgrading to Slackware Live's kernel the console was nice and high resolutioned. But kernel module alone isn't enough to start X. xf86-video-amdgpu was too old to support AMD Ryzen 7 3750H. Same for Nvidia GeForce GTX 1660Ti: xf86-video-nouveau was too old. And for proprietary driver I use bumblebee which isn't any good for using with X11, not that I would've liked to use Nvidia card as a primary one. So the only way seems to be upgrading.
I tried to compile the sources of xf86-video-amdgpu from -current, but that required newer libdrm. I assumed upgrading that would break a lot of things, so I didn't, and here I am.
To reiterate my question, can I upgrade the video driver (xf86-video-amdgpu) without breaking and rebuilding the entire x/? Or would it be much more hassle than switching to -current? Personally, I like everything to just work, so I stick to stable releases, and -current occasionally breaks things, especially third-party packages, and I can't be bothered to fix those every time Pat releases some major library update, but 14.2 is way too old at this point, and 15 doesn't look like it's gonna be released any time soon.
Sorry if I got some packages' names wrong, I'm writing from memory as, well, I can't really post from Slackware.
I actually did just that over this weekend after additional promptings and some help in another thread (I'll have to try and remember to link it when I get home). I ended up upgrading libdrm, adding libedit (from SBo), upgrading llvm, then mesa, and finally xf86-video-amdgpu.
I stuck with particular versions due to others posting that they're likely to work without too much issue on 14.2, which were new enough for my card (RX570), but yours may need even newer, which might run into problems.
I grabbed SlackBuilds for the rest from Alien Bob's git instance for -current, grabbing the last versions that used autotools for libdrm and mesa, making sure to remove any code that removed .la files. I dug through the changelog to find the latest version of the llvm.SlackBuild used to build a 7.0.x version. For the amdgpu driver itself, I just grabbed the current x11 directory and built the amdgpu driver from there. I don't think I had to make any adjustments to it.
However, you may require newer versions of mesa, which would require newer llvm and libdrm, so it may add a lot more work on your end.
I've never tried this but pkgsrc (NetBSD's package manager but made portable to other systems) does include modular Xorg. I've seen it mentioned on older NetBSD mailing list threads as a way to try newer drivers on NetBSD (with 9.0 less recommended I think since its base tree Xorg is pretty up to date, it having just been released this year), but I suppose it should also install on Linux given pkgsrc's goals. That could be a low risk way of trying to get a newer X installed, since it will be isolated into the /usr/pkg directory tree.
But I will warn you that recently I tried to install mpv from pkgsrc on slackware and hit some kind of libtool error while building. This could be just me and my setup, though. I haven't investigated yet. I was able to install pkgsrc's youtube-dl package without issue, but that's only a python script.
This is what my error looked like in case anyone is curious (or wants to help me, whoops, thread hijack, don't do that, I'll figure it out when I need this to be installed):
Quote:
CCLD libxslt.la
/bin/grep: /usr/local/pkgsrc/textproc/libxslt/work/.buildlink/lib64/liblzma.la: No such file or directory
/bin/sed: can't read /usr/local/pkgsrc/textproc/libxslt/work/.buildlink/lib64/liblzma.la: No such file or directory
libtool: error: '/usr/local/pkgsrc/textproc/libxslt/work/.buildlink/lib64/liblzma.la' is not a valid libtool archive
Makefile:543: recipe for target 'libxslt.la' failed
make[2]: *** [libxslt.la] Error 1
make[2]: Leaving directory '/usr/local/pkgsrc/textproc/libxslt/work/libxslt-1.1.34/libxslt'
Makefile:615: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/usr/local/pkgsrc/textproc/libxslt/work/libxslt-1.1.34'
Makefile:441: recipe for target 'all' failed
make: *** [all] Error 2
I've never tried this but pkgsrc (NetBSD's package manager but made portable to other systems) does include modular Xorg. I've seen it mentioned on older NetBSD mailing list threads as a way to try newer drivers on NetBSD (with 9.0 less recommended I think since its base tree Xorg is pretty up to date, it having just been released this year), but I suppose it should also install on Linux given pkgsrc's goals. That could be a low risk way of trying to get a newer X installed, since it will be isolated into the /usr/pkg directory tree.
But I will warn you that recently I tried to install mpv from pkgsrc on slackware and hit some kind of libtool error while building. This could be just me and my setup, though. I haven't investigated yet. I was able to install pkgsrc's youtube-dl package without issue, but that's only a python script.
This is what my error looked like in case anyone is curious (or wants to help me, whoops, thread hijack, don't do that, I'll figure it out when I need this to be installed):
.la files in /usr/lib{,64}/ have been removed from -current and all SlackBuilds from -current remove them if they're generated. Also meson builds don't generate .la files. This was one of the roadblocks I ran into when I had previously tried upgrading my graphic stack.
Mako-1.1.0 (from SBo; version from -current only builds for python3)
mesa-19.0.8 (SlackBuild for 19.0.6 from alienBOB's -current git repo)
xf86-video-amdgpu-19.1.0 (from -current)
Took a bit of work, but huge thanks for the solution! After building everything I was able to run X server as usual.
However, a lot of applications just segfault now, like Firefox, Vivaldi, Seamonkey, Thunderbird, Telegram, uGet, xfce4-pulseaudio-plugin etc. Apps from KDE work, though, such as KTorrent or Konqueror, Pidgin also works. I suspect some libraries that are indirectly relied on got upgraded in the process, but which ones? ldd doesn't help. Do you by any chance have a solution for that?
I forgot to mention that I disabled glvnd on my mesa, so I didn't need to build any of the requirements for that (which I'm guessing is libclc, libglvnd, and mako).
I do know that Firefox is working fine on my system (my primary browser is Chrome, but I did open Firefox as well). I don't use any of the others mentioned. Have you had any meaningful messages if you start those applications in the terminal?
I forgot to mention that I disabled glvnd on my mesa, so I didn't need to build any of the requirements for that (which I'm guessing is libclc, libglvnd, and mako).
I tried adding "--disable-libglvnd", but Mako and libclc were still required.
Quote:
Originally Posted by bassmadrigal
I do know that Firefox is working fine on my system (my primary browser is Chrome, but I did open Firefox as well). I don't use any of the others mentioned. Have you had any meaningful messages if you start those applications in the terminal?
Unfortunately, no, otherwise I would've had some sort of direction where to search. Applications just silently segfault, aside from some usual messages (depending on the app) that appear even when they work. Also, Chrome doesn't start either.
I tried adding "--disable-libglvnd", but Mako and libclc were still required.
My mistake. I already had them installed (possibly from a previous attempt at upgrading). I do also know that my 14.2 install isn't completely up to date (last update contained updates from 9 APR 2020), but I am running a 5.4.51 kernel
Quote:
Originally Posted by fsLeg
Unfortunately, no, otherwise I would've had some sort of direction where to search. Applications just silently segfault, aside from some usual messages (depending on the app) that appear even when they work. Also, Chrome doesn't start either.
Unfortunately, I'm not sure where to point you from here.
Someone else might be able to provide some advice on using strace or gdb to find more info, but I am not familiar enough with those to provide any pointers.
.la files in /usr/lib{,64}/ have been removed from -current and all SlackBuilds from -current remove them if they're generated. Also meson builds don't generate .la files. This was one of the roadblocks I ran into when I had previously tried upgrading my graphic stack.
I'm not in current though but in 14.2, so it must be something else. I'll make a new thread if I can't figure it out and if it's not completely unrelated to slackware. Probably is a pkgsrc + local pkg-config or other messed up configuration on my part.
I see the Slackware libtool library in xz's contents file and in ...lib64/:
Code:
20109r2:packages$ grep liblzma /var/adm/packages/*
/var/adm/packages/aaa_elflibs-14.2-x86_64-23:lib64/liblzma.so.5.2.2
/var/adm/packages/xz-5.2.2-x86_64-1:lib64/liblzma.so.5.2.2
/var/adm/packages/xz-5.2.2-x86_64-1:usr/lib64/liblzma.la
/var/adm/packages/xz-5.2.2-x86_64-1:usr/lib64/pkgconfig/liblzma.pc
20110r0:packages$ ls -l /usr/lib64/liblzma*
-rwxr-xr-x 1 root root 912 Oct 31 2015 /usr/lib64/liblzma.la*
lrwxrwxrwx 1 root root 24 Nov 24 2016 /usr/lib64/liblzma.so -> ../../lib64/liblzma.so.5*
20111r0:packages$ ls -l /lib64/liblzma*
lrwxrwxrwx 1 root root 16 Nov 24 2016 /lib64/liblzma.so.5 -> liblzma.so.5.2.2*
-rwxr-xr-x 1 root root 168312 Oct 31 2015 /lib64/liblzma.so.5.2.2*
But I'd think pkgsrc would be using its own version. Maybe it's from me defining PREFER_NATIVE=yes in pkgsrc's mk.conf.
it may be worth mentioning that llvm 8.0.1 is in /extra (which is needed for more recent firefox builds)
Yeah, and nodejs, and rust, and ...
What, no golang, haskell, common lisp, clojure, and eiffel? Surely they could at least squeeze in a smalltalk vm somewhere. What are these mozilla developers doing all day?
Starting program: /usr/bin/uget-gtk
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffec4eb700 (LWP 17826)]
Thread 1 "uget-gtk" received signal SIGSEGV, Segmentation fault.
0x00007ffff49f7e2f in rawmemchr () from /lib64/libc.so.6
strace spits a lot of strings about libGLX_indirect.so being missing before the app segfaults:
Code:
open("/usr/lib64/../lib64/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=384740, ...}) = 0
mmap(NULL, 384740, PROT_READ, MAP_PRIVATE, 5, 0) = 0x7f08f744d000
close(5) = 0
open("/lib64/tls/x86_64/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/tls/x86_64", 0x7fff345827e0) = -1 ENOENT (No such file or directory)
open("/lib64/tls/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/tls", 0x7fff345827e0) = -1 ENOENT (No such file or directory)
open("/lib64/x86_64/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/x86_64", 0x7fff345827e0) = -1 ENOENT (No such file or directory)
open("/lib64/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
open("/usr/lib64/tls/x86_64/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/tls/x86_64", 0x7fff345827e0) = -1 ENOENT (No such file or directory)
open("/usr/lib64/tls/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/tls", 0x7fff345827e0) = -1 ENOENT (No such file or directory)
open("/usr/lib64/x86_64/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/x86_64", 0x7fff345827e0) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64", {st_mode=S_IFDIR|0755, st_size=274432, ...}) = 0
munmap(0x7f08f744d000, 384740) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
+++ killed by SIGSEGV +++
This library, libGLX_indirect.so, doesn't seem to belong anywhere in the system: it's not part of mesa, it's not part of xorg, it's not even part of nvidia drivers (but it was at one point as some of my backups point out). This very system worked fine on my old laptop, so it must be something to do with upgraded mesa.
Also, when in console mode, trying to start the app says about no display available (as expected), instead of segfaulting right away.
Last edited by fsLeg; 07-18-2020 at 09:08 AM.
Reason: Added about console mode.
Hello fsLeg. You likely know this but just in case, if you are using nVidia proprietary drives and wish to upgrade Mesa, it's important to reinstall nVidia drivers after any Mesa upgrade.
Hello fsLeg. You likely know this but just in case, if you are using nVidia proprietary drives and wish to upgrade Mesa, it's important to reinstall nVidia drivers after any Mesa upgrade.
I mentioned that since it's a laptop, Nvidia is in optimus mode, therefore Nvidia drivers are installed via bumblebee which is no good for X11 and have all libraries under nvidia-bumblebee directory. Right now I'm trying to make everything work with integrated graphics.
So far my conclusion is that only apps that directly or indirectly rely on OpenGL segfault, others work fine. Which, now that I think about it, might mean mesa-19.0.8 isn't new enough... Although X server works fine with it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
