Bug 2526278
| Summary: | run-gui-backend: wrong DRM card selection and broken exit code on systems with multiple GPUs (RPi4) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jaroslav Groman <jgroman> | ||||||
| Component: | initial-setup | Assignee: | Martin Kolman <mkolman> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 45 | CC: | jeremy.linton, jkonecny, mkolman, rhbz, rvykydal, tdawson, v.podzimek+fedora | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | aarch64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | initial-setup-0.3.105-1.fc45 | Doc Type: | --- | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2026-09-11 19:03:56 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Jaroslav Groman
2026-08-31 12:14:21 UTC
Submitted PR: https://github.com/rhinstaller/initial-setup/pull/165 I'll note for the record that this bug report and proposed solutions appear LLM-generated, we need a domain expert to verify them. Jaroslav, I don't know if we have an explicit policy on this, but I think in the current climate it is a good idea to disclose substantial AI use any time it appears in something public. Proposing as a Beta FE in case the maintainer agrees with the diagnosis here, it seems like something we'd want to fix in Beta. LLM use is already disclosed in the PR description. I am not aware of any other places it should be added but I am of course open to suggestions. I should also add that I verified the fix on my HW. This just looks like multiple cards because the DT provided framebuffer (which is the vc4), isn't being taken over properly by the vc4 driver, right? What does ls -l /dev/dri/by-path/ print? Because I think we need to know if the https://elixir.bootlin.com/linux/v7.2.2/source/drivers/gpu/drm/vc4/vc4_drv.c#L362 is actually removing the conficts, or there is another driver running here. AKA is this actually a simpledrm->vc4 handover race, or is it something else. AGREED AcceptedBetaFreezeException Discussed at the 2026-08-31 (blocker / freeze exception) review meeting: This is accepted as it can make weston-based, graphical initial-setup unusable on Raspberry Pi. It's not obviously a blocker because we can't find a clear path where a release-blocking image would typically require graphical weston-based initial-setup to work. https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-08-31/f45-blocker-review.2026-08-31-16.01.log.txt > LLM use is already disclosed in the PR description. I am not aware of any other places it should be added but I am of course open to suggestions.
I meant to disclose it *in the bug report itself*, when you use an LLM to generate the bug report content.
So did anyone try if this fix works on real hardware ? E.g. a recent mainstream RPi ? If we have some data about it working then I could do a build just with the linked fix & put it into a Bodhi update. On the other hand, if it was not tested, then I guess I'll have to ask Fedora QA for some hardware to test the fix no. :) Yes, I did test it on real hardware and can confirm it works on RPi4. However currently the PR needs a few small fixes and probably also "udevadm settle" replacement. I am not sure what to replace "udevadm settle" with. If you have any idea please chime in. I think it would be good to get a review from someone who vaguely understands the actual display driver stack before merging anything. Some additional info for the reviewer: It seems that on RPI4 run-gui-backend sometimes evaluates cards too soon before vc4 driver is loaded and sees this: /sys/class/drm/ contains: card0 (simpledrm) card0-Unknown-1 (simpledrm connector) card1 (v3d, render-only) weston cannot use any of those and fails. Sometimes vc4 manages to load before run-gui-backend and the tree is complete: /sys/class/drm/ contains: card0 (simpledrm) card0-Unknown-1 (simpledrm connector, type Unknown) card1 (v3d, render-only, no connectors) card2 (vc4) card2-HDMI-A-1 (vc4 connector, type HDMI-A) card2-HDMI-A-2 (vc4 connector, type HDMI-A) According to logs the race window is approx 2 seconds. Actually that means that instead of `udevadm settle` we can just poll /sys/class/drm for an usable device for some time. I'll update the PR and retest. I have updated the PR and verified that it still works as expected. Note: this fix applies only when weston is spawned directly and NOT through kmscon. kmscon takes control over DRM devices and weston cannot use any of those directly. Maybe there would be some way to configure that in kmscon. I have updated the fix to support running weston from inside kmscon. Claude Opus 4.6 found out that we just need to chvt to a different VT than the one kmscon currently holds. Fixed run-gui-backend verfied working on Fedora-Xfce-Disk-45_Beta-1.2.aarch64 image running on RPi4 with no other changes. Martin, can you please review the fix? Thanks! (In reply to Adam Williamson (Fedora) from comment #15) > Martin, can you please review the fix? Thanks! Yeah - I got hold of a RPi for testing, so I'll do that & merge and release the fix if all looks fine. :) So I've tested on RPi 400 & it still does not show a GUI (TUI works out of the box) both with the patch and without it. As I don't see a regression & there might very well be devices where the fix helps, I'll merge the PR & do a release anyway. Created attachment 2157298 [details]
journal of Initial Setup GUI still failing to start on Rpi 400 with th fix from PR 165
Looking at the boot log it seems that there were no connectors found: run-gui-backend: no KMS-capable DRM device found (cards: card1 card2, connectors: none) They might get dropped by chvt. If you still have RPi400, could you just tweak the code to do card enumeration first and chvt after that? chvt might be dropping vc4 connectors and detection does not find any after the delay it takes to drop them. So there still might be a race condition in there. My RPi4 might be slower in that regard so it still find connectors even when they get removed just after. My apologies - found a typo in my PR in connector detection code:
if ls /sys/class/drm/${card}-* >/dev/null 2>&1 | grep -qvE "Unknown|Writeback"; then
should really be
if ls /sys/class/drm/"${card}"-* 2>/dev/null | grep -qvE "Unknown|Writeback"; then
Sorry about that!
FEDORA-2026-df72d35fa6 (initial-setup-0.3.104-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-df72d35fa6 Fixed the connector enumeration here: https://github.com/rhinstaller/initial-setup/pull/166 Sorry for the inconvenience, Martin! (In reply to Jaroslav Groman from comment #22) > Fixed the connector enumeration here: > https://github.com/rhinstaller/initial-setup/pull/166 > > Sorry for the inconvenience, Martin! No problem, at least it finally works now! :D Edited the Bodhi update to have the initial-setup-0.3.105-1.fc45 build, so it should all be good to go. :) FEDORA-2026-df72d35fa6 has been pushed to the Fedora 45 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-df72d35fa6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-df72d35fa6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. Thanks! Verified the initial-setup-0.3.105-1 update on RPi4 on Fedora-Xfce-Disk-45_Beta-1.3.aarch64, works fine. Attaching bootlog. Created attachment 2157418 [details]
bootlog Fedora-Xfce-Disk-45_Beta-1.3.aarch64 with initial-setup-0.3.105-1
In the end we signed off Beta-1.3 for release without this. Dropping FE status. FEDORA-2026-df72d35fa6 (initial-setup-0.3.105-1.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report. |