| Summary: | 3beta2 booting into KDE can give a black screen and no visible tty's to go to | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Marja Van Waes <marja11> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | balcaen.john, eeeemail, mageia, mageia, tmb |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | 3beta2 | ||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: | journalctl of one failed and then one good boot | ||
|
Description
Marja Van Waes
2013-01-15 22:00:16 CET
Marja Van Waes
2013-01-15 22:00:32 CET
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.
claire robinson
2013-01-29 10:57:29 CET
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 =>
RESOLVED |