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
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 
but with software graphics rendering 
, 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,
…AAAND:
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
first.
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
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.
System:
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)
Machine:
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
Battery:
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
CPU:
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
Graphics:
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.
Audio:
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
Network:
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
Bluetooth:
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
Drives:
Local Storage: total: 58.24 GiB used: 5.52 GiB (9.5%)
ID-1: /dev/mmcblk1 model: ASTC size: 58.24 GiB serial: 0x00000137
Partition:
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
Swap:
ID-1: swap-1 type: zram size: 7.64 GiB used: 0 KiB (0.0%) priority: 100
dev: /dev/zram0
Sensors:
System Temperatures: cpu: 50.1 C mobo: N/A
Fan Speeds (rpm): N/A
Info:
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]).