You can create the image on Micro SD card
It boots, you see the notification that Fedora image found, the services and systemd processes list/start/ok… Then nothing. A black screen.
If you wait for a few minutes, the Pi 4 is ping about, so some thing is running on the Pi, but with no image on screen, can tell of keyboard or mouse work, NOTHING. I felt Fedora years ago because it was really frustrating. Was hoping for better experience.
The Pi 4 is solid, I have tested Manjaro, Pi OS 11, Ubuntu, etc. Used multiple SD cards. It is not the hardware or the media. Tried downloading the Fedora 37 ARM 64 image more than once. Nothing but a black screen every time. Tried a different Pi 4 device, still the same result.
Anyone have any idea what to try next? Don’t say it is hardware or media, I have been working with Pi devices since 2012, I know how to cross validate hardware and media issues.
I’ve had reports of issues with HDMI cables on the upstream kernels that work with the RPi foundation kernels that are used by Ubuntu/Manjaro.
Also there’s issues with the upstream kernel and 4K monitors on the RPi, but you don’t mention the sort of monitor or how it’s connected. The 4K issue should hopefully finally fixed with the 6.2 kernel.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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?
(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.
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.