Description of problem: My Cauldron system worked well originally, but after the updates on Aug 26, I restarted my system immediately and I can no longer get into my desktop successfully. No matter from sddm or gdm, after entering my correct password, the system begins loading the desktop (I tried both kde and gnome), but several seconds later, just before the time the desktop wallpaper and system tray should appear, the system stops loading. In kde, the screen just stops at the big loading progress K and 100% progress bar, and sometimes shows my mouse cursor (in this situation I can move my cursor, so the system does not totally hang, but the desktop does not show). [See below attachment picture.] In gnome, the screen stops at the mageia welcome window, and I can move my mouse cursor to interact with the welcome window (but the gnome system tray/bar does not show). [See below attachment picture.] So I can start a terminal in the fourth page of the welcome window. In the terminal, I can start drakconf, systemsettings5, etc., but all of their windows have no window borders/decorations (the welcome and terminal windows have no window borders/decorations, either). And the desktop screen updates are broken, i.e., only the parts of the screen in the welcome, terminal, and other application windows I open get updated, but the other parts do not get updated. [See below attachment picture.] Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
Created attachment 6978 [details] kde final screenshot
Created attachment 6979 [details] gnome final screenshot
Created attachment 6980 [details] gnome screenshot with terminal window
I'm seeing sg similar since Saturday 29th on an intel E8400. What's your CPU? My symptoms are similar but I can access the desktop. The system will freeze if I start using big programs (firefox, ...) and there's nothing in the logs I'll try to downgrade glibc to mga5 one in order to see if it helps.
CC: (none) => thierry.vignaud, tmbHardware: i586 => AllSource RPM: (none) => kernel? glibc?
My CPU is AMD Athlon II. I've tried creating a brand-new user to confirm if any of my old settings is causing this situation, but the same situation still occurs while I login to the new user's desktop.
My KDE start froze at the same point also after an update around the 26th. This turned out to be due to kwin_x11 crashing in breezedecoration.so and was fixed by an update of the breeze package (5.4.0-1) on Aug 30th. Did you update your system after that date?
CC: (none) => gm2.asp
Yes, but I have not tried logining to KDE after Aug 30th. I only login to GNOME to do some daily routine, and my GNOME desktop remains the same situation, so I don't even think that maybe KDE already get fixed. I will try that and see the result this evening. Thanks!
Hi! My KDE has already come back. (And it seems that the causes of desktop hangs for kde and gnome are different.)
I installed GNOME. Initially it would not start on my system either. However, switching desktop manager from SDDM to GDM allowed me to start GNOME as well as KDE. So, looks like a problem with SDDM or the way it is set up.
For me, the kernel-linus-4.2 is much more stable than kernel-desktop-4.1
From debug logs, it looks like /usr/bin/gnome-session, when started from SDDM, searches for processes enabled for KDE rather than for GNOME in the .desktop files. Adding: export XDG_CURRENT_DESKTOP=GNOME before gnome-session is invoked allows GNOME to be started from SDDM
Actually, I've no more freeze since I've downgraded glibc from 2.22 to mga5's 2.20...
So I suspect it's lock elision which strikes again at older CPUs...
Probably more than one issue then. I think that the issue I see can be explained from the source code for SDDM and gnome-session respectively. In the Display::startAuth method of SDDM's Display class, the .desktop file corresponding to the selected desktop (02GNOME.desktop or 03GNOMEClassic.desktop in this case) in the /usr/share/xsessions/ directory is searched for a line starting with "DesktopNames=" (Display.cpp, line 248). If it is found, the rest of the line is assigned to the XDG_CURRENT_DESKTOP env variable. If it is not found, XDG_CURRENT_DESKTOP is still created, but assigned an empty string as value (Display.cpp, line 282). The main function of gnome-session has compatibility code, creating XDG_CURRENT_DESKTOP with value "GNOME" if it is not already existing. (main.c, line 340). Unfortunately, it does not also check for variable existing, but has value "" If XDG_CURRENT_DESKTOP does not hold the value "GNOME", the necessary gnome components do not get started. The above interpretation is supported by the fact, that after adding the line: DesktopNames=GNOME to 02GNOME.desktop and 03GNOMEClassic.desktop, both GNOME and GNOMEClassic can be started from SDDM.
(In reply to Arne Spiegelhauer from comment #9) > I installed GNOME. Initially it would not start on my system either. > However, switching desktop manager from SDDM to GDM allowed me to start > GNOME as well as KDE. > So, looks like a problem with SDDM or the way it is set up. Indeed, after switching the desktop manager from SDDM to GDM, I can login to GNOME successfully.
CC: (none) => doktor5000
(In reply to Arne Spiegelhauer from comment #14) > The above interpretation is supported by the fact, that after adding the > line: > DesktopNames=GNOME > to 02GNOME.desktop and 03GNOMEClassic.desktop, both GNOME and GNOMEClassic > can be started from SDDM. Uhmmm, when did you last update your cauldron? This is what it looks like here, both contain the GNOME values you mentioned, but different filenames: [user@localhost]â[17:43:22]â[~] grep -i desktopname /usr/share/xsessions/gnome*desktop /usr/share/xsessions/gnome-classic.desktop:DesktopNames=GNOME-Classic;GNOME /usr/share/xsessions/gnome.desktop:DesktopNames=GNOME [user@localhost]â[17:44:37]â[~] rpm -qf /usr/share/xsessions/gnome*desktop gnome-classic-session-3.19.2-1.mga6 gnome-session-3.18.1.2-2.mga6 [user@localhost]â[17:45:16]â[~] Starting a gnome session from SDDM works just fine here, no issues at all. The old desktop files you mentioned should be removed starting with gnome-session-3.16.0-5.mga6 and gnome-classic-session-3.18.0-2.mga6 Apart from that, the described issues seem pretty different, and got also mixed up.
Thanks Florian, I have updated my cauldron regularly and was aware that both the Plasma and the GNOME issue had been fixed. Maybe I should have added a comment about that, but I guess I expected that the originator of this bug report or the package maintainer would update/close it. By the way, in my current cauldron, gnome classic seems to be broken again with a different cause.
(In reply to Arne Spiegelhauer from comment #17) > Thanks Florian, > I have updated my cauldron regularly and was aware that both the Plasma and > the GNOME issue had been fixed. FWIW, I think I can reproduce the issue you mentioned with 02GNOME.desktop and 03GNOMEClassic.desktop on Mageia 5 with SDDM, so thanks for the pointer. Will open a new bug for that. > By the way, in my current cauldron, gnome classic seems to be broken again > with a different cause. Might be the case, if it's reproducible then best open a new bugreport about that ;)
Adjusting the summary, since the original reporter, Jin-tong Hu, said in comment 8 that KDE worked again, and in comment 15 that he can login to Gnome if he switches from SDDM to GDM. @ Hu Does starting Gnome from SDDM still fail for you? If so, then I'd like to move this bug report to a fresh report, because this report has become confusing.
Keywords: (none) => NEEDINFOCC: (none) => marja11Summary: Desktop hangs after login success and during desktop starting (both kde and gnome) => Desktop hangs after login success from sddm (gnome)Source RPM: kernel? glibc? => sddm?
I've already done a new installation of Cauldron (Mageia-6-dev1) and don't use GNOME anymore, so maybe this bug can be closed?
(In reply to Jin-tong Hu from comment #20) > I've already done a new installation of Cauldron (Mageia-6-dev1) and don't > use GNOME anymore, so maybe this bug can be closed? Thx for the feedback. Closing
Status: NEW => RESOLVEDResolution: (none) => OLD