Fedora Linux 40 Beta Blocker Bug Summary Report: 2024-03-19

[Aoife Moloney]

Hi all,

We are very close to the Fedora 40 Beta Go/No-Go meeting (Thursday
21st March @ 1700 UTC in #meeting:fedoraproject.org on Matrix), so
your help reviewing, reproducing, and help in finding and verifying
proposed fixes would be greatly appreciated. Below is a summary report
of the current proposed and accepted blocker bugs for Fedora Linux 40
Beta release.

Please visit the blocker bugs app page for more details
https://qa.fedoraproject.org/blockerbugs/milestone/40/beta/buglist

Summary 2024-03-19


== Proposed Blocker ==
1. mesa - Raspberry Pi 4/400: some GUI assets won't load - NEW
ACTION: Upstream to diagnose issue

2. xorg-11-server - Basic Graphics Mode seems to be broken on Fedora
Workstation RC 1.9 - NEW
ACTION: Maintainers to diagnose issue

== Accepted Blockers ==
1. bcm283x-firmware - Raspberry Pi 400 shows nothing on screen when
booting Fedora 40 images (even before grub) - ON_QA
ACTION: QA to verify fix
https://bodhi.fedoraproject.org/updates/FEDORA-2024-38764db413

2. shim - Live image made with BOOTX64.EFI from latest shim-x64-15.6-2
fails to boot on some boards - VERIFIED
ACTION: N/A

3. shim-unsigned-aarch64 - Fedora fails to boot via
BOOT/bootaa64->fbaa64 on UEFI machines with
EFI_MEMORY_ATTRIBUTES_PROTOCOL - VERIFIED
ACTION: N/A

4. uboot-tools - u-boot doesnt find and load the Fedora provided DTBs
from /boot/dtb - ON_QA
ACTION: QA to verify fix
https://bodhi.fedoraproject.org/updates/FEDORA-2024-5f5380bab6

Accepted Previous Release Blocker
1. distribution - dnf system-upgrade fails on some RPi4 due to system
boot date that pre-dates gpg key  - NEW
ACTION: Maintainer to diagnose



= Bug by Bug Detail =

== Proposed Blockers ==
1. mesa - Raspberry Pi 4/400: some GUI assets won't load -
https://bugzilla.redhat.com/show_bug.cgi?id=2269412 - NEW
When running workstation on the RC 1.2, the graphics on the title bar
and nautilus are missing on Raspberry Pi hardware. The graphics are
visible on x86_64 machines. The issue also appears on aarch64 running
the RC 1.8 and seems to affect GTK 4 applications only. Running RC 1.8
also does not crash on login, however the issue of the missing
graphics is still present. The issue is believed to be upstream. More
testing would be appreciated to verify if the bug exists in other
desktop offerings.

2. xorg-11-server - Basic Graphics Mode seems to be broken on Fedora
Workstation RC 1.9 -
https://bugzilla.redhat.com/show_bug.cgi?id=2270301 - NEW
Booting to live sessions from basic graphics mode does not seem to
reliably work on some bare metal environments, however other hardware
seems to work as expected. Additional testing would be helpful to
understand if this is a reproducible bug or an edge case. Please vote
in the blocker bug app
https://qa.fedoraproject.org/blockerbugs/milestone/40/beta/buglist


== Accepted Blockers ==
1. bcm283x-firmware - Raspberry Pi 400 shows nothing on screen when
booting Fedora 40 images (even before grub) -
https://bugzilla.redhat.com/show_bug.cgi?id=2267968 - ASSIGNED
Raspberry Pi 400 doesn't boot at all with 40-20240223.n.0 and
40-20240304.n.0 when tested both as is and with the firmware update,
the display is black from the start even with the display on.
40-20240219.n.0 shows the same behaviour and on 40-20240304.n.0 when
downgraded u-boot to 2024.01-2.fc40, the RPi400 behaves the same.
A fix has been submitted and is now pushed to the Fedora 40 testing
repo https://bodhi.fedoraproject.org/updates/FEDORA-2024-38764db413
which reportedly fixes the issue.

2. shim - Live image made with BOOTX64.EFI from latest shim-x64-15.6-2
fails to boot on some boards -
https://bugzilla.redhat.com/show_bug.cgi?id=2113005 - NEW
 UEFI LoadOptions that start with NUL cause boot failure. This is fixed
upstream in https://github.com/rhboot/shim/pull/505 but the SecureBoot
signing process requires NX support in the kernel. This is now in
kernel 6.7 and unsigned shim builds showed up recently, so this is
moving closer to being resolved once signed shim builds can be
procured. The sign request can be seen here
https://github.com/rhboot/shim-review/issues/386 and is yet to be
merged

3. shim-unsigned-aarch64 - Fedora fails to boot via
BOOT/bootaa64->fbaa64 on UEFI machines with
EFI_MEMORY_ATTRIBUTES_PROTOCOL -
https://bugzilla.redhat.com/show_bug.cgi?id=2259264 - POST
Fedora boots that are going via the bootaa64->fbaa64 path (installers)
fail to boot on machines that have the EFI_MEMORY_ATTRIBUTES_PROTOCOL.
shim 15.8 is available upstream and has been built for x86
(shim-unsigned-x64-15.8-1) but not aarch64 as of yet and is waiting on
this action to be resolved.

4. uboot-tools - u-boot doesnt find and load the Fedora provided DTBs
from /boot/dtb - https://bugzilla.redhat.com/show_bug.cgi?id=2247873 -
ASSIGNED
Fedora Server images do not boot on the Jetson Nano. Non-Server images
are not affected as they can use the kernel DTBs, and they boot OK.
There is a similar root cause in
https://bugzilla.redhat.com/show_bug.cgi?id=2246428 for this bug also.
A fix has been submitted to the Fedora 40 testing repository
https://bodhi.fedoraproject.org/updates/FEDORA-2024-5f5380bab6 which
should resolve the issues.


== Accepted Previous Release Blocker ==

1. distribution - dnf system-upgrade fails on some RPi4 due to system
boot date that pre-dates gpg key  -
https://bugzilla.redhat.com/show_bug.cgi?id=2242759 - NEW
beta dnf system-upgrade reboot fails on Raspberry Pi 4 (8 gb).
Using dnf system-upgrade log --number=-1, an entry like "Signature
10d5 created at Wed Sep 27 16:33:34 2023 invalid: signature is not
alive" is generated for each rpm in the upgrade list.
Raspberry Pi 4 does not have a hardware real time clock so when the Pi
is booting Fedora system time is at some (arbitrary?) date and time.
During a normal boot chronyd is executed and will set the clock:
"chronyd[571]: System clock wrong by 944623.935135 seconds".
If the gpg key used by DNF during the system-upgrade has a valid
period more recent than the boot time, system-upgrade will fail.
There are various possible workarounds, but none ideal for users to
have to implement, so a fix is still required for this bug to be
resolved.




Kind regards,
Aoife
-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney