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: NEW
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: BetaFreezeException, F31BetaFreezeException F31FinalBlocker, FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2019-07-09 12:02 UTC by Elizabeth Boswell
Modified: 2019-09-18 13:17 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


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

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.


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