Fedora IOT on Raspberry Pi 4 boot loop problem

I have a Rapsberry Pi4 B. I created an SD card with FedoraIOT 33 on it, with the following command:

sudo arm-image-installer --image=Fedora-IoT-33-20210315.0.aarch64.raw.xz --target=rpi4 --media=/dev/mmcblk0 --addkey --addconsole --resizefs

Then I put it in the Pi, and booted it. I noticed it was looping, and attached a serial port cable to see what was going on. This is what I was seeing:

U-Boot 2020.10 (Oct 28 2020 - 08:21:56 +0000)

DRAM:  7.9 GiB
RPI 4 Model B (0xd03114)
MMC:   mmcnr@7e300000: 1, emmc2@7e340000: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: probe failed, error -110
No working controllers found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
"Synchronous Abort" handler, esr 0x96000004
elr: 00000000000a2df0 lr : 00000000000a2e2c (reloc)
elr: 000000003df7bdf0 lr : 000000003df7be2c
x0 : ffffffffffffffe0 x1 : 0000000000000000
x2 : 000000003db54e50 x3 : 0000000000000015
x4 : b900001f58000540 x5 : 0000000000000015
x6 : 000000003dfd31a0 x7 : 000000003dfd31a0
x8 : 000000003dbea190 x9 : 0000000000000008
x10: 0000000000000001 x11: 0000000000000006
x12: 0000000000000a20 x13: 0000000000000001
x14: 000000003db48fb0 x15: 0000000000000021
x16: 000000003df851b0 x17: 122014037044b504
x18: 000000003db54d90 x19: 0000000000000000
x20: 0000000000000010 x21: 0000000000000006
x22: 0000000000000000 x23: 000000003db47368
x24: 000000003dfbb680 x25: 000000000000005c
x26: 000000003dbe6428 x27: 000000003dfbb000
x28: 0000000000000018 x29: 000000003db472e0

Code: eb02003f 54000061 d2800000 d65f03c0 (f9400401)
Resetting CPU ...

resetting ...

This keeps repeating ad infinitum…

What is the problem here?

1 Like

“bad CRC” suggests a corrupt file. Perhaps all the file systems were not unmounted when the SD card was removed or some data was otherwise not flushed properly? I would try running eject /dev/mmcblk0 before removing the SD card. I have no experience with this sort of equipment, however, so I don’t know if that is normally necessary.

You might try the fedora workstation image for arm. It works for me.

I’ve been running Fedora 36 aarch64 on a RPi 4 since its release (as well as earlier releases), but a few weeks ago after installing routine updates I started experiencing this issue.

Linux dns-2 5.18.11-200.fc36.aarch64 #1 SMP PREEMPT_DYNAMIC Tue Jul 12 22:35:02 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

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:   vidconsole
Err:   vidconsole
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
scanning bus xhci_pci for devices... 6 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
966711 bytes read in 105 ms (8.8 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
[rard did not respond to voltage select! : -110
Scanning disk mmcnr@7e300000.blk...
Disk mmcnr@7e300000.blk not ready
Scanning disk mmc@7e340000.blk...
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)

Code: 8b000021 f82068a1 8b030042 cb030084 (f100009f)
UEFI image [0x000000003ca0d000:0x000000003ca24fff] pc=0xda28 '/efi\boot\fbaa64.efi'
Resetting CPU ...

resetting ...

However, eventually it does boot. I have not been able to conclusively verify this because it’s difficult to repeat but it seems like booting will only happen if a monitor is attached. Again, not absolutely sure about that but I have not been able to break out of the boot loop without having a monitor attached and powered on. Even with monitor attached it can still loop several times before booting.

Raspberry Pi 4B (and 400) does require a monitor attached to hdmi0 in order to boot. This is built into the bios of the Pi. Instructions that came with my Pi clearly state that fact.

Have not tried IoT on it so cannot address that problem.

Interesting that I’ve been booting two different Pi 4Bs for well over a year with no monitor attached without issue until recently. Most of those were soft boots after applying updates, but there’s always been at least one cold boot when I initially installed them headless. Odd. :person_shrugging:

Maybe mine is old enough to have firmware that requires the monitor and a firmware update changed that. I Don’t know !

Won’t reboot it just to find out the firmware version or update the firmware since it has been running stable for months untended.

1 Like

Today, after reverting to uboot-images-armv8.noarch 2022.04-1.f36 and fiddling for the last couple days, I updated back to 2022.04-02 and rebooted (monitor attached). Came up first time. After that, no monitor attached, booted first time, every time. Go figure. Rebooted several times with no monitor attached and always came up without throwing any “Synchronous Abort” messages.

Best guess is that my initial installation of uboot-images-armv8 2022.04-2.f36 wasn’t entirely successful and there was a significant fix in 2022.04-2 that was successfully applied when I upgraded back to -2 today.