Bug 1728240

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

I can confirm, this is still valid for Fedora 31, current compose - 20190604. I am attaching journal logs from the machine.

Created attachment 1611892 [details]
The journalctl logs from the affected system.

Proposed as a Blocker for 31-beta by Fedora user lruzicka using the blocker tracking app because:

 The generic video driver option ('basic graphics mode' - as described in the Basic criteria) on all release-blocking installer and live images must function as intended (launching the installer or desktop and attempting to use a generic driver), and there must be no bugs that clearly prevent the installer or desktop from being reached in this configuration on all systems or on wide classes of hardware.

So, this works just fine on UEFI. It seems sddm doesn't render anything with VESA driver, but there is not anything obvious in journal. 

Installing and running gdm on live media from VT2 while booted into basic graphics driver runs gdm just fine, but KDE Desktop does not start (that might be some other issue, I am not sure if it's even possible to start KDE from gdm).

However, based on this, I'd say it's either problem with sddm itself, or some underlying components specific to sddm (Qt?).

Anyhow, looking at the criteria, this does not seem like a beta blocker.

Discussed during the 2019-09-09 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker" and an "AcceptedFreezeException" was made as it violates the following the criteron:

"The generic video driver option ('basic graphics mode' - as described in the Basic criteria) on all release-blocking installer and live images must function as intended...".

Also accepted as Beta FE as a significant issue that can't be fixed with an upgrade.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-09-09/f31-blocker-review.2019-09-09-16.00.txt

I got the same issue since systemd upgrade 242  to 243 (Im running rawhide).
Seems to be a systemd issue because downgrade solves the problem .I also noticed that when the display kernel module (nouveau or nvidia ) is in initramfs sddm start.
Sent bug report to systemd upstream ,others people seems also  have problem with systemd 243.

https://github.com/systemd/systemd/issues/13296#issuecomment-530671264

sddm boots just fine with systemd-243 in a VM (qxl, vga, or virtio graphics...).
Dunno, if there's no better idea, somebody who can reliably reproduce could bisect this.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #9)
> sddm boots just fine with systemd-243 in a VM (qxl, vga, or virtio
> graphics...).
> Dunno, if there's no better idea, somebody who can reliably reproduce could
> bisect this.

I am not sure testing this in VM is valid, there were some issues regarding VMs and nomodeset. 
I was able to reproduce similar issue with GNOME:
However, gnome-initial-setup after install from Workstation Live went just fine, it hanged up right when it tried to login to user account. Screen stays gray, this happens also when trying to log into an existing account, but with nomodeset.

I am going to try different systemd versions and bisect this tomorrow.

Again, it might be worth checking the master of seat "bug" that hit gdm last release. Originally I saw it with sddm.

Frantisek: how's that bisection going? :)

So, it's starting to look pretty messy. I've tested Basic video driver with BIOS installation on two different machines:

Intel Corporation HD Graphics 530 (rev 06):
gdm with basic video driver works just fine, sddm crashes.

Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09):
gdm gets stuck after login, trying systemd-242 didn't help, I wasn't able to boot F31 with systemd-241 at all (issues unrelated to graphics), it's broken also on F30 Workstation on this PC.

How did sddm work on the second system?

Can we try on more than two systems? :) I can try on my laptops and my test box later today, I guess.

Sure, I'll try one more system that I have in the office for testing. I don't know what gpu is in it from top of my head. Also, I'll upload some X/journal logs tomorrow.

(In reply to Adam Williamson from comment #14)
> How did sddm work on the second system?

sddm worked just fine there and I've got working KDE Desktop.

So, I tested on my test box, which has a Radeon HD 8470D adapter. I tested BIOS 'basic mode' boot for Workstation and KDE F31 nightlies from 2019-09-23.

Workstation booted and installed fine, booted fine on the first boot after install, switched to a desktop fine. Then on the second boot after login I got a black screen with a cursor. However, on a third boot it worked fine, so I think that was just a blip. So mostly Workstation seems fine.

The KDE live, though, fails to boot to a desktop in 'basic graphics' mode at all. It just sticks at 'Starting Terminate Plymouth Boot Screen...' Tried twice, same result both times. Tried on one of my laptops, with the same result.

So, so far I'd agree that KDE spin / SDDM definitely seems to have an issue with 'basic graphics' on BIOS.

(In reply to František Zatloukal from comment #16)
> (In reply to Adam Williamson from comment #14)
> > How did sddm work on the second system?
> 
> sddm worked just fine there and I've got working KDE Desktop.

Nevermind, it's failing there today too, I've probably missed something.

Created attachment 1618918 [details]
Xorg log - sddm, nomodeset

Created attachment 1618919 [details]
journal - sddm, nomodeset

For sddm, having system-242 makes no difference, it's still failing in BIOS/nomodeset and I am not able to boot F31 with systemd-241.

Can you try adding

QMLSCENE_DEVICE=softwarecontext
export QMLSCENE_DEVICE

to /etc/sddm/Xsetup, and restart sddm (systemctl restart sddm, or reboot) to see if that helps any?

(In reply to Rex Dieter from comment #22)
> Can you try adding
> 
> QMLSCENE_DEVICE=softwarecontext
> export QMLSCENE_DEVICE
> 
> to /etc/sddm/Xsetup, and restart sddm (systemctl restart sddm, or reboot) to
> see if that helps any?

That didn't help at all, no changes to previous behavior.

Try running `loginctl show-seat seat0` on affected machines.

Does CanGraphical=yes/no change between the affected machines?

sddm with nomodeset on BIOS:

CanGraphical=no

and on UEFI:
CanGraphical=yes

That sounds familiar, we've had this go-round with GDM before, I think...

...yeah, it was one of the things that broke GDM for 'basic graphics mode' in the F30 cycle: https://bugzilla.redhat.com/show_bug.cgi?id=1683197

basically, CanGraphical is not always reliable, so don't rely on it. Ray decided to just drop the CanGraphical stuff from GDM entirely; another option would be to do what Ubuntu did to work around this, where they had the login manager wait a certain amount of time for a CanGraphical seat to show up, but if none showed up in that time, just went ahead anyway.

So, poking around at this a bit more...

the CanGraphical stuff in SDDM is not new. It seems to have landed in 0.17.0, which appeared in Fedora 28. So I tested BIOS nomodeset ('basic graphics') on F28, F29 and F30 KDE lives, and it failed on all three. loginctl shows CanGraphical=no each time. This has been broken since F28, but we didn't notice; presumably we either only tested basic graphics mode for Workstation, or only tested it on UEFI for KDE.

I can see three...ish...potential ways to fix this:

1) easy downstream hack - patch SeatManager::initialize() , at https://github.com/sddm/sddm/blob/develop/src/daemon/SeatManager.cpp#L96 , to just always create seat0 and return immediately (i.e. have it always do what it currently does only if logind/CK2 aren't in use). I believe this is also basically what it did before.

2) correct-ish, upstreamable 'fix' - patch the seat manager to treat seat0 (or just the first discovered seat?) as CanGraphical if no seat actually shows up as CanGraphical after, say, ten seconds. This is I believe what Ubuntu did to gdm for a while.

3) patch out all the CanGraphical consideration so we still handle seats appearing and disappearing as we do now, but just assume they're always graphical-capable.

CCing Ray (GDM maintainer) just in case he has any thoughts on the options here, as this *is* very much comparable to the situation we had with GDM.

Also filed a systemd issue on the underlying problem of `CanGraphical` not being set correctly in this case, as it's still ultimately a problem in how this whole setup is supposed to work and systemd did not have an open issue for it.

Just to confirm we're on the right track here, I did a quick scratch build with the simple hack to make initialize() just set up seat0 and return, and that works. I can boot with nomodeset with that scratch build and get to SDDM successfully.

https://github.com/systemd/systemd/pull/13792

(In reply to Zbigniew Jędrzejewski-Szmek from comment #30)
> https://github.com/systemd/systemd/pull/13792

So, this fixes the issue too.

OK, I'll build systemd with this a bit later today.

Thanks! Please submit an update right away too.

FEDORA-2019-4d8742c07f has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-4d8742c07f

systemd-243-4.gitef67743.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-4d8742c07f

systemd-243-4.gitef67743.fc31 solves the issue.

systemd-243-4.gitef67743.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.

A very similar bug has shown up in F35:

https://bugzilla.redhat.com/show_bug.cgi?id=2016310

if folks can help debug, that'd be great. It doesn't seem like systemd dropped the patch, so the cause must be something else now, but the result is exactly the same (booting KDE with nomodeset results in a blank tty1 on BIOS, works fine on UEFI).