Hi folks,

As we are gearing up to the Fedora Linux 40 Beta release, there are a
number of blockers that need attention. Below is a summary of current
accepted and proposed blockers for F40 Beta[1]. As a reminder, the Beta
release target date is Tuesday 19th March[2], and the Go/No-Go meeting is
scheduled for next Thursday, 14th March[3].


== Proposed Blocker ==
1. anaconda - UEFI installs using bootupd do not write an EFI boot manager
entry, can make it hard to boot the installed system - NEW
ACTION: Maintainer to diagnose issue

== Accepted Blockers ==
1. bcm283x-firmware - Raspberry Pi 400 shows nothing on screen when booting
Fedora 40 images (even before grub)
ACTION: IoT team to provide a fix

2. desktop-backgrounds - We need F40 backgrounds - MODIFIED
ACTION: QA to verify
https://bodhi.fedoraproject.org/updates/FEDORA-2024-f0fdde3a5d

3. shim - Live image made with BOOTX64.EFI from latest shim-x64-15.6-2
fails to boot on some boards - NEW
ACTION: Maintainer to provide updated package if possible

4. shim-unsigned-aarch64 - Fedora fails to boot via BOOT/bootaa64->fbaa64
on UEFI machines with EFI_MEMORY_ATTRIBUTES_PROTOCOL - POST
ACTION: Maintainer to provide updated build if possible

5. uboot-tools - u-boot doesnt find and load the Fedora provided DTBs from
/boot/dtb - ASSIGNED
ACTION: Maintainer to diagnose

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. anaconda - UEFI installs using bootupd do not write an EFI boot manager
entry, can make it hard to boot the installed system -
https://bugzilla.redhat.com/show_bug.cgi?id=2268505 - NEW

UEFI installs using bootupd do not write an EFI boot manager entry. This
can make the installed system difficult to boot - it will depend on the
system's firmware implementation and configuration. It is affecting Fedora
IoT images built with os-build and all Fedora Atomic Desktop images. We
need the anaconda team to work on a fix for this.


== 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.
The last working firmware is bcm283x-firmware-20231123-1.93d3f79.fc40, see
https://koji.fedoraproject.org/koji/buildinfo?buildID=2324215. The IoT team
will need to work on a fix to resolve this issue.


2. desktop-backgrounds - We need F40 backgrounds -
https://bugzilla.redhat.com/show_bug.cgi?id=2264153 - MODIFIED

There are no F40 backgrounds available yet for desktop. Work is being done
at https://gitlab.com/groups/fedora/design/-/epics/32 and backgrounds have
been submitted for testing
https://bodhi.fedoraproject.org/updates/FEDORA-2024-f0fdde3a5d


3. 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


4. 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.


5. 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. We
need the ARM team to provide a fix for this.



== 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.





[1] https://qa.fedoraproject.org/blockerbugs/milestone/40/beta/buglist
[2] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html
[3] https://calendar.fedoraproject.org/meeting/10758/

-- 

Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to