Broken AMD drivers on opensuse....need halp!

I am using opensuse tumbleweed with the 3.19.3 kernel.

I installed AMD drivers on tumbleweed before on kernel 3.18 and all I had to do was switch the display manager from gdm to lightdm.

I did a fresh install with 3.19 and I am not having the same luck. I am able to boot into a terminal, and I have the ability to launch yast and even to uninstall the drivers and revert back to the opensource drivers. So I am not totally screwed over....but I am close to it.

Now an error message is spit out on the terminal when I try to startx and it says something about UID. IDK what Linux is talking about.

Am I supposed to feed it a kernel parameter or something?

And I am an idiot and forgot about the Linux help desk subforum. If a mod wants to move this, feel free and sorry for the trouble in advance.

UID = User ID
The proprietary drivers require special kernel modules to be loaded, modules that (as of February - this may have changed since I last checked) do not work with 3.19.x kernels. Try running startx as root and see how that goes. I'll check in on this thread in the morning when I can actually think. I'm going to strongly recommend that you get off Tumbleweed and onto a "standard" release like 13.2 if you are going to be using the proprietary GPU drivers - it'll save you a headache or two.

I actually tried that before posting and I got the same problem.

I would also love to be on the main stable release for more than 1 reason. The problem is that my root partition is in btrfs and the 3.18+ kernel fixes some bugs I was having with the root folder.

Do you know specifically what patch solved your root bugs? I can dig through the linux-kernel mailing list and see if they are planning on backporting the fix to older stable kernels.
In the meantime you could boot from a snapshot from prior to installing the proprietary drivers and use snapper rollback, so at least you will have a working system.

Absolutely no clue.

See normally I leave my computer on all the time, and when I did that I had no issues. But as of late I have been helping more people around me with windows and mac problems, so I am now turning off my computer a lot more.

When I restart my computer and go into windows or OSX and then come back to linux, it would not boot. I would have to load a live disk and then use gparted to correct any errors on the root partition. Then it would boot.

I had read in an article that newer kernels had better support for btrfs, so I gave it a shot and it worked.

IDK why or how. It could literally be nothing other than luck.

What errors did you have to fix? Exactly what did you do to fix them? btrfs scrub?

There were no errors. It would just say Loading linux kernel and then just flash to black and reboot.

To fix it I loaded a opensuse live USB, then opened up gparted, and checked the root partition for errors.

I rebooted and everything was fine. This happened 3 times.

The kernel not booting thingy is probably due to wrong permissions of some kind purporting to the live kernel update feature. Since 3.19, the kernel is updated during the session, and the bootloader is refreshed in that process. If zypper can't access some files with full write access, I expect that an error like that would occur at reboot.

My guess is that by rebooting after a live boot, the install just snaps back to a working RO snapshot, which is what it's configured to do when there are problems.

OpenSuSE offers the possibility to ignore a failing startx. It may happen that X fails to start when the kernel modules have not been patched yet. Only use the packages by Siebert (sebastian-siebert.de), because those contain the latest patches on the latest fglrx modules. If startx fails, just Ctrl-Alt-F1 to TTY1, login, then snap back to the last working snapshot with snapper. You can list the snapshots, they are listed by number and have a description next to them showing what changes were made right after that snapshot was taken by the system (like zypper install or zypper update). To rollback, just enter as root "snapper rollback NNN" with NNN being the number next to the snapshot you want to rollback to (e.g. "snapper rollback 345", so without the "#" before the number, the hashtag is in the list of snapshots, but doesn't have to be put into the rollback command). Then reboot, and the system will be rolled back, and you don't lose any time, and can take a look at the debug journal for what went wrong.

I wouldn't recommend fglrx at this point in time. The performance benefit is marginal, and the extra features are even more marginal, because compiling the proprietary kernel modules into your kernel, disables the new amd HSA modules that are already in the kernel, that are made to work with the amdgpu driver that will come out very very shortly, in fact, any moment now.

Even when the amdgpu driver isn't there yet, you'll see that you get about the same fps in games like CS:GO in linux as you would in Windows (that's with fps_max 999 etc..., system set up as if it were for competitive play), and that's with the open source radeon driver in linux. Switching to the fglrx driver in linux, brings absolutely no fps benefit at all in CS:GO, but increases overhead, so the actual fps will drop a few frames in known problematic stages.

I get that not everyone is interested in HSA, and that fglrx might be what some users want to use, but it's also a dying development, and the open source kernel modules are the way forward with AMD GPU's in linux, so don't expect a great deal of effort from devs to keep the proprietary kernel modules patched for every kernel update, because every kernel update might be the last for which fglrx is even relevant lolz.

I would recommend uninstalling fglrx completely, and going for radeon all the way, to have a clean system for the next kernel upgrade, which will offer the choice of a completely new proprietary or the radeon driver, both using the open source kernel modules. When that comes, the proprietary kernel modules used by fglrx will be a potential source of trouble or loss of performance and/or features, so in my opinion it's better to get rid of them.

1 Like

Agreed about zoltans radeon recommendation. Can't wait for amdgpu.

But if that's not an option for this immediate moment your likely on the older fglrx driver which doesnt work with Linux 3.19. The fglrx 15.* driver works and you should see if you can get that installed.

I'd look it up but I'm on my phone atm.

I will see what happens in the morning. My main concern are games like bioshock infinite and openGL performance in general.

I know amd struggles with this, and if it becomes a problem, then I will just see if anyone wants to trade a 290x for a 770 or 960 or something.

Yeup. Open Drivers only support open gl 3.3.

booooooooo.

Hopefully the amd gpu drivers will be out soon.

They've been out for a while under NDA. Basically it's waiting for Windows X and DX12, feature parity and all that crap you know... Linux 4.0 is also nothing else than a number; the actual kernel version has also been out for a while, publicly then. All the guys running kernel 3.19 have the amdkfd stuff on board, amdgpu will basically tie into the very same kernel modules that are already there and usable for opencl stuff on kaveri. It's just a matter of politics, AMD does the XBone chips, they can't roll over Microsoft lolz...

Lol. It kind of sucks but hey, at least they are kind of sort of supporting linux.

God damn it is so frustrating through. I REALLY want to love AMD. I really really do. I am even having troubles with AMD drivers on windows. Seriously, how can these guys literally suck so hard at making software?

I really hope the AMDgpu drivers change my mind.

Anyways, if amd is waiting for the software world to move forward. then II am going to assume the drivers would be out around computex time? Is that a fair assumption would you say?

hmmmmmmm well after reading forums for like 4 hours I decided to test out a theory.

I got fglrx working with the 15.03 beta drivers on the 3.19 kernel.

IDK how long this is going to last, and I will probably go back to the open drivers before the week is done, but they do actually work.