Bug 1728240 - Cannot start Fedora-KDE-Live (F31) in basic graphics mode on BIOS machine
Summary: Cannot start Fedora-KDE-Live (F31) in basic graphics mode on BIOS machine
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sddm
Version: 31
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Martin Bříza
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker AcceptedFreezeException
Depends On:
Blocks: F31BetaFreezeException F31FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2019-07-09 12:02 UTC by Elizabeth Boswell
Modified: 2019-10-21 18:54 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-21 18:54:22 UTC
Type: Bug


Attachments (Terms of Use)
actual results (1.54 MB, image/jpeg)
2019-07-09 12:02 UTC, Elizabeth Boswell
no flags Details
The journalctl logs from the affected system. (190.37 KB, text/plain)
2019-09-05 10:26 UTC, Lukas Ruzicka
no flags Details
Xorg log - sddm, nomodeset (49.19 KB, text/plain)
2019-09-25 07:46 UTC, František Zatloukal
no flags Details
journal - sddm, nomodeset (284.68 KB, text/plain)
2019-09-25 07:47 UTC, František Zatloukal
no flags Details


Links
System ID Priority Status Summary Last Updated
Github sddm sddm issues 1204 None None None 2019-10-01 15:32:54 UTC
Github systemd systemd issues 13773 None None None 2019-10-14 23:49:59 UTC

Description Elizabeth Boswell 2019-07-09 12:02:51 UTC
Created attachment 1588704 [details]
actual results

Description of problem
"KDE basic graphics mode" won't start in KDE Live Rawhide 20190704 (BIOS USB)


Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1.load KDE-live-x86_64-Rawhide-20190704 onto a USB stick using fedora mediawriter
2.boot from the usb stick and select "troubleshooting" in the boot menu
3.select "Start Fedora-KDE-Live Rawhide in basic graphics mode" and press enter
OR select "Start Fedora-KDE-Live Rawhide in basic graphics mode" and press tab and then press enter

Actual results:
see attached photograph of the screen, nothing changes after 5 minutes of waiting.

Expected results:
loading the KDE live environment in basic graphics mode.

Additional info:
Pressing the power button causes the system to shut down normally.

Comment 1 Ben Cotton 2019-08-13 16:57:05 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 2 Ben Cotton 2019-08-13 19:04:40 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

Comment 3 Lukas Ruzicka 2019-09-05 10:24:39 UTC
I can confirm, this is still valid for Fedora 31, current compose - 20190604. I am attaching journal logs from the machine.

Comment 4 Lukas Ruzicka 2019-09-05 10:26:14 UTC
Created attachment 1611892 [details]
The journalctl logs from the affected system.

Comment 5 Fedora Blocker Bugs Application 2019-09-05 10:27:53 UTC
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.

Comment 6 František Zatloukal 2019-09-06 12:56:58 UTC
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.

Comment 7 Geoffrey Marr 2019-09-09 19:23:25 UTC
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

Comment 8 edpil02 2019-09-14 10:56:21 UTC
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

Comment 9 Zbigniew Jędrzejewski-Szmek 2019-09-16 13:46:12 UTC
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.

Comment 10 František Zatloukal 2019-09-18 13:17:42 UTC
(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.

Comment 11 Jeremy Linton (ARM) 2019-09-20 21:56:15 UTC
Again, it might be worth checking the master of seat "bug" that hit gdm last release. Originally I saw it with sddm.

Comment 12 Adam Williamson 2019-09-23 23:44:11 UTC
Frantisek: how's that bisection going? :)

Comment 13 František Zatloukal 2019-09-24 14:31:17 UTC
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.

Comment 14 Adam Williamson 2019-09-24 15:17:36 UTC
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.

Comment 15 František Zatloukal 2019-09-24 15:44:38 UTC
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.

Comment 16 František Zatloukal 2019-09-24 15:45:39 UTC
(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.

Comment 17 Adam Williamson 2019-09-25 00:11:43 UTC
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.

Comment 18 František Zatloukal 2019-09-25 07:45:59 UTC
(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.

Comment 19 František Zatloukal 2019-09-25 07:46:39 UTC
Created attachment 1618918 [details]
Xorg log - sddm, nomodeset

Comment 20 František Zatloukal 2019-09-25 07:47:29 UTC
Created attachment 1618919 [details]
journal - sddm, nomodeset

Comment 21 František Zatloukal 2019-09-25 07:56:05 UTC
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.

Comment 22 Rex Dieter 2019-09-25 20:21:17 UTC
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?

Comment 23 František Zatloukal 2019-09-26 08:22:14 UTC
(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.

Comment 24 Jeremy Linton (ARM) 2019-10-03 21:41:04 UTC
Try running `loginctl show-seat seat0` on affected machines.

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

Comment 25 František Zatloukal 2019-10-04 12:44:42 UTC
sddm with nomodeset on BIOS:

CanGraphical=no

and on UEFI:
CanGraphical=yes

Comment 26 Adam Williamson 2019-10-04 14:19:42 UTC
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.

Comment 27 Adam Williamson 2019-10-14 22:57:34 UTC
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.

Comment 28 Adam Williamson 2019-10-14 23:49:59 UTC
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.

Comment 29 Adam Williamson 2019-10-14 23:58:39 UTC
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.

Comment 30 Zbigniew Jędrzejewski-Szmek 2019-10-17 10:47:02 UTC
https://github.com/systemd/systemd/pull/13792

Comment 31 František Zatloukal 2019-10-18 07:41:31 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #30)
> https://github.com/systemd/systemd/pull/13792

So, this fixes the issue too.

Comment 32 Zbigniew Jędrzejewski-Szmek 2019-10-18 13:09:58 UTC
OK, I'll build systemd with this a bit later today.

Comment 33 Adam Williamson 2019-10-18 16:55:48 UTC
Thanks! Please submit an update right away too.

Comment 34 Fedora Update System 2019-10-19 03:29:03 UTC
FEDORA-2019-4d8742c07f has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-4d8742c07f

Comment 35 Fedora Update System 2019-10-20 17:13:28 UTC
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

Comment 36 František Zatloukal 2019-10-21 07:31:22 UTC
systemd-243-4.gitef67743.fc31 solves the issue.

Comment 37 Fedora Update System 2019-10-21 18:54:22 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.