Description of problem: When i boot my cauldron prefdm service fail to start because of dependency on plymouth-wait-quit.service. I don't know if it's because I have a crossfire of 2 radeon 6870 or a native resolution of 2560x1600. Version-Release number of selected component (if applicable): plymouth-0.8.6.1-13.mga5 How reproducible: Each boot Steps to Reproduce: 1. boot mageia and get the message x failed to start bla bla bla 2. systemctl start plymouth-quit.service 3. systemctl default 4. then it works Reproducible: Steps to Reproduce:
This package has no registered maintainer in our database, so assigning to packagers collectively. Packagers, if one of you is maintaining this package, please update the maintainers database accordingly.
CC: (none) => tmbAssignee: bugsquad => pkg-bugs
What display manager do you use, and how do you start the X session? Is it configured to auto-start X on boot? And can you please show the output of cat /etc/sysconfig/desktop systemctl status prefdm.service -a systemctl status graphical.target default.target systemctl list-dependencies default.target --no-pager
CC: (none) => doktor5000
# cat /etc/sysconfig/desktop DISPLAYMANAGER=KDM # systemctl status prefdm.service -a â prefdm.service - Display Manager Loaded: loaded (/usr/lib/systemd/system/prefdm.service; static; vendor preset: enabled) Active: active (running) since mar. 2015-12-08 00:26:17 CET; 1 day 14h ago Main PID: 1976 (sddm) CGroup: /system.slice/prefdm.service ââ1976 /usr/bin/sddm -nodaemon ââ1987 /etc/X11/X -nolisten tcp -auth /var/run/sddm/{58a6d5d8-eda6-4f6d-9631-b237dcf4d9b3} -background none -noreset -displayfd 17 vt1 déc. 08 00:26:51 akasha.aoihime.eu sddm-helper[2044]: [PAM] Authenticating... déc. 08 00:26:51 akasha.aoihime.eu sddm-helper[2044]: pam_succeed_if(sddm:auth): requirement "user ingroup nopasswdlogin" not met by user "rapsys" déc. 08 00:26:51 akasha.aoihime.eu sddm-helper[2044]: [PAM] Preparing to converse... déc. 08 00:26:51 akasha.aoihime.eu sddm-helper[2044]: [PAM] Conversation with 1 messages déc. 08 00:26:51 akasha.aoihime.eu sddm-helper[2044]: pam_tcb(sddm:auth): Authentication passed for rapsys from (uid=0) déc. 08 00:26:51 akasha.aoihime.eu sddm-helper[2044]: [PAM] returning. déc. 08 00:26:51 akasha.aoihime.eu sddm[1976]: Authenticated successfully déc. 08 00:26:51 akasha.aoihime.eu sddm[1976]: Auth: sddm-helper exited successfully déc. 08 00:26:51 akasha.aoihime.eu sddm[1976]: Greeter stopped. déc. 08 00:27:16 akasha.aoihime.eu sddm[1976]: Session started # systemctl status graphical.target default.target â graphical.target - Graphical Interface Loaded: loaded (/usr/lib/systemd/system/graphical.target; enabled; vendor preset: enabled) Active: active since mar. 2015-12-08 00:26:17 CET; 1 day 14h ago Docs: man:systemd.special(7) déc. 08 00:26:17 akasha.aoihime.eu systemd[1]: Reached target Graphical Interface. â graphical.target - Graphical Interface Loaded: loaded (/usr/lib/systemd/system/graphical.target; enabled; vendor preset: enabled) Active: active since mar. 2015-12-08 00:26:17 CET; 1 day 14h ago Docs: man:systemd.special(7) déc. 08 00:26:17 akasha.aoihime.eu systemd[1]: Reached target Graphical Interface. # systemctl list-dependencies default.target --no-pager default.target â ââmsec.service â ââpartmon.service â ââpostfix.service â ââprefdm.service â ââresolvconf.service r ââsystemd-update-utmp-runlevel.service â ââmulti-user.target â ââacpid.service â ââatd.service â ââchronyd.service â ââcpupower.service â ââcrond.service â ââcups-browsed.service â ââdbus.service â ââlm_sensors.service â ââmdmonitor.service r ââmga-bg-res.service â ââmsec.service â ââNetworkManager.service â ââpartmon.service r ââplymouth-quit-wait.service r ââplymouth-quit.service â ââpostfix.service â ââresolvconf.service â ââsensord.service â ââshorewall.service â ââshorewall6.service â ââsmartd.service â ââsshd.service â ââsystemd-ask-password-wall.path â ââsystemd-logind.service r ââsystemd-networkd.service â ââsystemd-resolved.service r ââsystemd-update-utmp-runlevel.service â ââsystemd-user-sessions.service â ââbasic.target â â ââ-.mount r â ââalsa-restore.service r â ââalsa-state.service r â ââfedora-autorelabel-mark.service r â ââfedora-autorelabel.service â â ââfedora-loadmodules.service r â ââip6tables.service r â ââiptables.service â â ââmandriva-everytime.service â â ââmandriva-save-dmesg.service â â ââtmp.mount â â ââpaths.target â â ââslices.target â â â ââ-.slice â â â ââsystem.slice â â ââsockets.target â â â ââdbus.socket â â â ââsystemd-initctl.socket â â â ââsystemd-journald-audit.socket â â â ââsystemd-journald-dev-log.socket â â â ââsystemd-journald.socket â â â ââsystemd-udevd-control.socket â â â ââsystemd-udevd-kernel.socket â â ââsysinit.target â â â ââdev-hugepages.mount â â â ââdev-mqueue.mount â â â ââkmod-static-nodes.service r â â ââldconfig.service â â â ââmdmonitor-takeover.service r â â ââplymouth-read-write.service â â â ââplymouth-start.service â â â ââproc-sys-fs-binfmt_misc.automount â â â ââsys-fs-fuse-connections.mount r â â ââsys-kernel-config.mount â â â ââsys-kernel-debug.mount r â â ââsystemd-ask-password-console.path r â â ââsystemd-binfmt.service r â â ââsystemd-firstboot.service r â â ââsystemd-hwdb-update.service r â â ââsystemd-journal-catalog-update.service â â â ââsystemd-journal-flush.service â â â ââsystemd-journald.service r â â ââsystemd-machine-id-commit.service â â â ââsystemd-modules-load.service â â â ââsystemd-random-seed.service â â â ââsystemd-sysctl.service r â â ââsystemd-sysusers.service r â â ââsystemd-timesyncd.service â â â ââsystemd-tmpfiles-setup-dev.service â â â ââsystemd-tmpfiles-setup.service â â â ââsystemd-udev-trigger.service â â â ââsystemd-udevd.service r â â ââsystemd-update-done.service â â â ââsystemd-update-utmp.service â â â ââsystemd-vconsole-setup.service â â â ââcryptsetup.target â â â ââlocal-fs.target â â â â ââ-.mount â â â â ââboot.mount r â â â ââfedora-import-state.service â â â â ââfedora-readonly.service r â â â ââfedora-storage-init-late.service r â â â ââfedora-storage-init.service r â â â ââsystemd-fsck-root.service â â â â ââsystemd-remount-fs.service â â â â ââtmp.mount r â â â ââvar-lib-machines.mount â â â ââswap.target â â â ââdev-disk-by\x2duuid-4e93c312\x2dc084\x2d4dde\x2da241\x2d022073b71f18.swap â â ââtimers.target â â ââsystemd-tmpfiles-clean.timer â ââgetty.target r â ââgetty@tty1.service â ââopenvpn.target â âârpcbind.target
To start the x i press space after the message about X don't start, good luck, bla bla. Then i login as root Then type systemctl default Then i can login in the X session
I put r instead of â for the one in red, the other â are green. The installation was done with the cauldron 5 live cd and updated to latest version + urpmi installation of some package from repositories.
Weird, the log output from prefdm looks just normal, seems the problem before sddm start wasn't even caught. You should check two things, for one at the point where you do "systemctl default" please do "journalctl -ab | tail -250 > /tmp/journal.log" and attach that file here. Please also provide the output of journalctl -ab | grep -A 100 -i "ordering cycle" | grep -B 100 -i "ordering cycle" (should only be a few lines if there is some output at all). Apart from that, are there any other specifics to your system that are different from a "normal" installation, like network share as /home or remote authentication via NIS or similar? Also, what graphics driver do you use for the two radeons? fglrx? And is there anything in /var/log/Xorg.0.log ?
Created attachment 7277 [details] Xorg.0.log
Created attachment 7278 [details] journal.log
Created attachment 7279 [details] dmesg.log
ordering cycle was emplty. I added journal.log and Xorg.0.log The Xorg log mention a no screen found, but my configuration is right because 20 seconds later it works. I attached dmesg and you can see a sddm crash i don't understand. I use the plain radeon driver with latest kernel and ati one in xorg.
(In reply to Raphael Gertz from comment #10) > I attached dmesg and you can see a sddm crash i don't understand. It's a segmentation fault, from the dmesg log: > [ 6.087125] sddm[992]: segfault at 2049920 ip 0000000002049920 sp 00007ffe3f8dd868 error 15 Not sure where that comes from. And the actual X error is not "no screens found" but directly above it: > [ 7.768] (EE) No devices detected. But also not sure why that happens. Maybe plymouth still really holds the device? Apart from that, the journal log does not seem to contain anything related to sddm. Can you please attach a compressed full log of a normal boot please? Use e.g. journalctl -ab | xz - > /tmp/journal.log.xz
Created attachment 7282 [details] Full boot compressed journal
It seems the sddm segfault, say me how i can set it up to have a backtrace.
Not sure about segfault, it was the 12 december that it segv, not today : déc. 12 11:22:03 akasha.aoihime.eu kernel: sddm[809]: segfault at 340 ip 0000000000000340 sp 00007ffdeb0e59e8 error 14 in sddm[400000+67000] déc. 12 12:55:03 akasha.aoihime.eu kernel: sddm[992]: segfault at 2049920 ip 0000000002049920 sp 00007ffe3f8dd868 error 15
From what I can see, this behaviour is described in closed upstream bugreport https://github.com/sddm/sddm/issues/412#issuecomment-103114535 > X isn't starting so xcbScreen will return null so that's all for the crash in sddm-greeter. But I'm reporting this anyway wishing that in this case (no screen) we chose not to crash by handling it and outputting some useful information on what's going on (X has failed to start, check your Xorg log), also should probably deal with it in a X/wayland independent way. But in your case you get the message that X failed to start, this comes from the service display-manager-failure.service This seems to be the same issue as described in https://bugs.mageia.org/show_bug.cgi?id=17233#c11 in bug 17233 From the Xorg.0.log: [ 7.768] (II) [KMS] Kernel modesetting enabled. [ 7.768] (EE) No devices detected. [ 7.768] (EE) Fatal server error: [ 7.768] (EE) no screens found(EE) [ 7.768] (EE)
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=17233
(In reply to Raphael Gertz from comment #13) > It seems the sddm segfault, say me how i can set it up to have a backtrace. Should be possible by running e.g. "systemd-coredumpctl gdb <PID>" against the current PID of /usr/bin/sddm. When gdb is running and has attached to sddm and the segfault has happened run the "bt" command in gdb. You might need to install additional -debuginfo packages, but gdb should tell you which and how to install them. For more information see also https://wiki.mageia.org/en/Debugging_software_crashes
Status: NEW => ASSIGNEDAssignee: pkg-bugs => doktor5000
Seems fixed, no more crash since a recent upgrade of the distribution. Don't know what fixed it.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED