After installing 3beta2, I couldn't boot into KDE, before I reached KDM I seemed to have a hard lock. After rebooting into safe mode and updating, at next reboot the screen got black again, but this time the Alt-SysRq rseiub keys worked In runlevel 3 doing systemctl start prefdm.service made KDM (and KDE after that) start fine Then there was 1 time KDM started, but KDE gave the black screen again. After that it went fine a few times, until now. I'll restart that system and attach the last part of journalctl I do not have this problem with 3beta2 LXDM/LXDE
Whiteboard: (none) => 3beta2
Created attachment 3380 [details] journalctl of one failed and then one good boot the failed boot I just talked about, was a hard lock again :/ I haven't found whether there are differences in the journalctl output between a good and a wrong boot, before the point where it goes wrong
cc'ing mikala and neoclust
CC: (none) => balcaen.john, nicolas.lecureuil
Still valid with the final 3beta2 KDE (installed with i586 traditional installer DVD) LXDE again no problem. reboot after install: hard lock (needed to press power button to power-off) 2nd boot: no problem reboot: hard lock (so power-off with power button) next boot: no problem Maybe the problem only occurs when rebooting? After updating the system (over 100 packages, including kernel, systemd and x11-server stuff), rebooting went fine several times. I'll leave this bug open for now, though, because I've seen the problem return after several good reboots, before.
CC: (none) => eeeemail, mageia, tmb
Maybe same problem on a Centrino, only there the *only* way to boot into KDE is doing systemctl start prefdm.service even after getting all updates. That laptop has to use kernel-linus, because of bug 6077 I probably won't see that system again before February 11th, and didn't have time to get any logfile
I suspect one of a couple of things: 1. prefdm.service job was dropped due to a loop in the ordering cycle (e.g. the combination of enabled systemd units are in cyclical dependence i.e. A must start before B which must start before A). In order to cope with this, the prefdm.service start job is sometimes the victim in the "drop jobs until the cycle is broken" stage. This typically lands you on tty1 (but without any getty). Normally a swtich to tty2 allows you to login. This can be confirmed by logging in to tty2, and doing "systemctl show prefdm.service | grep -i mono" if the active time monotonic shows a 0 then the job has never been started. 2. Some other job is holding up prefdm.service from starting. It'll have to wait for a timeout (e.g. maybe a minute or three) before continuing. Also easy to test - just way 15mins and if it's still not running then it's not that :p
Maybe the above doesn't apply here. Seems that "Display Manager" is started in both cases in your log, which implies there is no inherent job related issue in terms of systemd. Could just be some kind of kernel/display/drm related fu I guess.
(In reply to Marja van Waes from comment #3) > > After updating the system (over 100 packages, including kernel, systemd and > x11-server stuff), rebooting went fine several times. > > I'll leave this bug open for now, though, because I've seen the problem > return after several good reboots, before. (In reply to Marja van Waes from comment #4) > Maybe same problem on a Centrino, only there the *only* way to boot into KDE > is doing > > systemctl start prefdm.service > > even after getting all updates. > > That laptop has to use kernel-linus, because of bug 6077 > > I probably won't see that system again before February 11th, and didn't have > time to get any logfile Closing as fixed: The problem didn't return for me, anymore. I didn't get around to checking Mga 3 on that Centrino again, but I don't even know whether it has or had the same bug.
Status: NEW => RESOLVEDResolution: (none) => FIXED