OpenMediaVault 8, or OMV8 for shorts, codenamed “Synchrony” has been released, now supporting only 64-bit architectures (AMD64 and ARM64), and dropping 32-bit systems based on the i386, armel, and armhf architectures.
OpenMediaVault is a popular, open-source network-attached storage (NAS) solution based on Debian Linux that’s been around for many years. I had my first experience with it in 2017 when I reviewed FriendlyELEC NanoPi NEO NAS Kit based on a NanoPi NEO2 SBC with an Allwinner H5 64-bit Cortex A53 SoC, but sadly not recommended for OMV8 (more on that below). The main reason for killing 32-bit support is that the Salt Project only supports 64-bit builds.
OpenMediaVault 8 highlights:
- Upgrade to Debian 13 (Trixie).
- Replace cpufrequtils with linux-cpupower
- Improve several user and group-related RPCs. Developers should note that the RPCs UserMgmt::enumerateSystemUsers, UserMgmt::enumerateUsers, UserMgmt::enumerateAllUsers and UserMgmt::getUserList now return only basic user information. Set the parameter detail to full to get more detailed user information. This API change was done to improve the RPC response times.
- Display updated modules in notifications after configuration changes have been applied.
- Display old versions of upgradable packages on the update page.
- Use pool instead of server directive in chrony configuration by default. This can be customized via the OMV_CHRONY_SERVER_POOL_DIRECTIVE environment variable.
- Add support for WPA3 (SAE) authentication for wireless connections.
- Prevent scripts/tools from getting stuck when calling mail/sendmail if email notifications are disabled.
- Add ability to SMB shares to limit the reported disk size for Time Machine.
As I write this, I can see a quick fix (8.0.2) was released on Christmas day with improvements to cpupower deployment, and a fix for a postfix issue.
If we look at the list of supported Raspberry Pi boards, any board with a 64-bit processor and OS continues to be supported. But the Raspberry Pi 1 and Zero variants are definitely not supported, and it’s more complicated for the Raspberry Pi 2 Model B: most variants are based on BCM2836 Cortex-A7 SoC, and not supported, but the Raspberry Pi 2 Model B v1.2 is supported since it’s powered by a BCM2837 Arm Cortex-A53 SoC, as long as you installed a 64-bit OS.
What about the NanoPi NEO2 mentioned in the first part of this port? It’s a 64-bit hardware platform, but it’s sadly not recommended for now, since Armbian images used to rely on a 32-bit rootfs as explained on the OMV8 compatibility list:
Armbian may default to a 32-bit bit userland which makes the board incompatible with OMV8. The NanoPi Neo2 is one example and is not recommended for OMV
They say this could be fixed with a custom ARM64 build. However, I can see the NanoPi NEO2 image built on December 26 is already a 64-bit binary, so OMV8 should work:
|
1 2 3 4 5 |
jaufranc@CNX-LAPTOP-5:~/Downloads$ sudo mount -o loop,offset=4194304 \ Armbian_community_26.2.0-trunk.130_Nanopineo2_trixie_current_6.12.63_minimal.img \ ~/rootfs jaufranc@CNX-LAPTOP-5:~/Downloads$ file rootfs/bin/bash rootfs/bin/bash: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=bea6a154d9a9158114ee0a2a439045596615df14, for GNU/Linux 3.7.0, stripped |
As mentioned above, OMV8 works on top of 64-bit Debian 13. On AMD64 targets, it’s very easy to install since the developers provide an ISO file. For 64-bit Arm platforms, you should select a minimal or server Debian 13 64-bit image, as Desktop versions are not supported. The compatibility list linked above provides direct download links to Armbian images for supported single board computers.
A few more details about the release can be found on the project’s website.
Thanks to TLS for the tip.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress. We also use affiliate links in articles to earn commissions if you make a purchase after clicking on those links.
Oh no! Plenty of odroids HC1/2 running OMV since a decade already and going still going strong…
OMV7 isn’t exactly going to go away over night, so you’re most likely good for quite some time even on 32-bit hardware. That said, it’s not as if 64-bit hardware is a new thing and if there’s a lack of OS support, that’s not on OMV.
Yes, and so is Resilio sync moving to 64-bit only.
I wish hard-kernel would produce an ARM64 board mechanically compatible with the old HC2 board.
Another alternative is to hack two HC2 emclosures with one HC4 board using cables, or by cutting an opening in the HC2 aluminium body, letting you mount one HC4 card to drive two HC2 cases.
> They say this could be fixed with a custom ARM64 build
They? It’s one moron delivering most of ‘documentation’ around OMV for years (and for reasons unknown to me: why is one guy allowed to spread so much stupid nonsense all over the place).
It would’ve been a nice idea for providing armhf userlands on 64-bit boards low on RAM, but that never happened: https://github.com/armbian/build/issues/1826#issuecomment-593494839
It seems the constraint comes from a poor choice of a component that doesn’t support 32-bit. It sounds a bit strange to me to choose to adopt components that are not compatible with what people are already using, but it also seems to be a new trend in computing and particularly opensource, to ignore what users are expecting or relying on, just for the sake of simplifying dependencies management. Most software nowadays are just a glue on top of many other parts, to which a name is assigned and they’re presented as a product. But the problem with this approach is that even the one proposing the “product” has zero control over forward compatibility nor features availability. It’s really a bizarre way of delivering software.
> It seems the constraint comes from a poor choice of a component that doesn’t support 32-bit.
That’s VMWare’s/Broadcom’s Saltstack (and I guess Volker had some good reason to rely on it sometimes ago), the real reason for ’64-bit’ only.
The other thing is that BS about ‘Armbian using 32-bit userland on 64-bit hardware’ which is either the moron’s own ‘research’ or today’s usual fashion of blindly trusting into the halluzinations whatever LLM vomits out.
Are there any chances that OMV8 will work on 32 ARM?
A bity off-topic, but that QNAP Annapurna based NAS couldn’t run your benchmark. If I remember right, it was missing some dependencies in the OS that couldn’t be installed. It wasn’t great, but it wasn’t awful either, but still stuck on a 4.x kernel which is just insane.
Well if the NAS is based on either AL-212 or AL-314 basing on Cortex-A15 then overall performance could be guesstimated but ofc none of special NAS ‘accelerators’ are covered by sbc-bench anyway.
I personally never owned any commercial NAS device and the only direct contact with NAS vendors was +30 years ago when AppleTalk still was a thing, me being part of the Helios and Netatalk communities somehow specialized in AppleTalk basics and my employer back then having bought some NAS ‘Snap’ appliance from a company called Quantum that f*cked up AppleTalk routing as usual back then.
At least it was fun creating support tickets to then support the (impressively fast learning) vietnamese guy Quantum hired for the Apple protocol stuff via Netatalk mailing list 🙂
If this project is riddled by a moron, are there other moron free alternatives? 😁
To be clear: I’m talking about a guy involved in ‘community support’ and ‘documentation’ spreading desinformation and stupid/dangerous advise since years (MS Windows user by heart).
OMV itself is great and this annoyance now with ’64-bit only’ could’ve been easily avoided if $someone would’ve picked up the salt* components, built and packaged them for Debian to be deployed by the install script on 32-bit platforms (something most probably I would’ve done already months ago if I would be still part of this project).
Thanks, its clear what you meant, I meant to use this statement as a funny packaging for a question for suitable alternatives. As last time I tried omv i didn’t find it very intuitive and pretty limited in functionality. Maybe my bad, as I didn’t invest much time into checking it out…
Don’t ask me cause me heavily biased since being an energy efficiency fetishist. OMV allowed (at least for some years) to gain same NAS performance on cheap ARM thingies idling sub 2W as ‘server grade’ HW consuming 50 times more. Settings/software tuning at work.
There were/are some OSS NAS projects that enforced their users to rely only on ‘server grade’ HW even at home by spreading lies like the infamous ‘ZFS scrub of death’ but since FreeBSD based FreeNAS turned into Linux based TrueNAS I completely lost track of 🙂
But I have to agree: the UI experience with OMV is lacking and especially everything administrative through the WEB UI is painfully slow on lower-end HW… but it comes with good defaults which compensates a bit for the silly/dangerous nonsense their documentation/forum is unfortunately full of.
I somehow gave up on arm sbc, as when they become fully OS supported are 10 years obsolete… And to be honest I don’t feel like using BSPs based on 3.x kernels and blob drivers.
TrueNas seems to me turned into a paid for product, forks are understaffed and OMV I never kind pf got warm with.
As much as I hate closed eco systems if you don’t feel like tinkering you will end up with an off-the-shelf nas box.
I once tried to instead setup a nextcloud instance based on a server os and podman, it was not bad, but to be honest nextcloud is just not meant for easy deployments in a secure way.
I guess next i might try immich for foto sync, but currently have no urge doing so.
“ARM thingies idling sub 2W as ‘server grade’ HW consuming 50 times more.”
My system consumes around 6 to 7 watts when idle, not counting the hard drives.
I have 32 GB of RAM, a Kontron motherboard, a very efficient 500-watt power supply, 3 SSDs, and 2 x 12 TB HDDs. I leave the HDDs running 24/7. The system then consumes around 17 watts. I have 2.5 GBe LAN and use TrueNAS Scale.
One of the problemes might be OMV. The other issue to turn into a project would be:
https://www.debian.org/releases/trixie/release-notes/issues.html
If you are really serious about it the best option might be to reverse the decission to drop the Armel port for Debian. One of the reasons to drop Armel and MIPS64EL a few months ago was a waning developer interest.
So the real issue here is that either there is no interest at all or a whole potential group of maintainers has been sleeping. The options: reversing the drop, forking or perhaps moving to Devuan…
Since I hardly have any armel or armhf hardware you won’t see me cry.
Armel is imho long obsolete and de facto replaced by armhf, which is 32bit with fpu, whereas armel is emulating an fpu, so the drop of armel won’t harm most 33bit sbcs
It will only harm very old SBC (predating ARMv7, w/o FPU support) and the restrictions of the armel ‘architecture’ ended up with Raspbian being born as such the more popular old boards still may get support for a long(er) time.
I was also sad when my atngw board based on avr32 fell out of support…
Honestly how many boards with arm7tdmi or arm9 cores with adequate peripherals for running omv are still around, on the other hand arm v7 like Allwinners, Samsungs, Rockchips and many others with suitable usb3 or sata ports are probably still some (i.e. plenty) around…
> The compatibility list linked above provides direct download links to Armbian images
Nope, it doesn’t (checked it only now).
Plenty of links go nowhere and according to this ‘documentation’ there exists a ‘Pine64 Rock 5’…, Odroid M1 is Intel based, Orange Pi 3 is RK3566, NanoPi M1 is RK3328, VisionFive 2 is ARM, BPI-CM4 is based on BCM2711 and so on.
The whole page is obviously complete and utter BS generated either by the crashtest moron himself or more likely some ‘AI’. Of course nobody cares. That’s the state of ‘documentation’ for OMV since years.