My KDE Plasma system will not boot to desktop unless I add nomodeset manually in grub. This is an AMD system with ATI graphics card and using default drivers (not proprietary). Without nomodeset I get a blanks (black) screen. Was working fine prior to updating today.
Journal shows a message from drm sayng No UMS support in Radeon module.
Obviously nomodeset gives rubbish screen resolution but at least system works.
Anyone any ideas please?
Stuart
Yes, because radeon requires KMS, and nomodeset disables it.
What does you /var/log/Xorg.0.log say if you boot without nomodeset?
(if it’s impossible to get at that because the system is not useable, reboot with nomodeset and post /var/log/Xorg.0.log.old)
Does it work if you boot the previous kernel?
There have not been any changes in the latest Tumbleweed snapshot that might cause this though, except for a kernel update but that was just a rebuild.
Right, so when did you last update your TW before the last one?
Previous update was only a day or so ago. Booting with nomodeset it comes up but I am unable to run any gui in root mode because it says
krusader
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
Invalid MIT-MAGIC-COOKIE-1 keyQXcbConnection: Could not connect to display :0
so as yet not looked at xorg log. System is dual boot with an old 42.2 system so will boot that and look at the log. This system only has two kernels both 13 one 3.1 and 1.1 (I think).
By KMS do you mean DKMS? which is installed.
Stuart
Beginning to think I may have a hardware issue as the 42.2 system shows the same problem and that has not been updated for ages.
Stuart
You don’t need to run anything as root to get the Xorg.0.log…
because it says
krusader
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
Invalid MIT-MAGIC-COOKIE-1 keyQXcbConnection: Could not connect to display :0
krusader also has a menu option to switch to root mode, so maybe try that.
Or use “Konsole (Super User Mode)” (or run “su -” in a normal terminal window, which does the same).
OTOH, running “xauth -b” (as user) might fix the “invalid MIT-MAGIC-COOKIE-1 key” problem too.
so as yet not looked at xorg log. System is dual boot with an old 42.2 system so will boot that and look at the log. This system only has two kernels both 13 one 3.1 and 1.1 (I think).
And did you try to boot the other kernel?
But as apparently not even 42.2 works any more, it might indeed be a hardware problem I suppose.
By KMS do you mean DKMS? which is installed.
No, I mean Kernel Mode Setting, as opposed to the older User Mode Setting (UMS).
“nomodeset” disables Kernel Mode Setting and switches to User Mode Setting, which is not supported by radeon or most other open source drivers.
DKMS is something completely different, it automatically rebuilds 3rd party kernel modules after a kernel update.
But that’s irrelevant here as radeon is part of the standard kernel anyway.
Right now looked at the old Xorg.0.log from a failed boot without nomodeset. Only shows one error (EE) which says it cannot load fglrx which is correct as I dont use it and it’s not installed. No other errors showing. Shows KMS enabled but then says Falling back to old probe method for modesetting. Also correctly identifies my CAICOS Radeon chipset.
So dont know what to do now. Strange that the system was working fine until I did a zypper up this morning and rebooted to get this. There are only two versions of the kernel installed both 4.13, one is 3.3 and the other 1.1 (I think) and both fail.
Stuart
Hi
So what does the output from the following show;
/sbin/lspci -nnk |grep -A3 VGA
systool -vm radeon
Just check the parameters section in the systoll command to see si and cik support are 0
The lspci shows
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] [1002:6779]
Subsystem: ASUSTeK Computer Inc. Device [1043:03da]
Kernel modules: radeon
01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Caicos HDMI Audio [Radeon HD 6450 / 7450/8450/8490 OEM / R5 230/235/235X OEM] 1002:a...
and systool
Error opening module radeon
Stuart
Hi
You need to be root user for systool, be interesting to check all the parameters, boot from an older kernel 4.12? and see if the difference…
Maybe post the Xorg.0.log, you might overlook something that somebody else might spot…
Also, you may try to switch to a different DISPLAYMANAGER in /etc/sysconfig/displaymanager.
xdm should be installed by default (as primitive fallback), but you might also try lightdm or kdm (you’d likely need to install them first though).
Might be specific to sddm, which requires working OpenGL support.
Same error for systool when run as root. I dont have any 4.12 kernels installed currently.
Stuart
Hi
So it’s a hostname issue…
https://lists.opensuse.org/opensuse-factory/2017-09/msg00405.html
Set your hostname…
The MIT Magic Cookie thing has gone away after a reboot.
Stuart
Any idea as to why the systool command fails even running it as root?
Stuart
Well after all yesterdays messing around I decided this morning to wipe my 42.2 hdd and install a completely fresh copy of Tumbleweed having downloaded the lastest full install with the 2017-0928 snapshot. I have just booted this completely vanilla TW install and it came up no problem at all in full resolution on my Radeon card. SO using the new grub install I chose to boot this original TW install without adding nomodeset to the options (I had not hard coded it anyway). So now I am writing this from a perfectly working original TW install with full resolution screen and by the way I now get output from the systool command just fine. So how come? I have no idea! I suppose it could be something to do with grub and its options as this was using the new grub efi boot options not the original one.
Anyway it is working now but leaves me rather puzzled.
Stuart
Hi
Booting with nomodeset…
Well something weird is happening because now both TW installs fail unless I use nomodeset. It happened to the new install after I had booted the old one but since neither share disks the old one cannot have done anything to the new one.
Stuart
Wild guess and probably wrong, but…
Try booting with another monitor, if possible.
A media center box I have would work fine for some time (many boots and shutdowns) then give a blank display when connected through HDMI to an older TV, and switching to VGA didn’t work also. BUT - and that’s the weird part - if I connected it to a LCD monitor it would boot normally, and connecting it back to the TV it would also boot OK. WTF??? This TV is old enough that it’s EDID info is probably bugged, but even so…
On the TV I could also trigger the problem simply by ending the user session (KDE, LEAD 42.3) - which gave me a blank screen in all VTs, or an unresponsive system. After switching the console resolution in Yast’s bootloader options from default to the TV resolution, ending the session still gives a blank screen but with a responsive mouse pointer, and I can switch to VT1, log as root and shutdown or restart the system.
It’s a loooong shot, I know. Good luck.
Nice idea but I dont have one!
Stuart