Sometime in the last couple of days the booting process has got borked. I'm not sure who's at fault, but I'll start by guessing plymouth. Scenario 1: You boot and get the plymouth splash screen, hit ESC, and watch all the status lines scroll by until you hit "Hold for boot to complete". Then it stops dead. Recalling the "Sorry" thread, on a hunch I gave it a couple of CTRL-ALT-BKSPs, the tty screen blinked, and the SDDM screen appeared. Scenario 2: You boot and never get the splash screen, but stay at "booting the kernel" on tty1. After waiting for what would be a reasonable time for a boot, a couple of CTRL-ALT-BKSPs again blinks the tty and gives you the SDDM screen. I think that the only difference between the two is that successive (or competing) updates to systemd (I assume) are resulting in no tty detail boot messages (scenario 2), the regular messages (scenario 1), and for a version of scenario 1, each message doubled. Anyway the common element seems to be that the initial launch of SDDM has some sort of race condition, and killing X with CTRL-ALT-BKSP causes systemd to restart dm and it works the second time.
Assigning to all packagers collectively, since there is no registered maintainer for plymouth. CC'ing SDDM maintainers
CC: (none) => kde, marja11Assignee: bugsquad => pkg-bugs
Still happening in today's cauldron.
Adding Giuseppe, Mike and Neal in CC because they worked on the "Good luck" thing and might have ideas or insights.
CC: (none) => ghibomgx, mrambo, ngompa13
FWIW, I updated all of my cauldron installations yesterday and then did a fresh installation via boot.iso. Among those installations I have Radeon, Intel, and nVidia with both free and proprietary drivers (the new installation was the latter). Unfortunately I have not been able to trigger the behavior described. Note that although the testing has been with a variety of video systems the underlying hardware for all the tests has been the same. It is an older HP 6000 Pro. Intel Core 2 Duo E8400 3GHz. I'll check on other hardware if I get time but so far I don't see anything helpful. Frank, what hardware are you seeing this on?
This is one of those systems that has dual GPUs, one NVidia (GEForce 610M) and one Intel (810 and later). but I'm not sure which one is actually used. Still happening in current cauldron.
(In reply to Frank Griffin from comment #0) > > Anyway the common element seems to be that the initial launch of SDDM has > some sort of race condition, and killing X with CTRL-ALT-BKSP causes systemd > to restart dm and it works the second time. I had overlooked that, do you mind running, as root, journalctl -ab > journal.txt right after you hit this again, and attaching journal.txt to this bug report?
Assignee: pkg-bugs => bugsquadSource RPM: plymouth => plymouth, sddm
Did this get fixed?
Keywords: (none) => NEEDINFO
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as OLD.
Resolution: (none) => OLDStatus: NEW => RESOLVED
Sorry, I seem to have mised Marja's request above. In any case, this has been foreshadowed by a problem reported elsewhere of lightdm stealing the systemd dm setting from sddm, so this bug report no longer applies.