Using sddm + plasma. Until recently, I had issues at boot already: it used to show the "good luck" message then managed to start sddm, but in a broken way (any accented letter would make it crash). So I had to come back to tty and restart the dm service and then everything would be ok. Now it's gotten worse. All I get is a black screen with a seemingly blinking cursor, but very slowly (every 10s or so). According to the logs it corresponds to sddm trying to start again and again. I can't even get a tty from here: the Ctrl+Alt+1..6 shortcuts don't work. I can still log in using ssh though.
Created attachment 8702 [details] journalctl -ab after logging via SSH.
CC: (none) => kde, kernel
Created attachment 8703 [details] lspcidrake -v
Created attachment 8704 [details] Xorg.0.log
Created attachment 8705 [details] journalctl -ab after runlevel 3 then service dm start Logs of a working situation, when I first start the system without X then start the dm service manually.
Created attachment 8706 [details] Xorg.0.log working after starting manually the dm service
Priority: Normal => High
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=19849
One relevant message (I suppose) in Xorg.0.log in the "bad" case, absent from the "good" case: [ 598.954] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied
(In reply to Samuel Verschelde from comment #6) > One relevant message (I suppose) in Xorg.0.log in the "bad" case, absent > from the "good" case: > > [ 598.954] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: > Permission denied We've had that error before in bug reports, some of them are still open, see the "failed to set DRM interface version 1.4" Bugzilla search that was just created & shared
CC: (none) => marja11Blocks: (none) => 19781Assignee: bugsquad => kernel
(In reply to Samuel Verschelde from comment #6) > One relevant message (I suppose) in Xorg.0.log in the "bad" case, absent > from the "good" case: > > [ 598.954] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: > Permission denied This might be another artifact of sddm crashing too soon. I noticed this in https://bugs.mageia.org/show_bug.cgi?id=19216#c57 and later decided that a user not being registered on the system was the cause because if I ctrl-alt-f2 (which I did see in your case you cannot do) and log in a normal user found those permissions were magically fixed and startX would succeed. https://bugs.mageia.org/show_bug.cgi?id=19199 also refers to this and it might be related to https://bugs.mageia.org/show_bug.cgi?id=18032 too. The bottom line is that once the good luck sddm thing is resolved this may well just go away.
CC: (none) => mrambo
Looking at /etc/X11/prefdm, I noticed that for most Display Managers, plymouthd is shut down before start, but only if they are explicitly configured in /etc/sysconfig/desktop, and not if they are selected as first available or as fallback. After creating /etc/sysconfig/desktop with the one line: DISPLAYMANAGER=sddm the system consistently boots to the login screen. However, after login, the display gets stuck on the splash screen about every second time. Changing to VT2 and back to VT1 will then cause the splashscreen to fade into the desktop.
CC: (none) => gm2.asp
(In reply to Arne Spiegelhauer from comment #9) > However, after login, the display gets stuck on the splash screen about > every second time. Changing to VT2 and back to VT1 will then cause the > splashscreen to fade into the desktop. I got that too. This is something new and probably worth its own bug report.
(In reply to Samuel Verschelde from comment #10) > (In reply to Arne Spiegelhauer from comment #9) > > However, after login, the display gets stuck on the splash screen about > > every second time. Changing to VT2 and back to VT1 will then cause the > > splashscreen to fade into the desktop. > > I got that too. This is something new and probably worth its own bug report. Submitted bug 19869
To anyone having this issue, does removing the conflict with plymouth-quit.service from /usr/lib/systemd/system/prefdm.service solve it?
In my system it does, with the minor side-effect (compared to prefdm doing a plymouth quit) of a text mode login prompt for VT1 being displayed for a fraction of a second shortly after the SDDM login screen is first displayed. I do not have the knowledge to have an opinion on the correct solution to this issue, but to me it looks like a bug that prefdm's decision whether to do a plymouth quit is affected anything other than what display manager is selected.
... is affected by anything other than what display manager is selected.
Fixed now.
Status: NEW => RESOLVEDResolution: (none) => FIXED