Description of problem: I wanted to install KDE from the KDE Live CD 35 RC 1.1 using the basic graphics mode, but I was unable to do it because the system ended up with black screen showing just a white underscore in the upper left corner. It does not respond to the `Esc` key, so no logs or further info can be provided. However, it responds to `Ctrl-Alt-Del` and can be restarted without the need to shut the computer down the hard way. This behavior happens on Lenovo ThinkPad T580 using the BIOS mode. In EFI mode, the basic graphics mode works well and KDE can be installed in this mode. Version-Release number of selected component (if applicable): RC 1.1 F35 How reproducible: Always Steps to Reproduce: 1. Try to boot up the KDE Live CD in basic graphics mode in BIOS mode Actual results: Does not boot. Expected results: Should work normally. Additional info: Will also test for the Workstation RC iso and will come back with more info.
Proposed as a Blocker for 35-final by Fedora user lruzicka using the blocker tracking app because: I am proposing this as a blocker because it violates #basic-graphics-mode release criterion.
The Workstation RC Live CD boots without issues on both the BIOS and the EFI mode on T580.
Created attachment 1835538 [details] journal from the failed boot I can confirm Lukas' findings on my Thinkpad T480s. Only the basic graphics mode on BIOS is affected. However, the system is not dead, if you boot without "rhgb quiet", you can see the boot happens pretty much normal, up to the point where the graphical interface should start, I think. Then nothing happens. Also, the "empty screen with a cursor" is just a trick. You can switch to TTY2 and see a standard login prompt, and login as "liveuser" and then "sudo -i" to root. That's what I did, and I attach the system journal from the failed boot.
We had a similar issue in F31 - https://bugzilla.redhat.com/show_bug.cgi?id=1728240 . Maybe something there regressed.
Hmm, the blob we added to systemd at the time - https://github.com/systemd/systemd/pull/13792 - still seems to be in current upstream systemd git...
In today's Go/No-Go meeting, we agreed: This is a clear violation of the "basic graphics mode" criterion https://meetbot.fedoraproject.org/fedora-meeting/2021-10-21/f35-final-go_no_go-meeting.2021-10-21-17.00.log.html#l-84
Bug 2011991 might be related, maybe?
Yeah, it may well be the same thing in fact. I'll try the patch from there. Good spot, thanks.
Hmm, I tried an sddm built with that patch but it doesn't seem to solve the problem in a quick test. https://koji.fedoraproject.org/koji/taskinfo?taskID=77636851 is the scratch build if anyone else wants to try.
Which patch did you apply, the wait for logind1, seat autocreation or the udev rule change? Depending on the problem, there are actually 3 different fixes in that defect. One of the things that really helps with debugging sddm is: diff --git a/sddm.sysconfig b/sddm.sysconfig index b704082..62185e7 100644 --- a/sddm.sysconfig +++ b/sddm.sysconfig @@ -1,3 +1,5 @@ # workaround https://bugzilla.redhat.com/1686675 # see also https://bugreports.qt.io/browse/QTBUG-58508 QML_DISABLE_DISK_CACHE=1 +# enable qDebug messages for debug build +QT_LOGGING_RULES="*.debug=true" along with a debug build.
I've built a debug version with my patches attached (this one only starts the seat if /dev/fb0 exists, so that might itself be a problem). https://koji.fedoraproject.org/koji/taskinfo?taskID=77660016 This version should print much more helpful information about why its not creating a seat (maybe). In my case I get: [root@rpi4-f35 ~]# journalctl -u sddm -p7 -- Journal begins at Mon 2021-10-18 15:04:02 CDT, ends at Fri 2021-10-22 10:27:22 CDT. -- Oct 22 10:27:14 rpi4-f35 systemd[1]: Started Simple Desktop Display Manager. Oct 22 10:27:14 rpi4-f35 sddm[7610]: Initializing... Oct 22 10:27:14 rpi4-f35 sddm[7610]: Starting... Oct 22 10:27:14 rpi4-f35 sddm[7610]: Sleeping for systemd-logind Oct 22 10:27:14 rpi4-f35 sddm[7610]: Sleeping for systemd-logind Oct 22 10:27:14 rpi4-f35 sddm[7610]: Sleeping for systemd-logind Oct 22 10:27:14 rpi4-f35 sddm[7610]: Sleeping for systemd-logind Oct 22 10:27:14 rpi4-f35 sddm[7610]: Sleeping for systemd-logind Oct 22 10:27:15 rpi4-f35 sddm[7610]: Logind interface found (note 5 second delay here) Oct 22 10:27:20 rpi4-f35 sddm[7610]: No graphical seats found, attempt to start one on the main console anyway... Oct 22 10:27:20 rpi4-f35 sddm[7610]: Adding new display...
So, a bit of a sanity check I use to see if its sddm or X/etc is to "dnf install xterm -y" then "xinit" Then startplasma-x11 in the resulting window, and/or `lsof -c Xorg |grep /dev` as well as the ` loginctl ; loginctl show-seat seat0` Without my patch sddm will generally fail to start X if none of the seats are cangraphical. Knowing what Xorg is using as its graphics device and the seat information goes a long way to fixing it. If Xorg fails to start with xinit, then /var/log/Xorg.0.log. OTOH, my patch can make it more consistently start or fail, depending on whether it's a problem with X or CanGraphical because that logind1 race can flipflop the behavior between working and not working depending on the weather.
"Which patch did you apply, the wait for logind1, seat autocreation or the udev rule change?" I applied the entire patch attached to the other bug - https://bugzilla.redhat.com/attachment.cgi?id=1835277&action=diff . I didn't see any other patch. "this one only starts the seat if /dev/fb0 exists, so that might itself be a problem" I'd have to refresh my memory, but yes, I think this might be a problem for the nomodeset case. IIRC we don't have a /dev/fb0 in that case. ISTR that was essentially the problem that we fixed/hacked around in 1728240 - udev was only tagging whatever provided /dev/fb0 as master-of-seat. The comment on the systemd patch - https://github.com/systemd/systemd/pull/13792/files - indicates this too. You can't assume there will always be a /dev/fb0; with nomodeset, that will only be the case if we're booting UEFI (provided by efifb) or if the uvesafb driver is available (which it typically is not in most distro kernels, including Fedora, AIUI).
Yah, I just went poking around in the Xorg drivers directory, seems for things like the cirrus it is just mmaping the PCI device node. In theory, someone could be doing this for a !PCI device as well. Which is the problem with CanGraphical, its second-guessing the capabilities of Xorg's drivers. So the patch I attached to that other defect just delays for 5 seconds and starts seat0 anyway if none of the seats are graphical seems somewhat reasonable, my later tweaking to check for /dev/fb not so much). I guess it is possible that the 5 second delay isn't enough if there is actually a slow starting pci/etc driver. That's the problem with the delay of course, it will never be "right". I'm still interested in which driver X is using in this defect. (aka that lsof output, and/or the xorg log from xinit). The fbdev is tricky because a DRM driver _might_ still be starting, but some of these other cases might not be as hard.
yeah, I'm trying to figure that stuff out now too. Now I'm vaguely remembering all the ins and outs of this from last time we fixed it. xinit actually failed on the VM I'm testing on (which is a Rawhide VM since that's what I had around). Had an error from vesa about ignoring a device with a bound kernel driver. Now I'm testing Workstation, and that doesn't start either. I may have to switch to testing on bare metal to reproduce the issue as Lukas reported it, but I've got some errands to run today so might not be able to get to it (today is actually an RH company holiday so I'm not even supposed to BE here...:>)
Jeremy posted a patch - https://bugzilla.redhat.com/attachment.cgi?id=1836078&action=diff - and scratch build - https://koji.fedoraproject.org/koji/taskinfo?taskID=77673924 - to the other bug. In a quick test on bare metal that looks good here; I can reproduce boot failing with nomodeset with stock sddm, after updating to that sddm, boot succeeded. I'll test a few more times and do an official build probably tomorrow, don't have time tonight.
BTW, is the 'ifdef have_systemd' in the patch strictly correct? Aren't there alternative implementations of the logind interface for systemd-haters?
FEDORA-2021-631306a178 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-631306a178
No, the ifdef isn't really needed, but as you mention and can see in the code it's trying to run on a generic system potentially without systemd, I was playing around with how the long delay should be if we expect to be on a machine with systemd (aka longer) for an upstream patch, along with looping for both services. None of those choices are really wrong and it just happens that the one I posted there removes the entire block if it's built without systemd.
My point was that we could be running on a system which doesn't have systemd, but *does* have a logind implementation. Still, I guess we don't know that such an alternate implementation would have the same slow startup problem, so it probably doesn't make sense to wait in that case...
FEDORA-2021-631306a178 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-631306a178` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-631306a178 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I can confirm this bug on Fedora-KDE-Live-x86_64-35-20211024.n.0.iso ON_QA is misleading since there the new update in unpushed. Moving it back to Modified
Final 1.2 has this one fixed. I am able to boot into Basic graphics driver
I can also confirm Fedora-KDE-Live-x86_64-35-1.2.iso boots into the basic graphics mode in BIOS mode on my Thinkpad T480s.
And I can confirm, too, that the RC 1.2 boots into the basic graphic mode in BIOS mode on my Thinkpad T580.
The other thing to test is whether you ever *don't* get Wayland when you *should* - please test booting without 'basic graphics mode' on various systems, and check the wayland session is always available. Thanks!
(In reply to Adam Williamson from comment #28) > The other thing to test is whether you ever *don't* get Wayland when you > *should* - please test booting without 'basic graphics mode' on various > systems, and check the wayland session is always available. Thanks! Works fine on my systems.
I confirm here at kvm/qemu/virt-manager too. Basic video works fine, qxl driver and BIOS mode. Fedora-KDE-Live-x86_64-35-1.2.iso
FEDORA-2021-631306a178 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.