Rendered at 03:27:50 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
nh43215rgb 4 hours ago [-]
> 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.
Few things to be wary of..!
tredre3 2 hours ago [-]
> 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.
rnantes 8 hours ago [-]
Would be cool to run this on Snapdragon X Mini PCs in a 10 inch rack
vegadw 8 hours ago [-]
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.
geerlingguy 8 hours ago [-]
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.
>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.
kevinday 8 hours ago [-]
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.
drdexebtjl 8 hours ago [-]
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?
markedathome 8 hours ago [-]
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.
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.
awesomeusername 8 hours ago [-]
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
JuniperMesos 8 hours ago [-]
What are you migrating to?
TacticalCoder 5 hours ago [-]
Don't know about GP but... Something that's not a collection of Perl scripts?
JuniperMesos 1 hours ago [-]
Certainly the fact that Proxmox heavily uses perl is a strike against it. I'm genuinely curious what some reasonable alternatives to it are.
ece 7 hours ago [-]
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.
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.
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.
I'm adding more details in my blog post here: https://www.jeffgeerling.com/blog/2026/proxmox-ve-arm-offici...
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.
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?
[1] https://www.youtube.com/watch?v=Lg263L1W97w
This was necessary, but guys you got the memo too late