Got a new motherboard and processor, the built-in graphics identify as RS780L (HD3000), AMD/Radeon. I decided this would be a good time to upgrade from 13.1 to 13.2.
Ran the upgrade, system rebooted, I got a black screen. None of the terminals (ex., CTRL-ALT-Fx) worked, either. I had to do a hard reboot, brought it back up in Recovery mode. Got the usual nasty-looking but serviceable GUI.
Then I made a mistake: I installed the fglrx current version (not legacy!), and had a time getting that thing purged. It creeps its tentacles all over the place
I’ve finally gotten it to work with the open-source radeon driver, but I can’t fix the aspect ratio. Samsung says the idea for my monitor (a 220wm) is 1680x1050. I’m at 1280 x 1024, so everything is stretched and ugly. OpenGL works, though – I can run Celestia and the “glxgears” test program just fine. But everything is stretched into an oval.
Bringing up KDE’s resolution setter tool shows that this is as high as it wants to go.
A little research shows that the ati fglrx-legacy driver isn’t supported after Opensuse 12.3.
Maybe you are still not using radeon. (OpenGL will work none-the-less, Mesa comes with a software renderer)
How did you install fglrx in the first place?
The RPM packages should be quite easy to remove completely. And the standard installer from AMD’s homepage does come with an uninstall function AFAIK.
Also try to rebuild the initrd, to make sure radeon is copied into it.
I used the one-click installer on one of the SDB:Radeon pages. My bad, I clicked to install the latest stuff, and my motherboard has a legacy chipset.
As for removing it, of course I went into Yast and tried. It kept giving me “confllict” errors. When I said, “look, just delete it and screw the conflicts,” it still wouldn’t do it. Maybe I missed something, but I’ve been using Suse since version 8.0, and the one-click installers for years.
I finally removed it manually in a terminal with zypper.
Thanks for the suggestion about mkinitrd. I didn’t think of that.
radeon does not work with “nomodeset”, it only supports KMS.
So remove “nomodeset” from the Kernel Parameters, in YaST->System->Boot Loader->Kernel Parameters e.g.
“nomodeset” effectively disables radeon.
I used the one-click installer on one of the SDB:Radeon pages. My bad, I clicked to install the latest stuff, and my motherboard has a legacy chipset.
As for removing it, of course I went into Yast and tried. It kept giving me “confllict” errors. When I said, “look, just delete it and screw the conflicts,” it still wouldn’t do it. Maybe I missed something, but I’ve been using Suse since version 8.0, and the one-click installers for years.
It should just work to remove all 5 fglrx packages in YaST.
I finally removed it manually in a terminal with zypper.
If you could remove it with zypper, it should have worked in YaST as well. They do the same thing.
Maybe those conflicts were unrelated, or maybe you even tried to uninstall a wrong package?
Anyway, that “nomodeset” is not added by the packages AFAIK, so they also do not remove it when you uninstall them.
Thanks for the suggestion about mkinitrd. I didn’t think of that.
I added the “nomodeset” just prior to this most recent reboot, trying to get an xorg log for you. The system will not boot without it. I get a black screen. The time previous, I even waited several minutes – more than enough time for a boot to complete – and was unable to get in with SSH. The system had hung.
As for the Yast thing, believe it or not, I think they’re related.
Remember: I have upgraded my motherboard and THEN tried to upgrade my Opensuse. Radically different hardware. I know from poking around among my config files that there are remnants of the previous install all through the system. For example: the config in X11 still showed my old Nvidia driver. Simply put, I think I’m getting conflicts.
I will try a clean install on a new hard drive. I’ll report back with how it went, probably tomorrow. I’ve got a gut feeling that my problem will be solved.
Then post /var/log/Xorg.0.log.old, that contains the log from the previous, i.e. failed, boot.
Instead of adding “nomodeset”, you could also select “Recovery Mode” in “Advanced Options” in the boot menu.
But to be able to help, we need the log from the failed boot.
This one is useless, as you actually disabled radeon.
As for the Yast thing, believe it or not, I think they’re related.
Related to what?
YaST should behave the same as zypper, as YaST uses the same underlying library (libzypp).
And I don’t see why anything should require fglrx to be installed.
But without seeing the conflict messages, it is impossible to tell what could have been the problem.
Remember: I have upgraded my motherboard and THEN tried to upgrade my Opensuse. Radically different hardware. I know from poking around among my config files that there are remnants of the previous install all through the system. For example: the config in X11 still showed my old Nvidia driver. Simply put, I think I’m getting conflicts.
Remember? You didn’t mention nvidia at all.
Remove the file /etc/X11/xorg.conf if it exists. If it still references the nvidia driver, Xorg will fail to load when it is not installed.
And if nvidia is still installed, you absolutely have to remove it too, as it breaks Mesa and therefore the radeon driver.
OK, that was indeed the problem. A clean install fixed it. The open source radeon driver seems to be working quite well, so I’m happy.
If anyone else should hit this thread in a search, there’s your answer (and frankly, I should have known better): if you’re changing hardware, don’t do an OS upgrade, you need to do a complete install.
I appreciate your help, and I probably didn’t word it correctly (I always try to keep my posts brief and to the point), but I assure you, I DID remove them. Now, I was unaware that “nomodeset” would cause radeon to not be loaded at all. I seem to recall that years ago, it would cause the BIOS video to be used up until desktop start, and which point the X server would load the appropriate driver. From a few Web seaches, I see that the newest kernels load the video driver during boot so that you can get fancy splash screens.
But I do assure you, I had removed radeon. As I said above, while I couldn’t get it removed with Yast (and you seem to think that I was doing something wrong; I don’t feel like arguing about it), I WAS able to remove it with Zypper. I tried several boots, with nomodeset and without, and the best I could get was a desktop with the incorrect resolution. When I ran “lsmod | grep radeon,” it showed that the driver HAD loaded – but the resolution was entirely wrong, and I couldn’t fix it. (I even tried some of the “xrandr” stuff I saw in a Web search).
No, speaking as someone with a LOT fo experience installing and using Linux (we generally use Red Hat/CentOS at work), the solution was indeed to do a complete, clean install. If you search this forum, you will see where others will recommend this all the time. It’s the quick fix. If you want to go poring through logs and trying to fix it, go ahead, but from my point of view, that would have taken much, much longer.
Easier to just to a “clean” install on a clean hard drive. Works like a champ now.
Whence my advice to anyone who has hit this in a Web search: sure, you can probably fix it with a lot of editing and log searches. But the quickest and easiest fix is to backup, clean the hard drive, then reinstall.
I also know for a FACT that the “upgrade” option didnot* clean all of my previous installation, because I saw the references to old, outdated drivers with my own eyes.
But again: thanks for your help. Being a mod in one of these forums is a thankless task, and you get snaps, props and a friendly poundin’ on the back for doing it.
You removed the userspace Xorg/DDX radeon driver. However, the radeon kernel driver remains (that is what lsmod refers to). nomodeset impacts the kernal driver (hence the name KMS: kernel modesetting). Once upon a time, the xorg/ddx driver was responsible for modesetting (UMS: user mode setting), but not no more.
Well, it’s not really only about fancy splash screens.
Whatever the reasons, setting the resolution (and other graphics related things) has been moved from user space to the kernel (KMS=Kernel Mode Setting). radeon only works with KMS, support for the old UMS (User Mode Setting) has been removed. So “nomodeset” effectively disables radeon (and e.g. nouveau and intel as well), which might be preferable when you use a proprietary driver (although there are better ways to prevent radeon/nouveau from interfering), or the driver has problems with your particular hardware.
But I do assure you, I had removed radeon.
Don’t you mean fglrx here?
Anyway, in this context I was talking about proprietary drivers in general.
E.g. if you had the nvidia driver installed for your nvidia card, you have to remove it completely if you remove the nvidia card. Otherwise you will have problems, in particular with 3D.
As I said above, while I couldn’t get it removed with Yast (and you seem to think that I was doing something wrong; I don’t feel like arguing about it), I WAS able to remove it with Zypper. I tried several boots, with nomodeset and without, and the best I could get was a desktop with the incorrect resolution. When I ran “lsmod | grep radeon,” it showed that the driver HAD loaded – but the resolution was entirely wrong, and I couldn’t fix it. (I even tried some of the “xrandr” stuff I saw in a Web search).
Well, as I said, without exact conflict messages (or Xorg logfiles, for that matter) it’s hard to say what the problem was.
I didn’t want to imply that you did something wrong.
But still, YaST uses the same underlying software management stack as zypper, so they should behave the same (unless you use different options of course). If you were able to remove fglrx with zypper, you definitely should be able to remove it with YaST as well.
And if you completely remove the proprietary drivers (which is necessary if you change graphics cards), the graphics should work fine.
In particular on 13.2, where the option NO_KMS_IN_INITRD is not respected any more. (this is set e.g. by the nvidia driver on installation but it doesn’t remove it on uninstallation; if set this can cause problems with KMS drivers like radeon, nouveau, and intel)
Again, without seeing your Xorg.0.log, I cannot even guess what your problem was. Well, I can guess, but there are far too many possible reasons, one being remnants of the nvidia driver you might have installed before, when you still used the nvidia card.
No, speaking as someone with a LOT fo experience installing and using Linux (we generally use Red Hat/CentOS at work), the solution was indeed to do a complete, clean install. If you search this forum, you will see where others will recommend this all the time. It’s the quick fix. If you want to go poring through logs and trying to fix it, go ahead, but from my point of view, that would have taken much, much longer.
Yes, it is a quick fix, and one possible solution (not the solution).
But it shouldn’t be necessary (most of the time). Although, if you prefer it, why not.
Easier to just to a “clean” install on a clean hard drive. Works like a champ now.
That depends. It might be quite tedious to setup everything again after a clean installation…
Btw, I haven’t done a clean install here on this system since 12 years.
Whence my advice to anyone who has hit this in a Web search: sure, you can probably fix it with a lot of editing and log searches. But the quickest and easiest fix is to backup, clean the hard drive, then reinstall.
Well, that’s ok of course.
But IME most of the time the reason for such a problem is pretty obvious from the Xorg log. At least if you know what to look for…
And one thing to consider: if it’s a configuration problem, you’d get the problem back if you restore those configuration files after the fresh install.
I also know for a FACT that the “upgrade” option didnot* clean all of my previous installation, because I saw the references to old, outdated drivers with my own eyes.
Yes. That’s the point of an “Upgrade”.
If you want a clean install, do a clean install, not an upgrade.
But again: thanks for your help. Being a mod in one of these forums is a thankless task, and you get snaps, props and a friendly poundin’ on the back for doing it.
