Fedora ARM 64 Does Not Work On Raspberry Pi 4

Interesting about the HDMI upstream, I got Manjaro working on the same exact Pi. The monitor is an older Dell 27in IPS, so maybe 5 or 7 years old? Not 4K. :slight_smile:

I tried connecting directly from Pi 4B to monitor using the dedicated HDMI port. No joy… the boot sequence works… I see start up, services starting/running, OK, OK, etc. But then nothing but a black screen. When I should see the typical configuration sequence, not even a blinking cursor.

I can setup the FTDI serial on the Pi, I will do that next, to at least get access and see if the logs explain the result.

This setup is really to validate some Wireless adapter driver updates I am doing for friends on GitHub. So I have Pi OS, Manjaro, Ubuntu, event Sparky for ARM on the Pi4B at times. Just seems Fedora glitched this time.

2 Likes

Oh, the image, is the official Pi 4 Fedora image, off the web site. Is this not the correct one?
Fedora-Workstation-37-1.7.aarch64.raw.xz

With serial console connected via FTDI to USB, I still need an id and password to login…

Fedora Linux 37 (Workstation Edition)
Kernel 6.0.7-301.fc37.aarch64 on an aarch64 (ttyS1)

white-ethernet login: fedora
Password:
Login incorrect

white-ethernet login: login: timed out after 60 secon
Fedora Linux 37 (Workstation Edition)
Kernel 6.0.7-301.fc37.aarch64 on an aarch64 (ttyS1)

I can’t seem to find a reference to this via Google. What is the default id and password?

1 Like

I don’t know what the root password is supposed to be, but if you have another Fedora machine you could plug in the microSD card and do:

virt-customize -a /path/to/microsd/card --root-password password:123456 --selinux-relabel

Can’t not a VM. ARM64 Fedora 37 on Pi4B. I can do your suggestion on Windows PC, can I?

Even on the serial console, all I get is…

[ OK ] Started sshd.service - OpenSSH server daemon.
[ OK ] Finished NetworkManager-wa…[0m - Network Manager Wait Online.
[ OK ] Reached target network-online.target - Network is Online.
[ OK ] Reached target remote-fs-p…eparation for Remote File Systems.
[ OK ] Reached target remote-fs.target - Remote File Systems.
Starting rpc-statd-notify.…- Notify NFS peers of a restart…
Starting systemd-user-sess…vice - Permit User Sessions…
Starting virtqemud.service…0m - Virtualization qemu daemon…
[ OK ] Started rpc-statd-notify.s…m - Notify NFS peers of a restart.
[ OK ] Finished systemd-user-sess…ervice - Permit User Sessions.
Starting gdm.service - GNOME Display Manager…
Starting plymouth-quit-wai… until boot process finishes up…
[ OK ] Started gdm.service - GNOME Display Manager.

Fedora Linux 37 (Workstation Edition)
Kernel 6.0.7-301.fc37.aarch64 on an aarch64 (ttyS1)

login:

You guys (Fedora Team) are NOT making this EASY or a nice experience of Fedora 37 on ARM64 Raspberry Pi 4B.

I am not sure what your problem is.
Since you posted this I downloaded the image and put it onto an SD card with this command.

$ sudo arm-image-installer --media=/dev/sdf --image=Fedora-Workstation-37-1.7.aarch64.raw.xz  --resizefs -y --target=rpi4

Once the image was on the SD card I placed it into my RPi 4b and booted it.
Yes, there is no splash screen during boot for me, but I can see the messages by waiting a few seconds after the screen goes black then pressing esc to display the text boot messages.

It booted to the graphical setup screen, and I set up the wifi and my user info.
I then restarted it and it followed the same pattern – black screen until the boot completes then the login screen opened up and I logged in to the desktop.

Note that boot failed with the first time I put the image on the SD, but that time I did not include the --target=rpi4 option. When I redid the image transfer to the same SD card with the target option included it then booted properly.

3 Likes

As per the examples of how to write the SD card, I use Raspberry Pi Imager, which 99% of Pi users will use. Please try using the Raspberry Pi Imager, and see if you get the same result?

In turn I will use the arm-imagine-installer, and see if it works then. But in my multiple test cases, I never get any thing on the HDMI monitor at all, of which I noted above, using the Raspberry Pi Imager tool. I can’t see how the SD card imaging tool is material to the issue… but stranger things have happened.

I have no clue why anyone is talking about VMs… I have never used a VM, can we PLEASE stop referring to a VM, I am only using a actual Pi4B device.

Just as qualification, I have tested ARM64… Kali, Manjaro, Pi OS 11, Ubuntu, etc. all with the same SD cards and Pi4B devices, and the only OS that is not displaying HDMI video image is Fedora 37 ARM64… which seems very odd, hence my post. All tests I used the (official) Raspberry Pi Imager. No changes in cables or HDMI monitor between tests.

1 Like

There is a distinct difference between the rpi-imager and the arm-image-installer.

The arm-image-installer is designed to work with fedora while the rpi-imager is designed to function with several differing linux distros.

Options are different, with the rpi-imager expecting the image to be 100% boot ready as-is while the arm-image-installer uses the --target= option to tell it exactly which SBC is being used and configures u-boot accordingly (while writing the image). Thus the arm-image-installer seems much more flexible for various SBC boards.

The rpi-imager works great for those images it downloads, but maybe not so well for images that require tweaking at install time (like u-boot which is somewhat equivalent to grub and hardware specific in config).

An assumption which is not likely close to the actual percentage.

I am doing that now and will report back.

1 Like

I just completed what you asked as a test.
I used the rpi-imager to write the Fedora-Workstation-37-1.7.aarch64.raw.xz image to my SD card, then booted.
The boot hung as shown.


Note that the last message says it finished the boot loader update.

I now powered down and rebooted and it booted the same as it had previously done with the image written using the arm-image-installer. Booted up and gave me the initial setup screen. I did the setup then did a restart and it booted directly to the graphical login screen.

In both cases it gave a black screen with no splash during the entire boot unless I pressed the esc key, but it does boot regardless of which image writer I used to transfer the image to the SD card.

1 Like

When I do it, via Raspberry Pi Imager, I get to the last startup item Gnome Display Manager, then nothing. Via the serial console…

[ OK ] Started rpc-statd-notify.s…m - Notify NFS peers of a restart.
[ OK ] Finished systemd-user-sess…ervice - Permit User Sessions.
Starting gdm.service - GNOME Display Manager…
Starting plymouth-quit-wai… until boot process finishes up…
[ OK ] Started gdm.service - GNOME Display Manager.

Fedora Linux 37 (Workstation Edition)
Kernel 6.0.7-301.fc37.aarch64 on an aarch64 (ttyS1)

white-ethernet login:

The expectation (based on other distributions) is that once GDM has loaded, the graphical UI would present its self. The fact that i get services start, the ‘Booting…’ message, etc. suggests that the default video (mode) works, but at the GDM UI display, the mode changes, or so was my thought at the time of testing.

And, it would be nice, if the serial console echoed the setup sequence behavior, not just prompt for id and password, when the OS is not really configured as yet. Understand that might be a bit complex to do.

So the bottom line is, the raspberry pi imager does not appear to create the SD card image right. This is a surprise because I have seen several Google referenced examples where they use the Pi imager.

Now using ARM imager… will post again.

1 Like

Well over 100+ Pi users I have interacted with since 2012… have use Win32Imager initially but once Pi foundation released Pi Imager, they have moved to it. In the Pi world, it is king. and it is hard to find anyone that does not use it. if they use Pi OS, they use the imager. So in my experience I can say 99%… with a wink to your comment, outside of that Pi OS 11 only bubble, many even just use ‘dd’ of course. I did considered using dd as well, but happen to read your post, so did not actually test it, but I will at some point.

Why are you needing the serial console?
I use the HDMI port for video and USB for keyboard & mouse. It works flawlessly that way.

The serial console (I assume via an ftdi interface and USB port) is a totally different animal and AFAIK was never intended for gui use.

Serial console works as a serial terminal which in the past has only done graphics using ncurses. The initial install does not configure a user until the boot reaches the initial setup screen which is part of the gui process. The user login from serial console then seems blocked because no user has been defined yet.

Essentially you are using an interface (serial) that probably 99.9% of users never use for an install. Once the install is completed and the user is configured then ssh or serial consoles are usable, but not for the initial setup.

If you want to use a serial interface then I suggest that you do a server or netinst install which does not rely on graphics for setup.

Ok, I had to fire up a Fedora 37 VM (under QEMU/KVM hypervisor) because I did not have a Fedora x86_64 system at hand. Had to set the USB reader/writer to VM, since I have not enabled USB hot plug in the VM as yet.

Note… the official Fedora 37 for ARM guide states that for Windows users… To use 7z.exe, which is something that I know of and have used, but the typical Pi OS 11 oriented user would never understand by default or cold turkey, say if they are new to Pi or even Windows. Why does the documentation not say to use the Windows based Fedora Media Writer?

Note… the official Fedora 37 for ARM guide does not qualify --target=rpi4 (as you referenced above), so the official documentation needs to be updated. I noticed this just now after scanning the documentation, in preparation to test as you did, suggested.

Note… the Fedora 37 ARM image for Pi… is NOT available at the documented link for download. The link is wrong. The correct link for 37 image is only at getfedora.org. This is likely a timing issue, since the 37 image is new. Documentation updates pending? Has yet to catch up?

Got the arm-image-installer installed.

Applied the image via the ARM installer…

# arm-image-installer --image=/home/jibun/Downloads/Fedora-Workstation-37-1.7.aarch64.raw.xz --media=/dev/sdb --target=rpi4

Once the installer is done, will test.

(Also… I downloaded the Fedora Media Writer, and it downloads the LIVE version of the image, not the RAW version of the image. THAT is interesting, and would be confusing for native Pi users, that typically do not use LIVE images. The image created with the Fedora Media Writer for Windows, failed to boot, UNABLE TO READ PARTITION AS FAT is the error reported by the Pi bootloader.)

I am uncertain what docs you are referring to since you did not link it, but here is the official docs from fedora.

Those do state how to install the image.

The doc also states that fedora supports the Pi 4 from 37 onward, and does not state that it requires 37 to use the arm-image-installer. Thus your use of a VM is unnecessary overhead if you already have a fedora system available. I used only F36 to manage the image.

The issue is the link to the media does not actually have the image there, I only found the image at fedora.org. I will post the link I found, when I can… not at my desktop at the moment. Maybe that Google sent me to the wrong link. The link I did use, that page if valid, needs an update.

VM setup was done just because I did not have any live Fedora system at the moment. So I based it on Fedora 37 x86_64… if, did, implied that I believed I needed x86_64 37… not intended.

Fedora media writer is not intended to manage arm images. In fact it is only intended for placing ‘live’ iso images onto a usb.


If you downloaded and installed the live image on the sd card then it would be possible to actually install a system from there to a usb device on the Pi. If no SD card is installed then the Pi will boot from usb. A little off track for this discussion but it is possible.

Well, doing as you did, I used the same tool as you did. However…

I still get nothing but a black screen right after the boot sequence completes. On the serial console I get a login prompt, on the HDMI monitor after GDM service start., nothing on the HDMI monitor, in fact my monitor reports NO SIGNAL after about 30 seconds. The serial console shows a bit more services starting and the following, with a login prompt is:

[ OK ] Finished systemd-user-sess…ervice - Permit User Sessions.
Starting gdm.service - GNOME Display Manager…
Starting plymouth-quit-wai… until boot process finishes up…
[ OK ] Started rpc-statd-notify.s…m - Notify NFS peers of a restart.
[ OK ] Started gdm.service - GNOME Display Manager.

This is on the same hardware setup, that I can use Pi OS 11 ARM64, Manjaro ARM64, Ubuntu ARM64, SparkyLinux ARM64, and Kali ARM64, without issue. If it was a hardware issue, surely at least some of these other distributions would fail in like manner in some way.

To be sure, I have also tried multiple different SD cards, multiple Pi4B devices, etc., Still can’t get Fedora 37 ARM64 image as noted above to display any UI on the HDMI monitor. I see the same boot sequence you do, the same start up sequence you do, but I never get the HDMI monitor display result you do.

Is there any thing I can tweak or change in the config.txt file to force the HDMI configuration to a ‘safe’ mode, or set the Fedora image to a safe mode type of state? At this point open to suggestions, but have come full circle. In my case, Fedora ARM64 Does not work on Raspberry Pi 4, when other OSes work fine.

Did you press the esc key on a usb connected keyboard about 15-20 seconds after applying power?
My Pi first displays the multicolored screen then goes black. After a few seconds time it displays the grub boot menu (in text) and continues booting with a black screen.
Waiting 15-20 seconds them pressing the esc key (sometimes twice) starts the text display of the boot messages so I can watch the boot progress. I do not have a serial console attached, nor anything except the keyboard and mouse attached to usb.

I doubt it is hardware related.
If using the serial console it seems quite probable that fedora sees the serial console and does not fully configure the graphics. Once again, when installing the workstation version, it is designed to boot to graphics mode only and if the serial console is connected that may be interfering.

I cannot see exactly what you are doing but I used a monitor attached to HDMI port 1, and USB connected mouse and keyboard. In that manner everything just worked for me to boot to the graphics desktop.

I think this may be caused by how you are connecting and not either the image or the hardware.

Oh, I needed to give you the link that seemed incorrect…

A Fedora ARM image from: https://arm.fedoraproject.org/. At this link (from the official Fedora documentation page) there is no Pi ARM image to download. So this link is wrong IMHO. I can not use this link to download the actual Fedora 37 Pi 4 Image.

The Fedora workstation link on the above link is for image 36, not image 37. The raw link is below, that illustrates my assertion that the official documentation needs to be updated.

https://download.fedoraproject.org/pub/fedora/linux/releases/36/Workstation/armhfp/images/Fedora-Workstation-36-1.5.armhfp.raw.xz