So far I have not been able to boot up Fedora 37 on a Raspberry Pi 4B. I’d like to be using KDE, but I’ve also tried the Minimal and Workstation images. I’ve tried using rpi-imager and the arm-image-installer multiple times. All images have had their checksums verified.
Each time I get no further than what’s shown in the attached image. It looks like there is a u-boot prompt , but then it is flooded with “eth0:” and pressing any keys makes no difference.
I don’t believe it is the sdcard, since I’ve tried 3 different ones, though they are all Sandisk brand.
Also, RPi OS boots and works fine, as does Manjaro. Centos 8 booted okay, but I can’t recall if they are using u-boot Ubuntu 22.10, which like Fedora uses u-boot, has no problem booting – but all other computers here are running Fedora and I’d prefer to keep it that way.
Here’s my set up:
Raspberry Pi 4b 8gb (how do I find the board revision?)
EEPROM 2022-12-07
Sdcard 32gb and 128gb - Sandisk
HDMI display with touch screen (touchscrren connected and disconnected)
Audio injector hat (installed and uninstalled)
Rasberry Pi 4 fan shim (always installed)
USB keyboard with trackpad
No mouse (I sure hope that’s not the problem!)
Ethernet cable (attached and unattached)
What else can I tell you?
Any ideas or suggestions?
I have used fedora 37 on an RPi4B 8GB with no problems.
What exact file name did you download and place on the sd card?
I used the one from fedora Fedora-Workstation-37-1.7.aarch64.raw.xz and placed it on the sd card with the arm-image-installer.
The command line to write it to the card was sudo arm-image-installer --image=Fedora-Workstation-37-1.7.aarch64.raw.xz --media=/dev/sdf --resizefs --target=rpi4
My first attempt to boot failed. (don’t remember exactly what I saw)
After waiting about 10 minutes I powered the pi off then back on. It then gave me a black screen for an extended period but finally came up with the normal first boot config screen and I was able to do the setup. After the setup was complete it boots though it still remains with the black screen until gdm starts up and the login screen appears.
I do use a logitech mouse (MX Ergo trackball) and keyboard (K350) with the unifying receiver and do not have a touchpad.
I thought I had also tried Fedora-Workstation-37.1.7-aarch.raw.xz, but I guess not.
They all gave the same result shown in the screen shot above. I have left it run like that for as long as 15 minutes once, but I’ll have to say I don’t believe I tried cycling the power to reboot it.
I’m trying that right now with a fresh write of Fedora-KDE-37-1.7.aarch64.raw.xz to an SDcard using:
On the other thread I linked it seemed that the only significant difference between my Pi and his was the Pi firmware version. Mine booted fine and his had problems.
The config file was also something I seem to remember may have been involved.
I do not recall that I changed anything in this, but will post the content just in case.
Mine, The file at /boot/efi/config.txt reads
(This is at the root of what would be the efi partition if the Pi were to boot using efi)
# Options you can adjust for all Raspberry Pi Revisions
# https://www.raspberrypi.com/documentation/computers/config_txt.html
# Raspberry Pi Zero 2W
[pi02]
kernel=rpi3-u-boot.bin
dtoverlay=upstream
# Raspberry Pi 3
[pi3]
kernel=rpi3-u-boot.bin
dtoverlay=upstream
# Raspberry Pi 4
[pi4]
kernel=rpi4-u-boot.bin
dtoverlay=upstream-pi4
# For RPi400 and newer rev RPi4s
arm_boost=1
# Enable DRM VC4 V3D driver
# dtoverlay=vc4-kms-v3d
dtoverlay=vc4-kms-v3d-pi4
dtoverlay=cma,cma-256
max_framebuffers=2
# 4K display support - RPi4 only, only one port possible
# hdmi_enable_4kp60=1
# Raspberry Pi CM4
[cm4]
otg_mode=1
# Default Fedora configs for all Raspberry Pi Revisions
[all]
# Put the RPi into 64 bit mode
arm_64bit=1
# Enable UART
# Only enable UART if you're going to use it as it has speed implications
# Serial console is ttyS0 on RPi3 and ttyAMA0 on all other variants
# u-boot will auto detect serial and pass corrent options to kernel if enabled
# Speed details: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=141195
# Terrible hack to work around U-Boot issues on most devices
enable_uart=1
# Early boot delay in the hope monitors are initialised enough to provide EDID
bootcode_delay=1
# We need this to be 32Mb to support VCHI services and drivers which use them
# but this isn't used by mainline VC4 driver so reduce to lowest supported value
# You need to set this to at least 80 for using the camera
gpu_mem=32
# Use eXtended firmware by default
start_x=1
# Automatically load overlays for detected cameras
camera_auto_detect=1
# Automatically load overlays for detected DSI displays
display_auto_detect=1
# Stop the RPi turning on HDMI monitors on reboot
hdmi_ignore_cec_init=1
# HAT and DT overlays. Documentation at Raspberry Pi here:
# https://www.raspberrypi.org/documentation/configuration/device-tree.md
# Each dtoverlay line is an individual HAT/overlay, multiple lines allowed
# dtoverlay=rpi-sense
# To use this on Fedora you need to use firmware provided device tree, not kernel
# For this functionality follow the following guide:
# https://fedoraproject.org/w/index.php?title=Architectures/ARM/Raspberry_Pi/HATs
I do seem to remember that something about the writing to the sd may have had an error in transferring one file over that had to be done manually. Cannot remember what that was and do not have a spare sd card to test with right now.
Just a quick update.
I did another transfer of the image to an sd card using the command structured as you showed it above.
Following the transfer I inserted it into my Pi and booted with no problems whatsoever. I did absolutely nothing to tweak the image or the files on the sd card and fedora 37 booted to the desktop. I then did the normal first boot setup, including connecting it to my wifi which went flawlessly. My next step was to do a full dnf upgrade which went well and installed the 6.1.7 kernel along with upgrading ~540 other packages. Another boot and the system was back up with the latest software.
If yours still does not boot then it would appear that the issue may be either firmware on the Pi or hardware version since I have no issues at all with installing and booting F37 on my RPi4B.
It’s the fan shim, the dang Pimoroni Fan Shim (1)! It’s using GPIO serial pins (14,15).
I figured it out by removing everything from the RPI4b, laying the bare board on the table top, and booting it up. It started right up, I was able to see the entire boot process and then there it was the setup screen! Way too tiny for my eyes to read, but I can live with that – for now.
According to Pimoroni the fan shim uses the the serial lines (GPIO 14,15) (2). It also uses 3 other header pins, but I’m guessing it has to do with the serial lines. So in boot/config.txt I tried setting enable_uart=0.
Rebooting, the screen went to black after the rainbow screen as others have described. I left it run for 10-15 minutes and rebooted. Nothing but a black screen after 10 or so minutes – (I tried several times) – no matter what keys I pressed during the boot process, and after the screen went to black.
Here’s a question though, why doesn’t Ubuntu (also using U-boot) also have this problem?
That’s as far as I got and don’t know where to go from here. I don’t really like he idea of removing the fan, or having to seek out (or pay for ) another cooling solution.
So what do I try next? Is there anything I might change or add to config.txt?
My fan is connected at the pins shown here. (pins 1 & 6). I have not used that shim and followed the pinout to connect directly to the +3.3V pin (1) and ground (6).
I am using the 25mm fan that was provided as part of the canakit package when I purchased the Pi.
The halt is probably not in u-boot, but instead seems to be at the beginning of the OS load in trying to load drivers and the OS is probably different in the sequence used. I would guess the shim is interfering with the chipset at the point where fedora is trying to configure the ethernet since it errors with the eth0 message.
This is the fan I use (image from amazon) and it is identical to the one originally delivered with the Pi (which is still going strong after 4 years of 24x7 operation.)
I reviewed the links you provided in detail and the first one has this note:
Notes
When mounting or detaching the fan, or assembled Fan SHIM, do not push on the fan
itself, as it is liable to break.
Be careful to mount your Fan SHIM on the correct pins on your Pi, with the Pi shut down
and power disconnected. Shifting it left by one pin or down a full row of pins could cause
damage to both the Fan SHIM and the Pi. Check out the photos in our tutorial if you're
not sure.
Not heatsink-compatible!
Because Fan SHIM uses pin BCM18 to control the fan, and this pin is also used by I2S
audio devices, you won't be able to use I2S DACs like pHAT DAC, pHAT BEAT, and the
IQAudio boards at the same time as Fan SHIM
Dimensions: 45x39x11mm
If you're using it with Ubuntu, the fan control won't work as it uses the serial pins which
are enabled at boot by default. To disable these and allow the shim to work add
enable_uart=0 to system-boot/usercfg.txt.
I suspect on fedora what is referred to there as system-boot/usercfg.txt is actually config.txt on the root level of the second partition of the sd card which will become /boot/efi when fedora is booted.
I barely understand the boot process, but wouldn’t it first go to grub, before loading the kernel?
Thanks for the for the fan suggestion, it is an option. But it looks like those 2 GPIOs are used by the Fan Shim to control the programmable LED, something I’ve never used. So the option I’m looking at is see if I can cut those two traces. I found an issue on Pimoroni’s github (1) that sounds a lot like like my issue. They suggest disabling the uart though raspi-config, but doing that in config.txt for me has not worked.
Maybe and maybe not. As I understand it u-boot loads grub which then launches the boot loader (or maybe u-boot does it all and grub is not involved.) I have not actually dug into the sequence of booting on the Pi.
Depends on how the hardware is configured and the message (eth0 flood) seems it is trying to configure a device that is not responding so it is in an endless loop. Wherever that occurs, but I thought it only got to that point as the kernel is building the device list for /dev.
However, I looked more closely at the last image you posted, and saw this.
That shows the eth0 message appears to be coming from u-boot, so I am not sure how to fix it other than as you already know, remove the fan shim. The fact it finished the setup and booted properly with the fan shim removed appears to be, at present, the workaround for this.
The config.txt file is the one I referred to. I think you mentioned trying the ‘enable_uart=0’ in that file already.
Okay, so here’s where I’m at. Rather than hack the pcb of the fan shim to disconnect the LED circuit, I figured out I could force the state of GPIOs 14 and 15 to a position that doesn’t cause any trouble with the boot process. In config.txt I added this:
# The Pimoroni fan shim LED circuit inteferes with the Fedora boot process. See link below for details
# https://discussion.fedoraproject.org/t/raspberry-pi-4b-hangs-during-u-boot-with-f37/76946
gpio=14,15=pd
Hopefully “pd” is the correct state! I’m away from the computer and am relying on my memory)
With a fresh image of Fedora KDE 37 on an sdcard and only the above mod to config.txt the boot process completes and starts the configuration screens. So the problem may be solved.
Unfortunately though, after tapping the button to complete the install it goes to a black screen with nothing but a cursor. Even after leaving it for a long time nothing changes. I can log into at VT but the font is so small I literally need a magnifying glass to make it somewhat legible – making it difficult to investigate what is going on. Rebooting makes no difference.
I doubt this is related to the original problem, but will need to look into it more. That will have to wait a few days since I’ll be out of town for the weekend.
I am guessing you are using a small lcd screen for the RPi4. If it were attached to a larger monitor things would be easier for trouble shooting since the screen would be readable.
Do you have a micro HDMI to HDMI cable so a larger monitor could be attached to the video out on the Pi.? Or is it already using video out that way and the displayed output is still tiny?.
I also noted that there is a new firmware for the RPi4B dated 2023-01-25, and have already updated my Pi which still boots Fedora 37 after the update.
Thanks for the screen suggestions, but no, the monitor is plenty big. Can’t quite remember, but it’s 14"-15." I believe the physical resolution is 1920x1080, but it gets identified as 3840x2160 until I can get to the display settings. As far as the boot and VT fonts, it’s been a while since I’ve had to set them to something reasonable and will need to relearn how. I need to relearn the config.txt hdmi mode setting that would probably help. Stuff to do now that it will actually boot!
For the moment though I was thinking of making it easy and enabling ssh so I can just work from another console.
Oh, I thought I had seen there was new firmware, but when I last checked with rpi-eeprom-update it hadn’t yet showed up. Thanks, I’ll check again
Pimoroni Fan Shim’s LED circuitry was causing aarch64 Fedora 37 to halt at a U-boot prompt and flooded with “eth0:”
Adding the following lines to the rpi config.txt solves the problem for me.
# The Pimoroni fan shim LED circuit inteferes with the Fedora boot process. See link below for details
# https://discussion.fedoraproject.org/t/raspberry-pi-4b-hangs-during-u-boot-with-f37/76946
gpio=14,15=pd
There are still other issues with the install, those should probably be separate topics
