[SOLVED] warzone2100 sbo on 14.1 with ati R7 graphics not working.

timsoft · 04-29-2015, 09:33 AM

I hadn't created a blacklist entry in /etc/modprobe.d/ (assuming the proprietary driver would do it for me. creating a blacklist entry as per
here did not make any noticeable difference.
/usr/share/ati/fglrx-install.log didn't show anything unusual.

I then tried reinstalling fglrx again using the direct install instead of create package method. This worked ! :-)

I have tried running the installer directly on both 32bit and 64bit slackware 14.1 and now there are no errors running glxinfo, or warzone2100 etc.

Thanks for all the suggestions. It would appear that the "create a package" function of the driver is broken (at least for slackware 14.1).
I'll try and report it to AMD, maybe they will fix it. There must be some more differences apart from creation of the blacklist entry which the direct installer does and the package creator does not do. thanks pataphysician and reaperX7 for your help. I will email slackdocs-admin to see if the howto can be updated.

pataphysician · 04-29-2015, 10:18 AM

I think when you make a slackware package, the fglrx installer doesn't make the blacklist file, whereas if you don't it will, if one doesn't already exist.

I doubt AMD will do anything, except maybe remove the code for slackware package creation completely. I'm pretty sure it's just in there because it made sense in the early days of the driver, and no one has bothered to remove the code, I doubt they would want to waste any time maintaining it, but who knows.

Also it might only be broken for newer cards, I would actually have to go through and test again, but I believe back when I was looking at this before, that my computer with an onboard 6000 series radeon, worked fine with multilib while using the make slackware package method. Where as I could never get it to work with my R9.

ReaperX7 · 04-29-2015, 12:09 PM

The packager works, but you still have to do some grunt work really. Highly surprised we do not have a SlackBuild for this on SBo.

timsoft · 04-29-2015, 01:35 PM

to ReaperX7. what extra work do you have to do after using the packager?. I tried the blacklisting, but that on it's own was not sufficient to get it working, at least with my R7 (A8 APU). I will test with a HD8370D (A4 APU) tomorrow, to see if package creation and blacklist entry is sufficient. If not, that will be 2 ati gpu's that don't work with package creation "out of the box".

bassmadrigal · 04-29-2015, 01:55 PM

If you're really curious what the differences between the slackware package and the actual installation directly from the blob, you can use overlayfs (needs a 3.18 kernel with it compiled in) to show you everything the blob would install into the system (overlayfs allows you to put to overlay a folder over the / partition with all files still visibile, but any modifications would reside in the folder lying on top of the root folder). See this post for more information.

http://www.linuxquestions.org/questi...ml#post5313014

If you really wanted, you could just create a Slackware package from the resulting changes that reside in the overlaid folder.

ReaperX7 · 04-29-2015, 07:50 PM

Quote:

Originally Posted by timsoft

to ReaperX7. what extra work do you have to do after using the packager?. I tried the blacklisting, but that on it's own was not sufficient to get it working, at least with my R7 (A8 APU). I will test with a HD8370D (A4 APU) tomorrow, to see if package creation and blacklist entry is sufficient. If not, that will be 2 ati gpu's that don't work with package creation "out of the box".

With the packaging you still have to create the /etc/modprobe.d/RADEON-blacklist.conf file that will contain:

Code:

blacklist radeon
blacklist r128

As well as do a backup of the Xorg drivers as needed.

Check the fglrx package after it's creation and search for any duplicate files in the native system. If you find any, append an -xorg to the extension name of the file (this is similar to Nvidia's driver but Nvidia's is automated) to preserve it.

Next, delete any symlinks for these such as libGL.so.1 libGL.so.1.0.1, but record what they are and what they were symlinked to. Now install the driver. If any symlinks aren't recreated, create them now as needed if the fglrx based file exists. If not, ignore it.

timsoft · 05-01-2015, 11:40 AM

well, I have the results of my test at least for 32bit slackware 14.1
Installing direct works fine. if you create the (slackware) package there are some extra things that need to be done (as root) in order for things to actually work.
first move to the directory you downloaded amd-catalyst-omega-14.12-linux-run-installers.zip
(I had problems with running the installer from a cifs mount, but copying the file to /tmp works fine)

Code:

unzip amd-catalyst-omega-14.12-linux-run-installers.zip
cd fglrx-14.501.1003
./amd-driver-installer-14.501.1003-x86.x86_64.run

select to create a package.
wait for several minutes, till it's done.

Code:

installpkg fglrx-14.501.1003-x86-1.tgz

now for the extra's...

Code:

echo "blacklist  radeon">/etc/modprobe.d/blacklist-fglrx.conf
mkdir -p /usr/lib/dri
mv /usr/lib/xorg/modules/dri/fglrx_dri.so /usr/lib/dri/
ln -s /usr/lib/dri/fglrx_dri.so /usr/lib/xorg/modules/dri/fglrx_dri.so
ln -s /usr/lib/libXvBAW.so.1.0 /usr/lib/dri/fglrx_drv_video.so
cd /usr/lib
rm libGL.so.1
ln -s libGL.so.1.2 libGL.so.1
aticonfig --initial

then reboot (to allow the module blacklisting to take place so that the proprietary drive can load)
I'll try and test this on slackware 14.1 64bit (with the path no doubt modified to /usr/lib64 ) over the weekend. If the solution works for 64bit as well, I'll post it on the howto.

bassmadrigal · 05-01-2015, 03:01 PM

Quote:

Originally Posted by timsoft

I'll try and test this on slackware 14.1 64bit (with the path no doubt modified to /usr/lib64 ) over the weekend. If the solution works for 64bit as well, I'll post it on the howto.

Instead of the howto, you seem most of the way there with a slackbuild. Maybe it would be worth creating the slackbuild and submitting it to slackbuilds.org for easy use by others

BTW, great job getting it all figured out!

timsoft · 05-06-2015, 10:01 AM

the tricky part is undoing the changes on uninstallation of a slackbuild. I'm not sure if/how removepkg handles links created in the doinst.sh file. It would be nice to warn the user on uninstallation that they have to reboot in order to reload the opensource radeon drivers. there may also be a problem with the opengl files. I noticed that if the package was installed twice, then that messed up restoring opengl. Having to test everything on real hardware also slows things down. I still haven't tested 64bit. other commitments have taken priority. Hopefully I'll get to it this week.

bassmadrigal · 05-06-2015, 12:30 PM

Quote:

Originally Posted by timsoft

I'm not sure if/how removepkg handles links created in the doinst.sh file.

According to this: "removepkg looks at the other installed packages and only removes files unique to the package you specify. It will also scan the postinstallation script for the specified package and remove any symbolic links that were created by it."

timsoft · 05-14-2015, 04:48 AM

well, I finally got tested on 64bit, and a part from changing dirs to /usr/lib64 instead on /usr/lib the extras I posted earlier work. I have also spotted the bug in the created slackbuild where _USING_X is declared, and then _USING_MODULE is used which causes a doinst.sh script error at line 67 on installation when X is not running at installation time. renaming the declaration _USING_X=0 to _USING_MODULE=0 fixes that problem. I'll see If I can track down the unofficial maintainer of that script (emanuele tomas) and see if he will fix it (along with the other fixes to make it work). If I have no joy, I might just write a re-packager slackbuild, which creates a package and then patches it. (it is easier than trying to edit (ati's) monolithic installer script.)

The key is that libGL.so finally links to /usr/lib{64}/fglrx/fglrx-libGL.so.1.2 (the ati one) and not /usr/lib{64}/libGL/so.1.2.0 (the mesa one)

timsoft · 06-08-2015, 05:41 AM

for anyone following this thread, It would appear that there may be more that is needed to be done. If anyone has feedback/comments on installing the amd/ati driver which would help, please leave them here. eventually I hope to get things working reliably on clean installs from a single package.

ReaperX7 · 06-08-2015, 05:50 PM

Be advised that the current 15.5 package does include a switchlibGL and switchlibglx utility set in /usr/lib${LIBDIRSUFFIX}/fglrx directory to backup and preserve the default mesa libraries.

I ran the packager on my system (even though I have an Nvidia GPU) to check the package build, and if you do in fact run the recommended Slackware build, it will build everything correctly. Be advised if you do revert to mesa, run the switchlibGL and switchlibglx utilities BEFORE you uninstall or upgrade the package.

JackHair · 06-09-2015, 12:07 AM

Quote:

Originally Posted by timsoft

for anyone following this thread, It would appear that there may be more that is needed to be done. If anyone has feedback/comments on installing the amd/ati driver which would help, please leave them here. eventually I hope to get things working reliably on clean installs from a single package.

What I do when I want fglrx:

Code:

When running X do an init 3 in a (root) console.
Run the installer and opt for install.
aticonfig --initial
Reboot.

Even when I run pure 64-bits, this works every time. Granted the installer doesn't need patches for a kernel.

timsoft · 06-09-2015, 03:51 AM

yes, I found that doing a direct install using the ati downloaded installer works every time; it is the (slackware) package creation that doesn't create a working solution. I have to do more investigation to see what the install option does that the package creation does not. the easiest way would be to run overlayfs, as bassmadrigal mentioned earlier, but that requires an updated kernel to a version that is not supported by the ati driver. (and would not be stock slackware either) just my luck!. I'll have to do things the slow way. thanks for the feedback.