I did a zypper dup yesterday and this completely has broken my desktop. I then downloaded the latest snapshot to rule out any issues I might have introduced at some point but it did not help:
After installing KDE/Gnome desktops (first tried KDE since this is what I want to use) I could no longer login. I managed to get a glimpse at the desktop once in a Gnome-Wayland session, but this also no longer works.
As background information: I use a ASUS N61Jv laptop (and planned to use the nouveau driver without bumblebee etc.). Login to tty still works.
Any suggestions?
It is fairly important for me to get this working again since my private laptop is using the same setup as my development machine @work.
Maybe a graphics driver problem?
Both GNOME and Plasma5 make use of OpenGL, if that doesn’t work, they crash.
Please login to IceWM, install “Mesa-demo-x”, and post the output of:
glxinfo | grep render
and the file /var/log/Xorg.0.log.
Try to boot to recovery mode (“Advanced Options” in the boot menu) and see if you can login there.
You say you “planned to use nouveau without bumblebee”, but what are you using now? And is this an Optimus system?
You cannot just use nouveau or nvidia on an Optimus system, as normally only the intel chip is connected to the display.
And installing the standard nvidia driver breaks Mesa, and therefore also intel’s OpenGL support (and even the software renderer), which definitely will prevent you from being able to login to either GNOME or Plasma5…
Yes this is an (infamous) Optimus laptop. Let me elaborate on what I said (and correct myself):
I did not install any proprietary drivers, so no nvidia driver (also not via nvidia-bumblebee). Therefore basic openGL support should be available via the Intel integrated graphics chip.
To explain the remark about using nouveau: I learned a “trick” from the arch linux forums, where they state that the (since 2013 unsupported) bumblebee will not work with nouveau and that one should use the following combination:
xrandr --setoffloadprovidersink nouveau Intel
DRI_PRIME=1 <application>
This actually seemed to really have made use of the nvidia chip. (This is what I meant: Rely usually on the Intel chip and enable nouveau via the above procedure.)
You do get a login screen, right? Then it shouldn’t be a general Xorg problem though.
Or how are you trying to login to the desktop sessions?
What display manager are you using?
Have a look into ~/.xsession-errors-:0 for error messages if it exists.
Are all files in your home directory owned by your user? (also the hidden ones?)
Is / and /home mounted read-write? Do you have any particularly “special” partioning, or is it just the default /, /home and swap?
Is some free space left in / and /home? Maybe try to delete a snapshot if using btrfs, it could be full even if “df” or other tools show plenty of free space.
By display manager I guess you mean wayland or xorg? In any case: I use the default display manager that comes with the default KDE installation.
Using “failsafe” and trying recovery also did not work.
/home is mounted read/write but I did not create any users since I have existing user data stored on /home (seperate XFS partition) that I want to reuse as soon as I have all required applications reinstalled. Could this be the issue? If so: Why? It worked before and imho this really should work, right?
I checked if the ~/.xsession-errors-:0 exists and it does not.
I just did a systemctl status which contained complete rubbish (strange symbols like the greek capital gamma, the german ö etc) and displayed in the State field: degraded.
I found something else out: While the Xorg.0.log does not contain any errors the fonts in vi are completly messed up. Could this be part of the problem?
In any case: I use the default display manager that comes with the default KDE installation.
I think that’s sddm now.
Try to set something else in /etc/sysconfig/displaymanager, xdm is installed by default too.
Or install kdm and set that.
Using “failsafe” and trying recovery also did not work.
Ok, then it’s definitely not graphics related. That was unlikely now anyway as you do see the login screen and the problem persists with IceWM too.
/home is mounted read/write but I did not create any users since I have existing user data stored on /home (seperate XFS partition) that I want to reuse as soon as I have all required applications reinstalled. Could this be the issue? If so: Why? It worked before and imho this really should work, right?
What do you mean with “did not create any users”?
How are you trying to login then?
sddm doesn’t support logging in as root AFAIK, so that might very well be the issue. But it shouldn’t even allow you to select root.
Anyway, try with xdm or kdm then.
Either with YaST or “useradd”.
Is there any other diagonstic or log file that I could check?
I’m not sure. If ~/.xsession-errors-:0 does not exist, the output is probably going to the systemd journal.
But if you use xdm or kdm as displaymanager, you should get a ~/.xsession-errors-:0.
The strange symbols are probably because UTF-8 support is not loaded in the text mode console.
See 859710 – on installation (init 3) unicode_start is missing
Try running “unicode_start” manually.
That should have no influence on your problem though.
But what “systemctl status” command did you run exactly, and in what “State field” did it display “degraded”?
When I run “systemctl status” here, I don’t see a “State” field at all. But that’s on 13.2, could be something new in systemd>210.
???
What should vi (in text mode I suppose) have to do with Xorg or your X sessions not starting?
I suppose that’s rather related to the missing UTF-8 setup in the text mode console.
It was indeed sddm not allowing to login as root. After some hassle getting the wifi working with nmcli (which is actually not too bad, just unfamiliar) I managed to install kdm which allows to login as root. A question regarding this: What are the disadvantages of using kdm over sddm and vice versa?
There’s not really a disadvantage, I’d say. They are just different.
Except maybe that Plasma5 only has a configuration module for sddm, if you want to configure kdm you’d need to use KDE’s “Configure Desktop”.
OTOH, sddm still lacks features compared to kdm, like Remote Login e.g.
At least it works now. One thing on top of not having a configuration module is that the lock screen will still use sddm (which leads to crashes when one wants to switch to another user).
As I wrote in the first post: I also use openSUSE Tumbleweed on my computer @work (also without proprietary drivers). When I want to upgrade, which I plan to do this week: What can I do if I experience the same segfaults/kwin crashes after logging in to my desktop?
Any advice on how to do the transition as safe as possible?
Also: I occasionally use Haskell here but the haskell-platform package ist apparently broken atm. Who needs to be notified so that this gets fixed?
No.
The lock screen does not use sddm at all, it is part of Plasma.
It’s rather the opposite: in the default configuration sddm uses Plasma5’s breeze theme, so they look similar.
Switching users should work with kdm too (or gdm for that matter), at least it does here on 13.2.
You can still use KDE’s systemsettings (“Configure Desktop”) to configure kdm, I don’t think that’s being uninstalled automatically. You might have to run it in a terminal window though.
As I wrote in the first post: I also use openSUSE Tumbleweed on my computer @work (also without proprietary drivers). When I want to upgrade, which I plan to do this week: What can I do if I experience the same segfaults/kwin crashes after logging in to my desktop?
Well, that depends on why it is crashing.
But it shouldn’t.
Any advice on how to do the transition as safe as possible?
A standard upgrade should work fine.
And AIUI, your main problem here was that you tried to login as root.
But if Plasma5 is giving you problems, you can still login to other desktop sessions.
Also: I occasionally use Haskell here but the haskell-platform package ist apparently broken atm. Who needs to be notified so that this gets fixed?
What’s that got to do with this thread?
But to answer your question:
If you installed haskell from the standard openSUSE repos and it doesn’t work, you should probably file a bug report at http://bugzilla.opensuse.org/ (same username/password as here).
I only had this problem with the login as root because I reinstalled, which I only did because kwin was segfaulting all the time directly after the upgrade. So the deeper reason was in fact the plasma 5 upgrade, not me not knowing that sddm banned root login (thx for that info btw). That I reinstalled also implies that I can only use the configure desktop application if it is still available in the repos. From what I have seen this morning the systemsettings have been replaced, so it is unclear to me atm if this will work as you say it will. I will try this later.
Regarding the question about haskell: I did not want to offend with this. Of course it has nothing to do with the specific question. I just was unsure if I should really open another thread for such a minor question.
You say a standard upgrade should work and I guess that means zypper dup should work. However there are quite a few issues mostly of the kind “X requires Y which cannot be provided”, where X is usually something plasma related. Should I always remove them?
Sorry for asking in such a great level of detail, but I just want to make sure to make not mistake with the company machine.
Ok, sorry.
I answered a lot of posts with similar issues yesterday and today, and also wrote a lots of EMails on the Factory mailinglist.
Hard to keep track of every detail in each particular track that way. And always re-reading everything from the start is not really an option too…
That I reinstalled also implies that I can only use the configure desktop application if it is still available in the repos. From what I have seen this morning the systemsettings have been replaced, so it is unclear to me atm if this will work as you say it will. I will try this later.
KDE4’s systemsettings is part of the package kdebase4-workspace-addons, which should not have been replaced on an upgrade.
You might have to install it manually though on a fresh installation, I don’t know.
If you don’t find it in the K-Menu you should still be able to run it manually in a terminal or KRunner with “systemsettings” (Plasma5’s version is called “systemsettings5”).
Regarding the question about haskell: I did not want to offend with this. Of course it has nothing to do with the specific question. I just was unsure if I should really open another thread for such a minor question.
No offense taken.
But it’s always preferable to open new threads for unrelated problems.
You say a standard upgrade should work and I guess that means zypper dup should work.
Yes, it should.
If not it’s a bug that should be fixed (which doesn’t help you much I suppose, if you run into a problem).
However there are quite a few issues mostly of the kind “X requires Y which cannot be provided”, where X is usually something plasma related. Should I always remove them?
I suppose so, but that depends on the particular problem.
There is one particular problem in plasma-nm5-xxx not obsoleting plasma-nm-xxx which leads to conflicts. Just select “Uninstall plasma-nm-xxx” in this case.
But that’s been fixed already, the fix isn’t in Tumbleweed yet though.
I am not aware of other conflicts at the moment…
Sorry for asking in such a great level of detail, but I just want to make sure to make not mistake with the company machine.
I can understand that.
Well, the question would be now why kwin crashed for you in the first place. (was it really kwin? the desktop should work fine even without it…)
Hard to answer without more details, but normally it should not happen, unless you have a graphics driver problem.
Some reports on the KDE forums would suggest to remove ~/.config/ to fix problems though.
And booting to recovery mode should help with graphics driver problems in any case, unless you installed some proprietary driver.
