So in a follow up to the original image for Raspberry Pi 5 we’ve come a long way and I now have some Fedora 44 images for Minimal, Workstation and for KDE. The details and links to the images are here, for the Desktop images note the bit about CMA. I’m looking for Feedback to polish them some more in time for F-44 freeze at the end of the month.
12 Likes
Thanks for getting these images together Peter!
What --target= do I use?
I do not see an rpi5 in /usr/share/arm-image-installer/boards.d for f43 or f44.
FYI your webpage uses em-dash for --args, I of course copy-n-pasted the emdash…
You can just use –target=none because we automatically setup the target for RPi devices.
1 Like
Model: Raspberry Pi 5 Model B Rev 1.0
Image: min
Image creation command:
sudo arm-image-installer \
--image=${IMAGE} --target=none --media=/dev/sda --resizefs --showboot \
--addkey=/home/barry/.ssh/id_ed25519.pub \
--args="cma=256M@0M-1024M"
booted 3 times.
First boot got a mmc0: Timeout waiting for hardware interrupt.
Not seen on the other 2 boots.
Fan runs all the time.
1 Like
What type of micro SD card are you using? Can you try a different one?
Model: Raspberry Pi 5 Model B Rev 1.0
Image: kde
Image creation command:
sudo arm-image-installer \
--image=${IMAGE} --target=none --media=/dev/sda --resizefs --showboot \
--addkey=/home/barry/.ssh/id_ed25519.pub \
--args="cma=256M@0M-1024M"
On first boot stopped booting with this showing on the screen
On Second boot went all the way to KDE Begin setup screen.
I then did reboot from a terminal and system is not driving HDMI signal (monitor says nothing coming in).
After powering off and back on I see the boot sequence hang at different points.
And
I source the SD cards I use from https://thepihut.com/ that they say are suitable for RPi use.
Do you know how I inspect from Feroda the details you need?
Yes. Doing that now… report back soon …
Using a different SDcard I see hangs during boot at different points.
I did manage to get the the setup stuff once.
If there is a race in the SDCard/kernel that would be a likely cause of the “random” hangs in boot up.
There might be pattern; either the last system service is systemd-rfkill.socket(?) or systemd-vconsole-setup.service is starting.
I could boot up a current raspbian on the same sdcard and Rpi5 to see if it boot reliably.
Would that be helpful as a data point?
FYI: I saw a message about journal being very slow because btrfs with CoW enabled in /var/log/journal.
Hi Peter,
nice work and have your blog direcktly added at my quiterss, a lil info, did you see my post with the script for rpmfusion, maby would something well placed in the “/home” folder for all where want use PI’s with nvme 
or maby direcktly something like from RPIOS, an backup and deployer for sd’s and nvme drives, just as idea for make it more easy to put your Version of Fedora on these Drive-types
there my post : Fedora installation on Raspberry pi 5 to NVME
Maybe can you take the one or other idea out of the Script if you play a bit around with rpmfusion and the script Maby could you make the whole script as grafical installer for different Fedora distries … or anyone else… put is as running system on sd then expand the sd, with an Grafical deployment tool for nvme + expand the partition and more better as the old one and the 4 different methods of deployment of the filesystem like i have make…
I find your KDE Spin very appealing, especially since the Pi 5 with 8GB is a real powerhouse, and for servers, the 16GB models are not to be underestimated either. But the community needs the possibility for NVMe to work—theoretically, if PCIe is working, the drives should be addressable. If the Pi sources were used for the kernel, it probably wouldn’t be a problem at all, since it already works in RPM Fusion. I took a look at your KDE Spin on an SD card… hmm… an EFI partition, a boot partition, and then the system partition. I think a less complicated approach, maybe using grubby and fewer partitions, might make it easier for NVMe, especially since Fedora is a community project and not everyone is using it in a corporate environment. I’ve been looking at your KDE Spin image 3 Partitions and in the last partition 3 Subfolumes.. i like more a normal flat partition with home in the filesystem .. this filesystem is too complicated for me …
That looks like a classic Btrfs subvolume structure that Fedora uses by default—visible by the split into root, home, and var right at the top level.
What I think about it:
-
Overcomplicated: For a Raspberry Pi server in a basement, this is often ‘overkill’. Making var a separate subvolume is usually done so that logs and databases aren’t rolled back during snapshots, but here it just adds layers.
-
Nesting: Having an empty /home folder inside root (as a mount point) tends to confuse users more than it helps.
-
The ‘flat’ idea: a flat system (one partition, everything in one filesystem) is much more maintenance-friendly on a Pi. If something gets stuck, you can immediately access all data from any other Linux machine without having to mess around with subvolume mounts.
The Fedora directories already show that the full Fedora enterprise structure has been slapped onto the little Pi here.
and this is not really helpful for the “normal” users of PI … in my opinion .. just my opinion ..
so, maby do you overtake the Idea of a grafical Deploymenttool, one part as SD backup one part as nvme-desploymenttool with Partitions expanstion and Userlike 6 diffrent FS-Structures , like the User it’s like’s and selectable .. so maybe Enterprice-Strukture & + Compressed, 2 Subvol’s & Compressed and 2 Flat Strucktures & + Compressed so have you 6 diffrent Struktures where can build it on and they can then be adjusted later at the user’s request/choice at selectable Options in the deploymenttool.
so …
best regards
Blacky
Hello Peter,
Thank you for the work you did!
I’ve tried your installation, but I’ve taken it to extreme – I’ve migrated my RPi4 box under F43 to RPi5 under F44b. Migration process was not complex and I can describe it if you’re interested.
All systems work as described (dmesg header):
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x414fd0b1]
[ 0.000000] Linux version 6.19.9-300.pr1.fc44.aarch64 (mockbuild@94f58ac689c6447cbde5c89576620ab3) (gcc (GCC) 16.0.1 20260305 (Red Hat 16.0.1-0), GNU ld version 2.46-1.fc44) #1 SMP PREEMPT_DYNAMIC Sun Mar 22 18:34:11 UTC 2026
[ 0.000000] KASLR enabled
[ 0.000000] Machine model: Raspberry Pi 5 Model B Rev 1.1
[ 0.000000] efi: EFI v2.11 by Das U-Boot
[ 0.000000] efi: ESRT=0x3e6cb040 RTPROP=0x3e6cd040 SMBIOS 3.0=0x3f719000 MOKvar=0x3e6a9000 INITRD=0x3e698040 RNG=0x3e697040 MEMRESERVE=0x3e696040
However, CPU fan is not active and I believe that’s because the fan is controlled at kernel level, not BIOS (like in PC). I will try to do some research to find how to bring the fan and thermo to life.
1 Like
Correct, there are missing drivers for CPU fan. I covered that where I mentioned thermal control is not in place yet. At this stage you would need a custom kernel with out of tree drivers.
1 Like
None of what you say makes sense TBH.
To note though:
-
NVME is high on my list to support, I do this in my spare time and it wasn’t ready for the images I spun.
-
disk partitioning and layout is the decision of the Fedora SIGS, so in the example you cite it’s the KDE SIGs decision, I think having it be the same as their defaults everywhere makes sense (so same as a x86 laptop etc).
-
I don’t think most users care too much about the partitioning TBH, whether a Pi or other, as long as it works and is stable. Those that do care will likely spins their own.
I haven’t looked at your rpmfusion stuff. I am not interested in things that aren’t in Fedora proper, all my work is towards getting things in Fedora proper. No out of tree hacks.
1 Like
Peter, I remember in one of the posts you were saying that USB disks is still the issue. But I found it working quite well. See some information from the console below:
[rpavlyuk@rpi4-waw overlays]$ sudo dmesg -w
....
[23824.009846] usb 3-1: new high-speed USB device number 2 using xhci-hcd
[23824.136224] usb 3-1: New USB device found, idVendor=152d, idProduct=0580, bcdDevice=11.01
[23824.136240] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[23824.136247] usb 3-1: Product: SSD 512GB
[23824.136252] usb 3-1: Manufacturer: SSD 512GB
[23824.136256] usb 3-1: SerialNumber: 0030025547E37
[23824.137971] scsi host1: uas
[23824.148530] scsi 1:0:0:0: Direct-Access SSD 512GB 1101 PQ: 0 ANSI: 6
[23824.151188] sd 1:0:0:0: Attached scsi generic sg2 type 0
[23824.660651] sd 1:0:0:0: [sdc] 1000215216 512-byte logical blocks: (512 GB/477 GiB)
[23824.660670] sd 1:0:0:0: [sdc] 4096-byte physical blocks
[23824.660815] sd 1:0:0:0: [sdc] Write Protect is off
[23824.660821] sd 1:0:0:0: [sdc] Mode Sense: 5f 00 00 08
[23824.661131] sd 1:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[23824.661233] sd 1:0:0:0: [sdc] Preferred minimum I/O size 4096 bytes
[23824.661240] sd 1:0:0:0: [sdc] Optimal transfer size 33553920 bytes not a multiple of preferred minimum block size (4096 bytes)
[23824.702867] sdc: sdc2 sdc3
[23824.703059] sd 1:0:0:0: [sdc] Attached SCSI disk
[rpavlyuk@rpi4-waw overlays]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 1 29.7G 0 disk
├─sda1 8:1 1 512M 0 part /media/sda1
└─sda2 8:2 1 29.2G 0 part /media/sda2
sdb 8:16 1 0B 0 disk
sdc 8:32 0 476.9G 0 disk
├─sdc2 8:34 0 24G 0 part
└─sdc3 8:35 0 452.9G 0 part
mmcblk1 179:0 0 59.7G 0 disk
├─mmcblk1p1 179:1 0 600M 0 part /boot/efi
├─mmcblk1p2 179:2 0 1G 0 part /boot
└─mmcblk1p3 179:3 0 57.5G 0 part /
zram0 251:0 0 7.7G 0 disk [SWAP]
[rpavlyuk@rpi4-waw overlays]$ sudo mkdir -p /media/sdc2
[rpavlyuk@rpi4-waw overlays]$ sudo mkdir -p /media/sdc3
[rpavlyuk@rpi4-waw overlays]$
[rpavlyuk@rpi4-waw overlays]$ sudo mount /dev/sdc2 /media/sdc2
[rpavlyuk@rpi4-waw overlays]$ sudo mount /dev/sdc3 /media/sdc3
[rpavlyuk@rpi4-waw overlays]$
[rpavlyuk@rpi4-waw overlays]$
[rpavlyuk@rpi4-waw overlays]$ ls -al /media/sdc2
total 212
drwxr-xr-x 11 root root 16384 Jan 1 1970 .
drwxr-xr-x. 7 root root 4096 Mar 25 17:21 ..
drwxr-xr-x 3 root root 16384 Nov 13 22:42 bios
drwxr-xr-x 3 root root 16384 Jan 10 2023 boot
drwxr-xr-x 3 root root 16384 Jan 10 2023 EFI
-rwxr-xr-x 1 root root 2574 Oct 11 2022 Fedora-Legal-README.txt
drwxr-xr-x 3 root root 16384 Jan 10 2023 images
drwxr-xr-x 2 root root 16384 Jan 10 2023 iso
drwxr-xr-x 2 root root 16384 Jan 10 2023 ks
-rwxr-xr-x 1 root root 1063 Oct 11 2022 LICENSE
-rwxr-xr-x 1 root root 95 Nov 5 2022 media.repo
drwxr-xr-x 4 root root 16384 Aug 9 2022 .Spotlight-V100
drwxr-xr-x 2 root root 16384 Jan 10 2023 'System Volume Information'
drwxr-xr-x 3 root root 16384 Feb 4 2023 .Trashes
[rpavlyuk@rpi4-waw overlays]$
[rpavlyuk@rpi4-waw overlays]$ ls -al /media/sdc3
total 5412
drwxrwxrwx 1 root root 4096 Aug 9 2023 .
drwxr-xr-x. 7 root root 4096 Mar 25 17:21 ..
drwxrwxrwx 1 root root 0 Jan 10 2023 '$RECYCLE.BIN'
-rwxrwxrwx 1 root root 5541888 Aug 9 2022 '$UGM'
drwxrwxrwx 1 root root 0 Dec 25 2022 backup
drwxrwxrwx 1 root root 0 Dec 26 2022 @eaDir
drwxrwxrwx 1 root root 0 Aug 9 2023 .fseventsd
drwxrwxrwx 1 root root 4096 Jan 10 2023 'System Volume Information'
drwxrwxrwx 1 root root 0 Dec 17 2022 @tmp
[rpavlyuk@rpi4-waw overlays]$
USB in Linux works fine, what we don’t support is booting from USB disks yet.
Hi Peter 
1.156
It’s a shame that you deny all users their right to their own partitioning choices and don’t consider them fully respected, which I find very unfortunate. Surely there are also some Python programmers among them who want a simple filesystem and not have to rely on a “I have to mount everything securely” and “it has to accept everything as it’s predefined and can’t have any say in the matter.” I find that a bit eccentric. Sure, you’re doing this privately, but what do you think? I, as a Mandrake grandpa, get everything paid for with my pension, which doesn’t even meet the standard, and then I still have to hold out my hands to the state because I’m not exactly well off? Well, at least I give others the option to choose what THEY, the community, want with my script, and I don’t dictate anything, since they have to eat what I decide with my script. I think it’s great that your efforts and NVMe support are so important to you thumbsup, but I think it’s a shame to have requirements that restrict others, because that limits their freedom. But thanks for your answer and feedback.
best regards
Blacky
I am not denying users anything at all, there’s a difference between users creating their own custom creations, which being an open project with an installer and tools to create images etc, they are absolutely free to do.
With pre-canned images we have to make a decision on a good set of defaults, this is exactly the same as the official Raspberry Pi images, and any other similar images, if people want to customise this they are free to do so and MANY MANY people already do their own customer images for the other generations of RPi we support.
So please understand what the difference is, I also don’t see what anything else you mention has to do with Fedora so please keep on topic.
1 Like
oky, then on technical level
Subject: Proposal for a standardized NVMe deployment path (Technical perspective)
Hi Peter,
I appreciate the clarification regarding the distinction between the official ‘pre-canned’ defaults and custom user creations. I completely understand the goal of keeping the official Fedora images as close to mainline and as stable as possible.
However, looking at the RPi 5 as a powerhouse, the transition to NVMe is where most users struggle. From a strictly technical standpoint, manual intervention often leads to broken UUIDs or unstable boot configurations, which then causes more noise in the support forums.
What if we view a streamlined, graphical installer not as a ‘custom hack’, but as a bridge to ensure a clean, UUID-compliant deployment on NVMe?
The idea would be:
- Ensuring 1:1 Parity: Using a tool to deploy the official image onto NVMe while automatically handling the unique hardware offsets and UUID consistency that the RPi 5 requires.
- Reducing Support Overhead: By providing a ‘blessed’ technical path for NVMe deployment, we ensure that users don’t mess up their fstab or bootloader manually.
- User Choice within Defaults: It keeps the ‘official’ image clean, but gives the user a reliable, Fedora-standard way to move that system to high-performance storage in various ways, according to the user’s preference.
I’ve been working on the logic for this to make sure it respects the Fedora architecture. Given your experience with the ARM stack, do you see a way to integrate such a graphical ‘deployment helper’ as an optional but recommended tool for the RPi 5 cycle?
A modern, graphical tool (Wayland-based) would elevate the user experience to a professional level that the hardware deserves and put Fedora a step ahead of other distributions, without compromising the integrity of the base image."
best regards
Blacky
p.s.: this is my last posting in this thread and is a pure suggestion. I don’t expect a direct reply, but it would be great to see this result in a tool for the Fedora community that includes the various features I’ve described in the thread (yes, I see you 
in the chat ).
Hello Peter,
I have an update for you – I’ve made thermo working completely. I’ve ported Raspberry Pi driver into the F44 kernel (I took your kernel as the base) and enabled kernel-level fan control with thermal levels.
Now kernel controls the fan and whole Raspberry Pi 5 thermo interface is stable and balanced.
System info (don’t get confused by ‘rpi4’ in hostname – it left after upgrade):
[rpavlyuk@rpi4-waw ~]$ uname -a
Linux rpi4-waw 6.19.9-300.pr1.fc44.aarch64 #1 SMP PREEMPT_DYNAMIC Sun Mar 29 22:48:21 CEST 2026 aarch64 GNU/Linux
[rpavlyuk@rpi4-waw ~]$
[rpavlyuk@rpi4-waw ~]$ sudo dmidecode -t baseboard
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 3.7.0 present.
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: raspberrypi
Product Name: Raspberry Pi 5 Model B Rev 1.1
Version: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Features: None
Location In Chassis: Not Specified
Chassis Handle: 0x0003
Type: Unknown
Contained Object Handles: 0
[rpavlyuk@rpi4-waw ~]$
[rpavlyuk@rpi4-waw ~]$ modinfo pwm-rp1 | grep -E 'filename|description|author'
filename: /lib/modules/6.19.9-300.pr1.fc44.aarch64/kernel/drivers/pwm/pwm-rp1.ko.xz
description: RP1 PWM driver
author: Naushir Patuck <naush@raspberrypi.com
[rpavlyuk@rpi4-waw ~]$
[rpavlyuk@rpi4-waw ~]$ lsmod | grep pwm
pwm_rp1 12288 1
pwm_fan 24576 0
[rpavlyuk@rpi4-waw ~]$
[rpavlyuk@rpi4-waw ~]$ sudo ls /proc/device-tree | grep -i fan
cooling_fan
[rpavlyuk@rpi4-waw ~]$ ls -al /sys/class/pwm
total 0
drwxr-xr-x 2 root root 0 Mar 30 11:39 .
drwxr-xr-x 72 root root 0 Mar 13 01:00 ..
lrwxrwxrwx 1 root root 0 Mar 30 11:39 pwmchip0 -> ../../devices/platform/axi/1000120000.pcie/pci0002:00/0002:00:00.0/0002:01:00.0/1000120000.pcie:pci@0,0:dev@0,0:pci-ep-bus@1/1f0009c000.pwm/pwm/pwmchip0
[rpavlyuk@rpi4-waw ~]$
[rpavlyuk@rpi4-waw ~]$ for h in /sys/class/hwmon/hwmon*; do
echo "== $h =="
cat "$h/name" 2>/dev/null
grep . "$h"/pwm* 2>/dev/null
grep . "$h"/fan* 2>/dev/null
done
== /sys/class/hwmon/hwmon0 ==
pwmfan
/sys/class/hwmon/hwmon0/pwm1:75
/sys/class/hwmon/hwmon0/pwm1_enable:1
== /sys/class/hwmon/hwmon1 ==
cpu_thermal
[rpavlyuk@rpi4-waw ~]$ cat /sys/class/thermal/thermal_zone0/type
cat /sys/class/thermal/thermal_zone0/temp
cpu-thermal
49600
[rpavlyuk@rpi4-waw ~]$ for c in /sys/class/thermal/cooling_device*; do
echo "== $c =="
cat $c/type
cat $c/cur_state
cat $c/max_state
done
== /sys/class/thermal/cooling_device0 ==
PCIe_Port_Link_Speed_0002:00:00.0
0
1
== /sys/class/thermal/cooling_device1 ==
pwm-fan
1
4
[rpavlyuk@rpi4-waw ~]$
Source RPM is here: Index of /results/rpavlyuk/Fedora-RPi5-kernel/srpm-builds/10271793/
Brief changelog:
- Added driver file
pwm-rp1.cto RPM source, incl. patches - Updated
kernel.spec:
...
## RPi5 Support for Fedora
Source5001: pwm-rp1.c
...
Patch45: 0002-rpi5-pwm-rp1-driver.patch
Patch46: 0003-rpi5-add-rp1-pwm-dt-nodes.patch
Patch47: 0004-rpi5-enable-rp1-pwm1-on-gpio45.patch
Patch48: 0005-rpi5-add-pwm-fan-node.patch
Patch49: 0006-rpi5-add-thermal-fan-control.patch
...
ApplyOptionalPatch 0002-rpi5-pwm-rp1-driver.patch
ApplyOptionalPatch 0003-rpi5-add-rp1-pwm-dt-nodes.patch
ApplyOptionalPatch 0004-rpi5-enable-rp1-pwm1-on-gpio45.patch
ApplyOptionalPatch 0005-rpi5-add-pwm-fan-node.patch
ApplyOptionalPatch 0006-rpi5-add-thermal-fan-control.patch
...
Please, accommodate the driver into your version of kernel, if you find it appropriate.
Hey Roman,
Thanks for the update, ATM I am only adding patches there that are already headed upstream and reviewed. Hence why I have not yet included any of those sorts of patches. There’s a group of us working to get pieces upstream, I had similar success to you when I was testing but I ultimately want all of this to go into Fedora proper, which is the ultimate end game. There will be more stuff added through out the F-44 cycle.
2 Likes