Indeed, this works well on a Mac using Parallels for virtualisation.
I’d like to add that there’s a workaround and you can work with the app store. You create the app as usual and you see it stop (failing). Then you convert it to custom app and make sure it says something like
platform: linux/arm64
instead of linux/amd64. I just tested this with the open-speed-test app.
This is fun! Kudos, @Joel0!
As long as the image/container has an arm64 version you’re good, most of the popular apps/containers have support for both amd/arm 64-bit, whereas 32-bit arm containers are fading away
Then you convert it to custom app…
Thanks for the workaround! If it’s that easy, this will unlock the ability to run many apps.
As long as the image/container has an arm64 version you’re good…
Yup. It’s not a technical limitation. It’s just that some architecture assumptions were baked in and I need to find them and parameterize them.
I’m actually finding that containers do indeed work. That was not the case on one of the earlier builds I tested on. So, this is progress.
The apps might be hit or miss. I can fix the architecture it’s trying to provision, but in the end it really depends on if the app properly supports aarch64.
Thank you very much for going through all of this work. I don’t have any suitable ARM hardware to test this on but perhaps one day!
I was listening to the TrueNAS Tech Talk episode in which you were discussing porting challenges and having to get into the assembly-level depths of Debian. I have an inkling of your pain: I work at a large Internet web portal that you’ve heard of and one of my tasks has been to modify an awful lot of native code with assumptions to portable code. I salute you!
Just came over here from the TrueNAS Tech Talk episode that aired today, Saturday, August 23, 2025.
@Joel0 , congratulations on getting this working. I’m guessing it wasn’t nearly as straightforward as you made it sound.
I’m hopeful we’ll start seeing more commodity desktop/workstation-level ARM hardware that would be suitable to use as a TrueNAS server now that SystemReady standard seems to really be taking off.
I need to go back and educate myself about why Uboot and other non-UEFI bootloaders historically became the norm on ARM systems. The lack of anything standardized (and in particular, the lack of UEFI) has seeminly needlessly fragmented OS compatibility on ARM SBC devices for at least a decade. At least it can be done on a Raspberry Pi 5, but I’m still missing an understanding of why that’s not the default behavior. Raspberry Pi’s standard bootloader really doesn’t feel like a better experience.
Heh. I didn’t get a chance to adequately express how many weekends I was fighting back and forth with the builds to get everything working.
I’m no expert in the history of Arm, U-Boot, and UEFI, but I can speculate. My understanding is that EFI arose from Itanium, which was for workstations and servers. So EFI had to be full-featured to support modular hardware and provide controls to the end user. In the early days of Arm, its low power consumption made it a popular choice for embedded devices. I assume U-Boot is lighter weight and satisfied all the needs of many embedded devices, so it became a more popular choice and was easier to implement.
I don’t know much about the Raspberry Pi 5, but I can see the appeal for the older pre-UEFI style and the attitude of “we’ve always done it this way.” Writing the OS directly to the SD card is easier than writing the installer iso to a flash drive and booting from that to install it. I always prefer UEFI, but I’m just saying I can see the other side.
As someone who has has extensively used OpenMediaVault over the last two years on Rockchip boards with Armbian’s flavor of Debian I’m excited to try this on real hardware and report back.
RK3588 with EDK2-RK3588
Orion O6 (Cix-P1)
I have it running on a Raspberry Pi 5 16GB using rpi5-uefi, installed on a USB 3.0 SSD.
Going to also attempt to run it on a CM5 with a NAS enclosure I’ve been testing lately.
I’ll post the full setup guide on my blog later, I’m re-doing it a couple times to make sure I have the right order of operations, as UEFI on the Pi is still a bit annoying 
I was trying to run the above image link for TrueNAS on arm on a proxmox instance that I am running on Orange Pi 5 Max. This proxmox is a proxmox-port for arm devices.
I was assuming that with UEFI, I would be able to run this TrueNAS arm build on it. However it did not boot from the image. I checked this same VM config with an arm64 debian image and it did boot from the debian image on the same VM.
May be I am doing something wrong. 
I would expect it to work in Proxmox. Do you know if SecureBoot is enabled? That needs to be disabled. Do you have any boot messages that could help me identify what went wrong?
Ohh yes… It worked!
Disabling secure boot did the trick.
I am still a noob when it comes to proxmox , so the issue was between the keyboard and the chair 
Since I am new to the forum I cannot post an image here.
So the vm config that I have is this
affinity: 4-7
bios: ovmf
boot: order=scsi0;scsi2
cores: 2
efidisk0: local:105/vm-105-disk-0.qcow2,efitype=4m,pre-enrolled-keys=1,size=64M
memory: 7048
meta: creation-qemu=9.2.0,ctime=1756063132
name: truenas
numa: 0
ostype: l26
scsi0: local:105/vm-105-disk-1.qcow2,iothread=1,size=32G
scsi2: local:iso/TrueNAS-SCALE-25.04.2-aarch64.iso,media=cdrom,size=1777376K
scsihw: virtio-scsi-single
smbios1: uuid=14d87ed5-aa54-4127-89fc-dd6700181462
sockets: 2
I am using like 7GB of RAM which below the requirements. But that itch to make it work wanted me to still try it out.
However thanks a lot for this build @Joel0
Now let me see if the installation succeeds.
ohh yes… Its worked… the whole installation worked.
I still can’t post images yet on the forum
Ill post it on twitter : x . com/smarthomecircle
You should get DM from a bot to do a quick tutorial (after you make your account). Afterwards you should be chill to post pictures/links.
Happy to hear that! I’ll eventually add Proxmox to the list of known compatible platforms.
The hardware requirements aren’t actually enforced. I had it running on 4 GB. Just don’t be surprised if weird things happen.
No issues at all.
For me its more about fulfilling my curiosity.
@geerlingguy
I’m trying to run this on my Raspberry Pi 5 (8GB model) with the Penta SATA HAT. After changing the PCI Express link speed from Gen 2 to Gen 3, I can see both of my SATA SSDs in the UEFI menu. My goal is to create a mirrored TrueNAS boot pool. However, the TrueNAS installer only detects the microSD card that contains the UEFI firmware—it doesn’t see the SSDs.
I realized I’m using a different UEFI build than the one you referenced in your post. I’ll swap it out this evening and retest.
@Joel0
In the meantime, is there anything else you’d recommend?
UEFI build I used: ansleythompson/blueberry
UEFI build @geerlingguy used: NumberOneGit/rpi5-uefi
From the TrueNAS installer shell,
lspci. Does the SATA controller show up?lsblk. I’m guessing the drives don’t show up there?dmesg logs, either with dmesg | less or dmesg | grep -i sata and other search terms.Do you know if the disks show up when using the standard Debian 12 installer?
Excellent!
It’s also great that the TrueNAS team showed this in the video.
However, what are the plans that the official source tree adopts this and runs multi-platform? Because, if that’s not happening, then we’re talking about a one-time effort that shows that it could be done, and in a few weeks it’s back to being history. e.g. Goldeneye nightlies aren’t available as ARM, which means this hasn’t been absorbed into the official code base…
There are plans to get these changes incorporated upstream, but don’t read too much into that for whether it will be officially supported. Only time will tell.
My fork is a bit more than a one time effort. I’ve set up CI jobs to pull from upstream daily. The upstream is already on Halfmoon, which is why the Goldeye nightlies are gone temporarily. I just need time to set up more CI jobs; there are no code changes needed.
Even if I were to abandon this project, everything I’ve done is open source, including my CI scripts. It would take somebody else only a small amount of effort to rebase the changes and potentially resolve a few minor conflicts. I have faith in the community that I’m not the only one capable of doing this, and I’ve pushed us past the hardest roadblock.