RPi 4 no longer boots after upgrade

RPi 4B,
I have two fedora installs on different sd cards, fedora workstation 39 and fedora silverblue 39. neither boots after the november 16 silverblue update. stock raspberry pi os boots fine

I get a blank screen with _ for about 20 minutes, then a boot loop, or i might get dumped in the grub menu.

selecting the previous kernel makes no difference.

changing ACPI / Device tree or ram limit (3gb) settings in boot menu makes no difference

Please advise

Did you try this?

See this common issue for f39 Some Raspberry Pi boards have no display output on Fedora Server

You need to add nomodeset to the kernel command line.

You should be able to ssh into the RPi4 and run:

sudo grubby --args=nomodeset --update-kernel=/boot/vmlinuz-$(uname -r)
sudo reboot

The screen should stay on now.
I run fedora server and not a desktop version and do not know what happens if you try to start the GUI.

Ninja! @ilikelinux

1 Like

I’m unable to ssh into the pi.
editing the command list in grub after i’m eventually dumped to the grub menu and adding nomodeset to the end of the line which begins with linux results in:

  Booting a command list


after about 10 minutes i was dumped back to the command list editor

removing rhgb quiet had no effect

It actually should for the boot log. There should be more info of the boot available to review.

nonetheless, even adding linux rescue has no effect

here’s the ostree-2-fedora.conf

title Fedora Linux 39.20231116.0 (Silverblue) (ostree:0)
version 2
options rhgb quiet root=UUID=a8f3408d-9bc8-429d-86cb-b45fd1de51f4 rootflags=subvol=root rw ostree=/ostree/boot.1/fedora/188753120b7e646138068d4caf5e64a8733ab8674070c13fc992db82e1102f9d/0
linux /ostree/fedora-188753120b7e646138068d4caf5e64a8733ab8674070c13fc992db82e1102f9d/vmlinuz-6.5.11-300.fc39.aarch64
initrd /ostree/fedora-188753120b7e646138068d4caf5e64a8733ab8674070c13fc992db82e1102f9d/initramfs-6.5.11-300.fc39.aarch64.img
abootcfg /ostree/deploy/fedora/deploy/3fb2424c91b1c1c0dd9167d0c8b0bca1c425390164e158ed6e9ef297d4cf7071.0/usr/lib/ostree-boot/aboot.cfg
fdtdir /ostree/fedora-188753120b7e646138068d4caf5e64a8733ab8674070c13fc992db82e1102f9d/dtb
aboot /ostree/deploy/fedora/deploy/3fb2424c91b1c1c0dd9167d0c8b0bca1c425390164e158ed6e9ef297d4cf7071.0/usr/lib/ostree-boot/aboot.img

You might try removing rhgb quiet and adding /bin/bash so it boots directly to a root shell in single user mode.

I mounted the sd card on another machine and manually removed rhgb quiet from the options in grub.conf, and it booted

for reference, to make the fix permanent:

sudo grubby --remove-args="rhgb quiet" --update-kernel=ALL

I spoke too soon. After installing the November 18th 2023 image, even after manually deleting rhgb quiet, I’m one again unable to boot

Unable to boot or its boot and the screen turns off?

If it screen turns off then add nomodeset to fix that.

No boot. Stuck at _ for an hour, then back to grub

What image are you writing to your sdcard?
Give me the download URL please.

What is the exact arm-image-installer command you use to write that image to the sdcard?

With that info I can try and duplicate what you are seeing.

I flashed Silverblue 38, from getfedora.org, to the sd card. my shell history doesn’t have arm-image-installer for that file, so maybe i used rpi imager, or fedora writer, or dd, or impression

up until now i’ve been avoiding reflashing the card, but it seems my best way forward would be to back up /var/home and /etc, then do a fresh install.

The decision to reinstall jogged my memory, so after saying my prayers and performing some hasty rsyncing, here’s how I installed Silverblue 39, according to the instructions at pi 4 - How do I install Fedora Silverblue on Raspberry Pi 4? - Raspberry Pi Stack Exchange

I first inserted the boot SD card and a USB drive into my workstation. With my boot SD card at /dev/sdc, I downloaded the silverblue 39 aarch64 image and flashed it to a USB drive using Impression, then I formatted the SD card and copied the RPi firmware to it:

wget -P ~/Downloads/Images https://download.fedoraproject.org/pub/alt/releases/39/respins/Silverblue/aarch64/Fedora-Silverblue-ostree-aarch64-39-1.5-respin.iso
wget -P ~/Downloads https://github.com/pftf/RPi4/releases/download/v1.35/RPi4_UEFI_Firmware_v1.35.zip
sudo mkfs.vfat /dev/sdc
mkdir /tmp/ESP
sudo mount /dev/sdc /tmp/ESP
sudo unzip ~/Downloads/RPi4_UEFI_Firmware_v1.35.zip -d /tmp/ESP

I then inserted both the SD card and the USB drive into the SBC and booted. I had previously disabled the 3GB ram limit and set ACPI+DeviceTree, in the firmware settings, so I skipped those steps from the stackoverflow linked above. Then I booted the liveusb and installed to the SD card, preferring automatic partitioning.

Instead of rebooting, I turned the SBC off after installation, then I mounted the SD card on my workstation and copied over the boot partition with the following:

sudo mount (sudo fdisk -l /dev/sdc | awk '/EFI/ { print $1; }') /tmp/ESP
sudo unzip ~/Downloads/RPi4_UEFI_Firmware_v1.35.zip -d /tmp/ESP
sudo umount /tmp/ESP

At that point, I reinserted the SD card into the SBC and rebooted and received a Synchronous Exception error on the boot firmware screen, so I downloaded and copied over v1.34 instead

wget -P ~/Downloads  https://github.com/pftf/RPi4/releases/download/v1.34/RPi4_UEFI_Firmware_v1.34.zip
sudo mount (sudo fdisk -l /dev/sdc | awk '/EFI/ { print $1; }') /tmp/ESP
sudo unzip ~/Downloads/RPi4_UEFI_Firmware_v1.34.zip -d /tmp/ESP
sudo umount /tmp/ESP

At the prompt, I chose “Replace all”. firmware booted as usual, and fedora booted as expected :chipmunk: but with software graphics rendering :frowning_face:, so following the steps at Performance issues Silverblue for Raspberry Pi 4b - #5 by navras, I rebooted to the firmware settings TUI (escape at boot) and 1. disabled the 3GB ram limit, 2. set the system table selection to ACPI+DeviceTree, then rebooted,


boot hangs just after the grub menu. I saw this message:

   Booting `Fedora Linux 39.20231102-n.0 (Silverblue) (ostree:0)`

error: ../../grub-core/disk/efi/efidisk.c:615:failure reading sector 0x12c000
from 'hd1'.
error: ../../grub-core/loader/arm64/linux.c:282:you need to load the kernel

Press any key to continue...

You are beyond my experience now. I do not know much about silverblue.

If you can live with a traditional fedora install then that will work.
If you want to debug the silverblue install maybe compare what is setup on the silverblue sdcard vs. Traditional fedora sdcard.

Also you could ask on the fedora arm mailing list.

Ok then, for reasons I fail to comprehend, I’ve successfully booted the system described in my last message now twice. I have not modified the boot options (kernel args) in any way, for a moment, it seemed i needed to keep the usb stick plugged in in order to boot, but i’ve just now tried and managed to reboot twice with the liveusb unplugged

:man_shrugging: ok i guess. later tonight BE"H I will attempt an rpm-ostree upgrade, and will report in here on the outcome. I have a separate issue related to this rpi kernel bug (patched in rpi os) which is preventing me from starting a wayland session, affecting both silverblue 39 and workstation 38. I will open a new issue for that if 1. i’m able to boot after upgrading the ostree and 2. the issue isn’t resolved in kernels later than 6.5.6

I don’t know about silverblue, but with workstation I have no problems with an RPi4B.

I downloaded the aarch64 raw image.
Used arm-image-installer to write that image to my sd card.
Booted the RPi and configured wifi (kernel 6.5.6)
Did a full dnf upgrade
Rebooted with kernel 6.5.11
System is now running Wayland, Gnome, kernel 6.5.11 and fully updated with no issues so far.

  Host: fedora Kernel: 6.5.11-300.fc39.aarch64 arch: aarch64 bits: 64
    compiler: gcc v: 2.40-13.fc39 Desktop: GNOME v: 45.1 tk: GTK v: 3.24.38
    wm: gnome-shell dm: GDM Distro: Fedora release 39 (Thirty Nine)
  Type: Desktop System: raspberrypi 4-model-b product: Raspberry Pi 4 Model B
    Rev 1.4 v: N/A serial: 10000000bc733468 Chassis: type: 3 serial: N/A
  Mobo: raspberrypi 4-model-b model: Raspberry Pi 4 Model B Rev 1.4
    serial: N/A UEFI: U-Boot v: 2023.07 date: 07/01/2023
  Device-1: hidpp_battery_8 model: Logitech K350 serial: e6-28-b0-cb
    charge: 70% (should be ignored) status: discharging
  Device-2: hidpp_battery_9 model: Logitech MX Ergo Multi-Device Trackball
    serial: 06-e4-a3-3c charge: 55% (should be ignored) status: discharging
  Info: quad core model: N/A variant: cortex-a72 bits: 64 type: MCP
    arch: ARMv8 rev: 3 cache: L1: 320 KiB L2: 1024 KiB
  Speed (MHz): avg: 1600 min/max: 600/1800 cores: 1: 1600 2: 1600 3: 1600
    4: 1600 bogomips: 432
  Features: Use -f option to see features
  Device-1: bcm2711-hdmi0 driver: vc4_hdmi v: N/A bus-ID: N/A
    chip-ID: brcm:fef00700
  Device-2: bcm2711-hdmi1 driver: vc4_hdmi v: N/A bus-ID: N/A
    chip-ID: brcm:fef05700
  Device-3: 2711-v3d driver: v3d v: kernel bus-ID: N/A
    chip-ID: brcm:fec00000
  Device-4: bcm2711-vc5 driver: vc4_drm v: N/A bus-ID: N/A chip-ID: brcm:gpu
  Display: wayland server: X.org v: 1.20.14 with: Xwayland v: 23.2.2
    compositor: gnome-shell driver:
    gpu: vc4-drm,vc4_crtc,vc4_dpi,vc4_dsi,vc4_hdmi,vc4_hvs,vc4_txp,vc4_v3d,vc4_vec
    display-ID: 0
  Monitor-1: HDMI-A-1 model: LG (GoldStar) MP59HT res: 1920x1080 dpi: 102
    diag: 551mm (21.7")
  API: OpenGL v: 3.1 vendor: broadcom mesa v: 23.2.1 glx-v: 1.4 es-v: 3.1
    direct-render: yes renderer: V3D 4.2 device-ID: 14e4:ffffffff
    display-ID: :0.0
  API: EGL Message: EGL data requires eglinfo. Check --recommends.
  Device-1: bcm2711-hdmi0 driver: vc4_hdmi bus-ID: N/A chip-ID: brcm:fef00700
  Device-2: bcm2711-hdmi1 driver: vc4_hdmi bus-ID: N/A
    chip-ID: brcm:fef05700
  API: ALSA v: k6.5.11-300.fc39.aarch64 status: kernel-api
  Server-1: JACK v: 1.9.22 status: off
  Server-2: PipeWire v: 0.3.85 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
  Device-1: bcm2711-genet-v5 driver: bcmgenet v: N/A port: N/A bus-ID: N/A
    chip-ID: brcm:fd580000
  IF: end0 state: down mac: dc:a6:32:c1:54:1f
  Device-2: mmc-pwrseq-simple driver: pwrseq_simple v: N/A port: N/A
    bus-ID: N/A chip-ID: mmc-pwrseq-simple:wifi-pwrseq
  IF-ID-1: wlan0 state: up mac: dc:a6:32:c1:54:20
  Device-1: pl011 driver: uart_pl011 bus-ID: N/A chip-ID: arm:fe201000
  Report: btmgmt ID: hci0 rfk-id: 0 state: up address: AA:AA:AA:AA:AA:AA
    bt-v: 4.1 lmp-v: 7
  Device-2: pl011 driver: N/A bus-ID: N/A chip-ID: arm:serial0
  Local Storage: total: 58.24 GiB used: 5.52 GiB (9.5%)
  ID-1: /dev/mmcblk1 model: ASTC size: 58.24 GiB serial: 0x00000137
  ID-1: / size: 56.65 GiB used: 5.25 GiB (9.3%) fs: btrfs dev: /dev/mmcblk1p3
  ID-2: /boot size: 973.4 MiB used: 242.3 MiB (24.9%) fs: ext4
    dev: /dev/mmcblk1p2
  ID-3: /boot/efi size: 598.8 MiB used: 34.9 MiB (5.8%) fs: vfat
    dev: /dev/mmcblk1p1
  ID-4: /home size: 56.65 GiB used: 5.25 GiB (9.3%) fs: btrfs
    dev: /dev/mmcblk1p3
  ID-1: swap-1 type: zram size: 7.64 GiB used: 0 KiB (0.0%) priority: 100
    dev: /dev/zram0
  System Temperatures: cpu: 50.1 C mobo: N/A
  Fan Speeds (rpm): N/A
  Processes: 274 Uptime: 1d 12h 56m Memory: total: 8 GiB available: 7.64 GiB
  used: 1.75 GiB (22.9%) Init: systemd v: 254 target: graphical (5)
  default: graphical Compilers: gcc: 13.2.1 Packages: pm: rpm pkgs: N/A
  note: see --rpm Shell: Bash v: 5.2.21 running-in: gnome-terminal
  inxi: 3.3.31

I’ve now booted twice successfully after reinstalling. no need to remove rhgb quiet or any other hacks…

unfortunately i am no closer to understanding what the problem was or what fixed it.

I don’t have Silverblue so I can only guess but, does it have bcm283x-firmware[1] installed (Workstation image does)? The base DTB included in that package is much newer that what UEFI v1.34 includes. It seems that the DTB version matters if using Devicetree.
There is also a bug for the DTB, not sure if relevant.[2]
EDIT: Nope, never mind. I don’t think the ISO install would include the firmware… And for the bug, nomodest was the suggested workaround which didn’t work here.

On Workstation, when I switch to Devicetree post-install, it didn’t boot because the initramfs generated under ACPI didn’t include some drivers that it would under Devicetree. Though I’m not sure if this is the case for Silverblue (seems that initramfs comes with the install instead[3]).

  1. https://src.fedoraproject.org/rpms/bcm283x-firmware ↩︎

  2. https://bugzilla.redhat.com/show_bug.cgi?id=2246428 ↩︎

  3. ↩︎