Fedora Account System
Red Hat Associate
Red Hat Customer
The run-gui-backend script fails to start the initial-setup GUI wizard on Raspberry Pi 4 (and other systems with multiple DRM devices) due to two bugs: 1. Wrong DRM card selection: The script picks the primary card using "head -1" which selects the first card numerically. On RPi4 this is card0 (simpledrm, a simple framebuffer) instead of card2 (vc4, the actual display controller with HDMI outputs). Weston fails with "Failed to get drmModeRes" because simpledrm doesn't support KMS modesetting. Additionally, there is a race condition: DRM drivers may still be loading when run-gui-backend enumerates cards. On RPi4, vc4 registers card2 after initial-setup has already started Weston with card0. 2. Silent failure on Weston crash: When Weston fails to start, the autolaunch script never runs, so the EXIT_CODE_SAVE file remains empty. The exit_code variable ends up empty, and "exit" with no argument returns 0 (success). This causes run-initial-setup to incorrectly report "Initial Setup finished successfully, disabling" and disable the service, preventing retry on next boot. Version-Release number of selected component: initial-setup-gui-wayland-generic-0.3.103-1.fc45.aarch64 Reproducible: Always Steps to Reproduce: 1. Install Xfce Fedora 45 Branched 20260826.n.0 image on Raspberry Pi 4 2. Boot for the first time 3. initial-setup.service starts run-gui-backend 4. run-gui-backend picks card0 (simpledrm) instead of card2 (vc4) 5. Weston fails: "Failed to get drmModeRes" / "fatal: failed to create compositor backend" 6. run-initial-setup reports success (empty exit code = 0) and disables the service Actual Results: - Weston starts with wrong DRM device and fails - initial-setup GUI never appears - Service incorrectly reports success and disables itself Expected Results: - Weston should use the KMS-capable DRM device (vc4, card2) - If Weston fails, the exit code should be non-zero so the service remains enabled for retry Additional Information: Suggested fix: 1. Call "udevadm settle --timeout=30" before enumerating cards to wait for all DRM drivers to finish loading. 2. Select the primary card by checking for connector entries in /sys/class/drm/ (e.g., card2-HDMI-A-1) instead of using "head -1". KMS-capable display devices have connector subdirectories; render-only GPUs and simple framebuffers do not. 3. Default exit_code to 1 when EXIT_CODE_SAVE is empty, so Weston failures are correctly reported as errors.
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.