> Device-tree-only single-board computers, such as the Raspberry Pi, are not supported
> Virtual machines always boot through UEFI, provided by the ARM build of OVMF (AAVMF). SeaBIOS is not available on arm64.
> Device-tree-only single-board computers, such as the Raspberry Pi, are not supported
Good. The more software vendors require UEFI, the more arm board manufacturers will have to support it.
As an embedded developer I don't hate device-tree-only devices per se, and I have the skills to make any distro (that supports ARM) work on any board, but I absolutely do not have the patience to do it.
FWIW there exist UEFI implementations for Raspberry Pi 4 and 5, they can be used to boot Windows 11 aarch64 images as well as 'generic' Linux distro images, so I suppose they will support this one as well.
I was curious about this, so I looked it up just now. It looks like the project providing UEFI for the Raspberry Pi 5 is abandoned, and compatibility with newer board revisions is reported to be broken (if I correctly understand their "end of support" message on the repo).
Q: Can I run Proxmox VE on a Raspberry Pi or a similar single-board computer?
A: No. An arm64 host must boot through UEFI and describe its hardware through ACPI. Device-tree-only boards and legacy boot are not supported.
Basically no consumer facing arm SBCs, NAS boxes, etc will work with this. Frankly, I see this as a good thing though: Maybe it'll make the SBC market get its stuff together and start actually doing UEFI instead of every board needing a custom build.
Technically it will run on Pis — someone in my YouTube comments already has it going on top of basic Pi OS 13 (disabled NetworkManager and cloud-init to get it going). Someone else on Mastodon already has it running via a custom Pi 4 UEFI image.
Let's say that one does want to use a raspberry pi as a hypervisor and run a bunch of VMs on it... But why? A raspberry pi 5 with current market pricing for the 8GB or 16GB model is a really bad price/performance decision.
Not when you can go to ebay and get a 16GB RAM gently used, ultra small form factor corporate desktop, quad core intel core i5/i7 computer for less money. With real NVME SSD and such. Yeah, it'll consume more like 25 watts idle, not 7W, but as a hypervisor platform it'll also be vastly more capable.
The raspberry pi with 1GB RAM have some very good use cases for things that need their I/O pins, but if you're just trying to use it as a general purpose computer, there's so many other better options.
>Maybe it'll make the SBC market get its stuff together and start actually doing UEFI instead of every board needing a custom build.
If your board needs custom build, it's probably because there's no SPI flash with the bootloader. The board can't describe itself.
This could be solved https://sd-card-images.johang.se/ style: single kernel+rootfs OS image, with the small board-specific bootloader + dtb, which you concatenate to the OS image.
The majority of ARM SBCs can boot UEFI (TianoCore) as a u-boot payload, there are ports for many SoCs/platforms. Raspberry Pi has a port. Libre.computer ships Amlogic and Rockchip with UEFI out of the box.
Nobody just usually bothers because modern u-boot handles all aspects of boot process, incl. display and user interaction. Unless you want Windows on ARM, or want to use beefy server/desktop hardware (ARM non-SBC, non-embedded) with external PCI-e boards which may want to run its embedded .efi rom, you probably don't want UEFI.
> This could be solved https://sd-card-images.johang.se/ style: single kernel+rootfs OS image, with the small board-specific bootloader + dtb, which you concatenate to the OS image.
This is what NixOS does as well, but it still requires the kernel to effectively have support for your specific SoC.
On ARM ACPI/UEFI, ACPI abstracts many parts away reducing the need for this.
The Orange Pi 6 Plus is full UEFI and boots things like FreeBSD natively. It's a bit higher end than a Raspberry Pi, but they're definitely in the SBC market. I'd assume they'll work with Proxmox if they support the newish 5G ethernet chips out of the box.
You can run it on a anything. Now officially. About a year back i had proxmox cluster on 3 orange pi 5+. As long as you have a some sort of Debian it's pretty seamless.
> Maybe they mean there’s no enterprise support, but it technically runs?
Yes, basically this, but in addition to us not providing a kernel and boot method targetting the RPi or other such SBC, but most of the time all will work if you bring that yourself (or plain Debian provides that for your).
I've installed Proxmox on RasPi 4 and up using an unofficial port, it has been running without problems for several years. Now that there is an officially supported version it should only get easier no matter what Proxmox-the-company states.
rpi4 and rpi5 both can use UEFI, and there are various people who already have Proxmox running on a PI5. jeffgeerling has a comment pinned at the top of his Level2jeff video[1], and a comment to that has a link to a rpi5 uefi repository.
This would be interesting on a Spark or two. I don't know how seamless the GPU and networking cluster setup would be when resource sharing between agent and post-training VMs.
> Certainly the fact that Proxmox heavily uses perl is a strike against it.
Besides that being very outdated view of our tech stack, given that we have used Rust for every new development for seven years already and migrated lots of Perl code to it - what's actually wrong with using Perl?
Is all Perl, Python, etc., generically just categorally unusable for someone? Or is the fact that Perl - just like Python and many other languages - packs a lot of built-in features while being easy to modify and interpretable so it can also be used for scripting purposes seriously counted as a "strike against it"? Genuinely curious where these - for me completely unrelatable - opinions stem from.
> Is all Perl, Python, etc., generically just categorally unusable for someone?
I am not the OP but my take as someone who is not keen on Perl or Python:
1. Perl has a dense programming style and is quite opaque to new maintainers. You also have CPAN dependencies to keep track of.
2. Python is more readable than Perl, but has its own issues (dependency hell etc.) and still does not address the issue of dynamic typing and the inability to test correctly, whilst e.g. Rust and Go will just refuse to build.
3. Rust or Go is single-binary shipping. Rust or Go is easier to test.
4. In practical terms the Perl developer population is a shrinking one. Rust and Go are growing.
Ultimately you are selling Proxmox as a hypervisor platform and the expectation is the user should not go hacking around in the shell ? So shipping compiled binaries is safer (easier to audit) than shipping shell scripts that e.g. an attacker with shell access could easily compromise by manipulating the scripts.
But I'm sure you already know all of the above given you have been using Rust for seven years and spending effort migrating Perl scripts .... not exactly something you do for fun. :)
> 1. Perl has a dense programming style and is quite opaque to new maintainers. You also have CPAN dependencies to keep track of.
You can write dense Perl code just like you can write dense Go, Rust, ... code (did you ever write a rust proc_macro and then wanted to edit/extend that like half a year later?); our common coding style in Proxmox is to not use the more sigil-heavy/dense variants of Perl. Re CPAN: that's not used at all in Proxmox VE; we distribute all packages and dependencies solely through Debian package based repositories, with full audit and supply chain integrity.
> 2. Python is more readable than Perl, but has its own issues
See the first part of 1.; besides, both Python and Perl have type annotations that can help.
> 3. Rust or Go is single-binary shipping. Rust or Go is easier to test.
Erm, no, that doesn't change anything? Our daemons are also just single executables. Just like you can "link" any interpreted code into one file, that can be OK for distribution but normally provides no benefit on its own. And they still load modules or dynamic libraries, like the stdlib; both Go and Rust are not fully static (as in compiled with musl) in most common use cases after all. For Rust this is actually a significant pain point: a good and stable Rust ABI that allows native dynamic linking would allow more library reuse and thus faster and smaller/more targeted updates for delivering bug and security fixes. As of now you always have to ship the whole (potentially huge!) binary to deliver an update. In some parts we use Rust dynlibs with a C ABI, but that's rather a crutch.
> 4. In practical terms the Perl developer population is a shrinking one. Rust and Go are growing.
Yes, but that doesn't make Perl or Python a worse language to use, it mostly might hinder potential external devs from contributing. But for one, we have enough Perl experts hired to cover that, and for another, we know of one prolific former contributor with a ton of sysadmin and Perl experience that basically stopped contributing to our newer projects due to the Rust adoption and that being a challenge for them to learn. Language widespreadness also has to be looked at from the POV of the existing developer community, not just the global one. In this case the benefits of Rust still outweigh the cost, and it could also be the other way around, but it's still sad to see experienced contributors being hindered, and it's an example of your point not being as simple as it might sound.
> Ultimately you are selling Proxmox as a hypervisor platform and the expectation is the user should not go hacking around in the shell?
Yes, that's also why I never stated otherwise, my point was that being able to do so is really not a negative thing. Or would Go or Rust become worse if they got better scripting support?
> So shipping compiled binaries is safer (easier to audit) than shipping shell scripts that e.g. an attacker with shell access could easily compromise by manipulating the scripts.
For one, we're not shipping shell scripts, but polished Perl code with a mature module hierarchy and many modern features that Perl does provide over simpler shells like POSIX sh or Bash. And for another, no, binaries are not easier to audit, on the contrary; they are only auditable at all with reproducible builds, which is still not a fully solved issue (albeit we're getting there). Perl you can just look into, and debsums can also tell you at a glance that all files tracked by the Debian packaging system that we reuse are sound and safe, delivered and signed with our release keys. The latter holds for Rust too, that's why it's fine, but not because they are less introspectable due to being binaries. IMO you got it really backwards.
> an attacker with shell access could easily compromise by manipulating the scripts.
An attacker with root access - which is needed to manipulate these "scripts" as you call them - can also just edit the binary, switch it out with a jump script/executable with their rootkit in there, or a recompiled version of the Rust, Go, whatever code with their malicious code in, ... Or how does being a binary magically avoid that?
> Device-tree-only single-board computers, such as the Raspberry Pi, are not supported
Good. The more software vendors require UEFI, the more arm board manufacturers will have to support it.
As an embedded developer I don't hate device-tree-only devices per se, and I have the skills to make any distro (that supports ARM) work on any board, but I absolutely do not have the patience to do it.
FWIW there exist UEFI implementations for Raspberry Pi 4 and 5, they can be used to boot Windows 11 aarch64 images as well as 'generic' Linux distro images, so I suppose they will support this one as well.
I was curious about this, so I looked it up just now. It looks like the project providing UEFI for the Raspberry Pi 5 is abandoned, and compatibility with newer board revisions is reported to be broken (if I correctly understand their "end of support" message on the repo).
I must be out of the loop because I thought all ARM devices needed a device tree
Corpo-only support,
Q: Can I run Proxmox VE on a Raspberry Pi or a similar single-board computer? A: No. An arm64 host must boot through UEFI and describe its hardware through ACPI. Device-tree-only boards and legacy boot are not supported.
Basically no consumer facing arm SBCs, NAS boxes, etc will work with this. Frankly, I see this as a good thing though: Maybe it'll make the SBC market get its stuff together and start actually doing UEFI instead of every board needing a custom build.
Technically it will run on Pis — someone in my YouTube comments already has it going on top of basic Pi OS 13 (disabled NetworkManager and cloud-init to get it going). Someone else on Mastodon already has it running via a custom Pi 4 UEFI image.
I'm adding more details in my blog post here: https://www.jeffgeerling.com/blog/2026/proxmox-ve-arm-offici...
Let's say that one does want to use a raspberry pi as a hypervisor and run a bunch of VMs on it... But why? A raspberry pi 5 with current market pricing for the 8GB or 16GB model is a really bad price/performance decision.
Not when you can go to ebay and get a 16GB RAM gently used, ultra small form factor corporate desktop, quad core intel core i5/i7 computer for less money. With real NVME SSD and such. Yeah, it'll consume more like 25 watts idle, not 7W, but as a hypervisor platform it'll also be vastly more capable.
The raspberry pi with 1GB RAM have some very good use cases for things that need their I/O pins, but if you're just trying to use it as a general purpose computer, there's so many other better options.
There are some lucky people (e.g. me) who got high-RAM Pi4's and Pi5's before the prices spiked
>Maybe it'll make the SBC market get its stuff together and start actually doing UEFI instead of every board needing a custom build.
If your board needs custom build, it's probably because there's no SPI flash with the bootloader. The board can't describe itself.
This could be solved https://sd-card-images.johang.se/ style: single kernel+rootfs OS image, with the small board-specific bootloader + dtb, which you concatenate to the OS image.
The majority of ARM SBCs can boot UEFI (TianoCore) as a u-boot payload, there are ports for many SoCs/platforms. Raspberry Pi has a port. Libre.computer ships Amlogic and Rockchip with UEFI out of the box.
Nobody just usually bothers because modern u-boot handles all aspects of boot process, incl. display and user interaction. Unless you want Windows on ARM, or want to use beefy server/desktop hardware (ARM non-SBC, non-embedded) with external PCI-e boards which may want to run its embedded .efi rom, you probably don't want UEFI.
> This could be solved https://sd-card-images.johang.se/ style: single kernel+rootfs OS image, with the small board-specific bootloader + dtb, which you concatenate to the OS image.
This is what NixOS does as well, but it still requires the kernel to effectively have support for your specific SoC.
On ARM ACPI/UEFI, ACPI abstracts many parts away reducing the need for this.
The Orange Pi 6 Plus is full UEFI and boots things like FreeBSD natively. It's a bit higher end than a Raspberry Pi, but they're definitely in the SBC market. I'd assume they'll work with Proxmox if they support the newish 5G ethernet chips out of the box.
That thing is apparently $366 USD with 16GB of RAM, so my first thought is really "it had damn well better boot things properly if it costs so much".
A Raspberry Pi 5 16GB is $425CAD right now ($300 USD) which isn’t a huge gap.
The price on SBCs is insanity right now because they have RAM.
You can run it on a anything. Now officially. About a year back i had proxmox cluster on 3 orange pi 5+. As long as you have a some sort of Debian it's pretty seamless.
https://github.com/armbian/configng/pull/965
Someone in the forum thread reports it runs on their Pi.
I don’t see why it couldn’t work, since Debian runs fine on these SBCs.
Maybe they mean there’s no enterprise support, but it technically runs?
> Maybe they mean there’s no enterprise support, but it technically runs?
Yes, basically this, but in addition to us not providing a kernel and boot method targetting the RPi or other such SBC, but most of the time all will work if you bring that yourself (or plain Debian provides that for your).
I've installed Proxmox on RasPi 4 and up using an unofficial port, it has been running without problems for several years. Now that there is an officially supported version it should only get easier no matter what Proxmox-the-company states.
rpi4 and rpi5 both can use UEFI, and there are various people who already have Proxmox running on a PI5. jeffgeerling has a comment pinned at the top of his Level2jeff video[1], and a comment to that has a link to a rpi5 uefi repository.
[1] https://www.youtube.com/watch?v=Lg263L1W97w
Sounds like it will work with DGX Spark, though.
If I could install PVE on my M series Mac, nothing would make me happier. It would be such a nice way to recycle such hardware once I finally upgrade.
This would be interesting on a Spark or two. I don't know how seamless the GPU and networking cluster setup would be when resource sharing between agent and post-training VMs.
Unfortunately as of today DGX Spark doesn't support GPU PCI passrhru for KVM
A good alternative is incus and running LXC and or OCI containers, GPU works in those and can be shared with multiple instances
Would be cool to run this on Snapdragon X Mini PCs in a 10 inch rack
I literally am in the process of migrating away from proxmox because they said publicly they would not support arm.
This was necessary, but guys you got the memo too late
They said publicly the Arm support was coming and that was in like 2024 or 2025.
This is the opposite of what happened. Prove me wrong with a URL
https://forum.proxmox.com/threads/proxmox-ve-arm64.183752/
May 2026, but still. Now you prove they said it was NOT coming.
What are you migrating to?
Incus
Don't know about GP but... Something that's not a collection of Perl scripts?
Certainly the fact that Proxmox heavily uses perl is a strike against it. I'm genuinely curious what some reasonable alternatives to it are.
> Certainly the fact that Proxmox heavily uses perl is a strike against it.
Besides that being very outdated view of our tech stack, given that we have used Rust for every new development for seven years already and migrated lots of Perl code to it - what's actually wrong with using Perl?
Is all Perl, Python, etc., generically just categorally unusable for someone? Or is the fact that Perl - just like Python and many other languages - packs a lot of built-in features while being easy to modify and interpretable so it can also be used for scripting purposes seriously counted as a "strike against it"? Genuinely curious where these - for me completely unrelatable - opinions stem from.
> Is all Perl, Python, etc., generically just categorally unusable for someone?
I am not the OP but my take as someone who is not keen on Perl or Python:
Ultimately you are selling Proxmox as a hypervisor platform and the expectation is the user should not go hacking around in the shell ? So shipping compiled binaries is safer (easier to audit) than shipping shell scripts that e.g. an attacker with shell access could easily compromise by manipulating the scripts.But I'm sure you already know all of the above given you have been using Rust for seven years and spending effort migrating Perl scripts .... not exactly something you do for fun. :)
The only issue with Python is performance, which is only an issue if you need performance.
Incus[0] is one.
[0] https://linuxcontainers.org/incus/
You might like IncusOS. I found some rough edges but it has some very nice properties like the OS being immutable, and having no shell.
Oh this is awesome. Going to try this on my OCI Ampere instance.