Created attachment 2016909 [details] journal log Description of problem: Raspberry Pi 4 and 400 with Fedora 40 20240213.n.1 won't boot into graphical environment. Text part of boot (U-boot and systemd) is visible as expected, but when the computer switches to graphical, connected display goes black ("no hdmi signal from your device"). See the attached journal log. With nomodeset it boots as expected. Filing against GDM (which is probably the wrong component) as the error in journal is from gdm-x-session: /usr/libexec/gdm-x-session[1276]: (EE) open /dev/dri/card0: No such file or directory ...snip... /usr/libexec/gdm-x-session[1276]: (EE) open /dev/fb0: No such file or directory ...snip... /usr/libexec/gdm-x-session[1276]: (EE) open /dev/dri/card0: No such file or directory ...snip... /usr/libexec/gdm-x-session[1276]: (EE) open /dev/fb0: No such file or directory /usr/libexec/gdm-x-session[1276]: (EE) No devices detected. /usr/libexec/gdm-x-session[1276]: (EE) /usr/libexec/gdm-x-session[1276]: Fatal server error: /usr/libexec/gdm-x-session[1276]: (EE) no screens found(EE) Version-Release number of selected component (if applicable): Linux fedora 6.8.0-0.rc4.20240212git716f4aaa7b48.35.fc40.aarch64 #1 SMP PREEMPT_DYNAMIC Tue Feb 13 00:16:47 UTC 2024 aarch64 GNU/Linux gdm-46.alpha-4.fc40.aarch64 xorg-x11-server-Xorg-1.20.14-32.fc40.aarch64 uboot-images-armv8-2024.01-2.fc40.noarch
Created attachment 2016910 [details] rpm -qa
Proposed as a Blocker for 40-beta by Fedora user lbrabec using the blocker tracking app because: A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility.
Discussed during the 2024-02-19 blocker review meeting: [0] The decision to classify this bug as an "AcceptedBlocker (Beta)" was made as it violates the following criterion: "Release-blocking ARM disk images must boot to the initial-setup utility" for the ARM Workstation disk image (which is release-blocking) on the Raspberry PI 4 (which is a "supported ARM platform" as defined right above that criterion). [0] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-02-19/f40-blocker-review.2024-02-19-17.00.log.txt
Testing 40-20240219.n.0.aarch64: Raspberry Pi 4: Workstation does boot, but has the same issue (and goes graphical with nomodeset). The same issue is when trying to boot KDE. Raspberry Pi 400: neither Workstation nor KDE boots. Workstation-39-1.5.aarch64 boots on both RPi 4 and 400.
well, it's clearly not gdm now. probably kernel or mesa, let's guess mesa. Also CCing Peter as this is obviously a significant ARM bug and he may have some idea about it.
There's actually two problems here.
So the first bug is rhbz #2247873 which is the issue we saw at GA for F-39 which caused us to roll back U-Boot, I have been working on this and hope to have a fix soon. The second bug, which is partially as a result of the first bug, is because the downstream RPi DT that is provided added an incompatibility around the sound which causes an error on the vc4 display driver loading: Jan 25 01:00:09 fedora kernel: vc4_hdmi fef00700.hdmi: Could not register PCM component: -517 I believe this DT change in downstream DT causes the issue: https://github.com/raspberrypi/linux/commit/0491a0aecb999b1a013ad4a6ad3816c535ac6e73 There has been mention of sending the associated kernel change upstream but I am not sure if it has been sent or not. So the first bug is referenced above, and this bug is a kernel bug.
I thought #2247873 was specific to Server because of the whole XFS /boot thing?
(In reply to Adam Williamson from comment #8) > I thought #2247873 was specific to Server because of the whole XFS /boot > thing? Sort of, there was an extra bug introduced upstream that made U-Boot not be able to find the DT on /boot because the ESP is the first partition. So the server issue will still exist after the other bug ceases to exist. That's where this bug kicks in in that use case due to the FW DT problem with the kernel.
FEDORA-2024-20c5181331 (bcm283x-firmware-20240229-1.dc94391.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-20c5181331
FEDORA-2024-20c5181331 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-20c5181331` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-20c5181331 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Fedora Update System from comment #10) > FEDORA-2024-20c5181331 (bcm283x-firmware-20240229-1.dc94391.fc40) has been > submitted as an update to Fedora 40. > https://bodhi.fedoraproject.org/updates/FEDORA-2024-20c5181331 This update fixes the problem for Raspberry Pi 4. Tested Workstation-40-20240223.n.0 (the latest compose nominated) and Workstation-40-20240304.n.0 (the latest from Adam's nightlies page), both hit this bug, then I booted with nomodeset, installed this update and finally I was able to boot to graphical environment. Raspberry Pi 400 doesn't boot at all with 40-20240223.n.0 and 40-20240304.n.0 (tested both as is and with the firmware update), the display is black from the start (but display is on, there is a backlight). 40-20240219.n.0 shows the same behaviour. I couldn't retest the 40-20240213.n.1 from the first comment, as it is not in kojipkgs anymore. fzatlouk pointed out that it could be due to u-boot bump. On 40-20240304.n.0, I downgraded u-boot to 2024.01-2.fc40, but the RPi400 behaves the same, black screen.
> fzatlouk pointed out that it could be due to u-boot bump. On > 40-20240304.n.0, I downgraded u-boot to 2024.01-2.fc40, but the RPi400 > behaves the same, black screen. It's unlikely to be U-Boot in this context, can you file a different bug for this and I'll deal with that problem separately as it looks to be a different bug. My RPi-400 had a broken mSD slot so I'll need to test that with a USB stick. Pleas add karma on the update.
We don't list the Pi 400 as supported at https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi , so I think we can say the release-blocking aspect is fixed if Pi 4 works, and the new bug doesn't have to be a blocker?
(In reply to Adam Williamson from comment #14) > We don't list the Pi 400 as supported at > https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi , so I think > we can say the release-blocking aspect is fixed if Pi 4 works, and the new > bug doesn't have to be a blocker? I would say the RPi4 and RPi400 are the same thing... I almost explicitly use the 400 for all my ARM/IoT testing. I realize there are minor differences, but I think most users will equate the 4 and 400... "The 400 just has an added keyboard" (from a user's POV).
(In reply to Geoffrey Marr from comment #15) > (In reply to Adam Williamson from comment #14) > > We don't list the Pi 400 as supported at > > https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi , so I think > > we can say the release-blocking aspect is fixed if Pi 4 works, and the new > > bug doesn't have to be a blocker? > > I would say the RPi4 and RPi400 are the same thing... I almost explicitly > use the 400 for all my ARM/IoT testing. I realize there are minor > differences, but I think most users will equate the 4 and 400... "The 400 > just has an added keyboard" (from a user's POV). ...almost *exclusively* use the 400... Not explicitly. It's early.
ah, okay, that's unfortunate :/ Still needs to be a separate bug, then, but should probably be proposed as a blocker.
> I would say the RPi4 and RPi400 are the same thing... I almost explicitly > use the 400 for all my ARM/IoT testing. I realize there are minor > differences, but I think most users will equate the 4 and 400... "The 400 > just has an added keyboard" (from a user's POV). From the PoV of graphics they are the same thing, but it seems it's not even producing early output up to the grub2 stage which is a different bug. I suspect it needs to be filed against bcm283x-firmware
> We don't list the Pi 400 as supported at > https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi , so I think > we can say the release-blocking aspect is fixed if Pi 4 works, and the new > bug doesn't have to be a blocker? I have updated this.
I went ahead and filed https://bugzilla.redhat.com/show_bug.cgi?id=2267968 for the 400 issue, so we don't lose it if this update is pushed stable.
FEDORA-2024-20c5181331 (bcm283x-firmware-20240229-1.dc94391.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.