Dear Voluminous,
There is a lot of guessing about what Volumio “needs” and about what changed between Volumio 3 (Buster) and Volumio 4 (Bookworm). Most of it treats Volumio as if it sets these limits itself. It does not. Volumio inherits its floors from Debian and Raspberry Pi, then adds its own workload on top.
This post separates fact (sourced) from hearsay, and flags anywhere I am giving an estimate rather than a measured number. We build these images, so “builder-measured” means my own testing on real hardware, not a published spec.
The short version
| Claim in circulation | Reality |
|---|---|
| Volumio sets its own minimum requirements | It inherits them from Debian and Raspberry Pi |
| ARMv6 was dropped to save RAM | It was dropped on CPU architecture grounds, set upstream |
| Volumio 4 needs more RAM because Volumio got heavier | The Debian base got heavier from Buster to Bookworm |
| The OS runs in RAM | The squashfs is loop-mounted from storage and read on demand |
| A small image means low RAM use | Disk size and RAM use are different budgets |
| 512 MB is fine | 512 MB struggles under Volumio’s real workload |
Layer 1 - the CPU floor is Debian’s
| Debian architecture | CPU requirement | Applies to |
|---|---|---|
| armhf (32-bit) | at least ARMv7 + VFPv3 | Buster and Bookworm |
| arm64 (64-bit) | at least ARMv8 | Buster and Bookworm |
| (below the line) | ARMv6 / VFP2 - not served by Debian armhf | Pi 1, Pi Zero, Pi Zero W (BCM2835) |
Source, Debian arch baseline: 2.1. Supported Hardware
Source, BCM2835 is ARMv6: https://www.raspberrypi.com/documentation/computers/processors.html
ARMv6 only runs at all because Raspberry Pi maintains a separately recompiled 32-bit userland for it. Stock Debian armhf was never built for ARMv6. So “why was ARMv6 dropped” is answered two layers below Volumio.
Layer 2 - Raspberry Pi already drew the same line for 64-bit
| Raspberry Pi OS variant | Supported boards |
|---|---|
| 64-bit | Pi 3 or later, or Pi Zero 2 |
| 32-bit | original Pi, Pi 2, Pi Zero (and up) |
Source: https://www.raspberrypi.com/documentation/computers/os.html
Volumio 4 uses a 64-bit (arm64) kernel on Bookworm. It inherits exactly the boundary Raspberry Pi already set for 64-bit: ARMv8 and up. Volumo runs 64bit kernel with 32 bit userland and this will not change any day soon.
Why ARMv6 was dropped for Volumio 4
| Reason | Type | Source |
|---|---|---|
| Debian armhf requires ARMv7 + VFPv3 | upstream fact | Debian arch baseline (above) |
| 64-bit generation excludes ARMv6 | upstream fact | Raspberry Pi OS docs (above) |
| No stable bootable ARMv6 Bookworm image could be produced | builder-measured | my own build testing |
| “Necessary binaries simply aren’t available for these older boards” | Volumio statement | Volumio 4 is Here: A Year in the Making, Built for What's Next - Volumio |
This is not a RAM decision. A Pi Zero has 512 MB, the same as a Zero 2 W. What ended support is the CPU architecture, not the memory.
Layer 3 - the base RAM floor went up because Debian got heavier
| Generation | Debian base | Installer RAM minimum | Installer disk minimum |
|---|---|---|---|
| Volumio 3 | Debian 10 (Buster) | 256 MB | ~2 GB |
| Volumio 4 | Debian 12 (Bookworm) | 780 MB | 1160 MB |
Source, Buster: Debian Installation Guide (Buster), restated at How to Install a Debian 10 (Buster) Minimal Server
Source, Bookworm: 2.5. Memory and Disk Space Requirements
That is roughly a threefold rise in the base installer RAM floor, decided entirely upstream by Debian. Indicative Debian installed footprint (amd64): 647 MB minimal base, 843 MB standard.
Source: D.2. Disk Space Needed for Tasks
[NOTE: footprint figures are amd64 and indicative; armhf/arm64 differ slightly.]
Layer 4 - on real hardware, 512 MB is already the tight edge
Even before Volumio is involved, experienced Pi users treat 512 MB (the Zero 2 W) as the constraint: headless Bookworm Lite runs, a desktop is slow, a browser is effectively out, specifically because of the 512 MB.
Source: https://forums.raspberrypi.com/viewtopic.php?t=365766
That is the bare-OS idle bar. Volumio’s bar is higher, because it adds a workload.
Layer 5 - Volumio is the consequence: lean base plus its workload
How Volumio ships lean:
| Mechanism | Effect | Source |
|---|---|---|
| Package stripping (Lite-class, headless) | only what the appliance needs | Volumio filesystem architecture |
| Compressed read-only root (squashfs) | system occupies far less storage than uncompressed | Squashfs 4.0 Filesystem — The Linux Kernel documentation |
Volumio filesystem architecture: Volumio File System Architecture | Volumio Developers Documentation
[SPECULATION / DIRECTION ONLY: the Volumio image is meaningfully smaller than a comparable plain Debian install. Direction is certain - compression plus package stripping - but I am not putting an exact size delta here, it should be measured.]
What Volumio runs on top of the base: the Node.js based management and UI service, MPD, and library indexing.
Builder-measured: 512 MB is a struggle for Volumio even at idle. With the Node.js layer, MPD and library handling active, a 512 MB device struggles in normal use. That is the running-stack floor, above the bare-OS floor from Layer 4.
The squashfs / overlayfs design
| Aspect | Detail | Source |
|---|---|---|
| Advantage: size | compressed read-only root | squashfs kernel docs |
| Advantage: flash wear / integrity | immutable base, writes isolated to data partition | OverlayFS - Wikipedia |
| Advantage: clean updates | base image replaced as a unit, user changes layered separately | Volumio filesystem architecture |
| Consequence: RAM | data decompressed into page cache, decompressor state per mount - raises the RAM floor | squashfs kernel docs; Bug #1636847 “unexpectedly large memory usage of mounted snaps” : Bugs : Snappy |
| Consequence: write amplification | editing a base file copies it up, then overrides squashfs on update | Volumio filesystem architecture |
| Myth: “OS runs in RAM” | false - squashfs is loop-mounted from storage, read on demand; only /tmp and /var/log are tmpfs | contrast: https://wiki.ubuntu.com/BootToRAM |
Leanness on disk is real and deliberate, but it does not translate into RAM savings. The two are different budgets.
Putting it together
| Layer / source | Buster gen (Volumio 3) | Bookworm gen (Volumio 4) |
|---|---|---|
| CPU floor, Debian armhf | ARMv7 + VFPv3 | ARMv7 + VFPv3 |
| CPU floor, Debian arm64 | ARMv8 | ARMv8 |
| ARMv6 status | runs via Raspbian arm6hf | not supported, no stable build |
| Pi 64-bit boundary (RPi) | Pi 3+ / Zero 2 | Pi 3+ / Zero 2 |
| Debian installer RAM minimum | 256 MB | 780 MB |
| Bare Pi OS Lite at 512 MB | workable headless | tight but workable headless |
| Volumio plus its workload | 512 MB marginal | 512 MB struggles |
| Practical Volumio minimum | 1 GB | 1 GB |
| Comfortable | 2 GB | 2 GB |
| Storage | 8 GB and up | 8 GB and up |
The chain in one paragraph
Volumio’s minimum is the sum of inherited upstream floors plus its own workload. The CPU must be ARMv7 or ARMv8 because Debian requires it. ARMv6 is excluded upstream by Debian and again by Raspberry Pi’s 64-bit line, and I could not build a stable ARMv6 Bookworm image. The base RAM floor rose from 256 MB to 780 MB because Debian grew from Buster to Bookworm. On a real Pi, even bare Bookworm Lite treats 512 MB as the tight edge. Volumio then adds Node.js, MPD and indexing, so 512 MB struggles and the sensible minimum is 1 GB, 2 GB comfortable. Volumio is the consequence of these layers, not the origin.
Fact vs estimate
| Statement | Status |
|---|---|
| CPU architecture floors | fact, Debian sourced |
| ARMv6 exclusion | fact, Debian and Raspberry Pi sourced |
| 256 MB and 780 MB installer minimums | fact, Debian sourced |
| squashfs / overlay behaviour | fact, kernel and Volumio docs |
| Pi 64-bit boundary | fact, Raspberry Pi docs |
| 512 MB struggles for Volumio under load | builder-measured (my testing) |
| Image size advantage over stock Debian | estimate, direction only |
| Exact V3 vs V4 idle RAM delta | estimate, not claimed |
Now, the workload and what you need to consider for your music library:
Kind Regards,
