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 ==
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 ==
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.
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
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
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.
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 ==
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.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
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
== 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
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
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
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
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
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
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.
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
