When booting with shim 15.6 it seems that fbaa64.efi is crashing on aarch64. This causes issues with some devices when booting using the U-Boot UEFI interface as if the particular device doesn't have support for set variable the device will use fbaa64.efi for all boots and hence it crashes consistently. I've also seen at least one report that this may no be limited to fbaa64.efi. U-Boot 2022.04 (Apr 04 2022 - 00:00:00 +0000) DRAM: 7.9 GiB RPI 4 Model B (0xd03114) Core: 203 devices, 14 uclasses, devicetree: board MMC: mmcnr@7e300000: 1, mmc@7e340000: 0 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial Out: serial Err: serial Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... 3 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi Found DTB mmc 0:2 /dtb/broadcom/bcm2711-rpi-4-b.dtb 27466 bytes read in 31 ms (865.2 KiB/s) 966711 bytes read in 87 ms (10.6 MiB/s) Card did not respond to voltage select! : -110 Scanning disk mmcnr... Disk mmcnr not ready Scanning disk mmc... Found 4 disks No EFI system partition Booting /efi\boot\bootaa64.efi No EFI system partition Failed to persist EFI variables "Synchronous Abort" handler, esr 0x02000000 elr: fffffffffeb48a28 lr : fffffffffeb3f024 (reloc) elr: 000000003ca1aa28 lr : 000000003ca11024 x0 : 000000003ca0d000 x1 : 000000003ca22018 x2 : 000000003ca22000 x3 : 0000000000000018 x4 : 0000000000001488 x5 : 0000000000000000 x6 : 0000000000001000 x7 : 0000000000000000 x8 : 0000000000000007 x9 : 0000000000003ca0 x10: 000000003ca3e040 x11: 00000000b0b87665 x12: 000000007c70ea25 x13: 000000005a827999 x14: 000000006ed9eba1 x15: 000000008f1bbcdc x16: 000000003df97394 x17: 00000000b7ce40b7 x18: 0000000000000011 x19: 000000003caeb000 x20: 0000000000000000 x21: 000000003dc1ba50 x22: 000000003caff2f8 x23: 0000000000000001 x24: 000000003caff000 x25: 000000003caff3c0 x26: 000000003caff3c8 x27: 000000003caff3d0 x28: 000000003caff3d8 x29: 000000003db3e600 Code: 8b000021 f82068a1 8b030042 cb030084 (f100009f) UEFI image [0x000000003ca0d000:0x000000003ca24fff] pc=0xda28 '/efi\boot\fbaa64.efi' Resetting CPU ... resetting ...
FEDORA-2022-e0fa7e16a2 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-e0fa7e16a2
FEDORA-2022-e0fa7e16a2 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-e0fa7e16a2` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e0fa7e16a2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-e0fa7e16a2 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.