Raspberry Pi5 - NVMe M2 Boot (Pineberry Pi HatDrive!)

I will check it for experiment. My Volumio is still powered on and I don’t need to wait for power on.

First I want use Volumio with M.2 hat like a home media server but I built NAS with Samba on Pi4.Now I bought another one Pi5 8M and will use with HatDrive on this server.

1 Like

The Primoroni does not have a power connector, but that consumption seems excessive to me, a Samsung evo has a maximum consumption of 1A, and taking into account that the Raspberry’s PCI is 1x and on a PC they work at 4x, I highly doubt that it will ever reach the maximum, to which we must add the low volumio consumption. but if you add hats and screen it can be, you can try

It depends on the capacity, I need a minimum of 2T. Samsung 970EVO 2T need over 2A. My 256GB less than 1A

This is what it says on the Samsung website for the 2TB, and we must take into account that the maximum will be a 4x PCI, with the 1x of the Raspberry it will be much less

Average: 6.1 WMaximum: 7.2 W (Burst mode)* Actual power consumption may vary depending on system hardware & configuration

I’m not measure it. I saw how react Pi5 with 2T disk

Few things to consider:
Your Rpi 5 will need to be prepared to boot from NVME using default Rpi distro:

sudo rpi-eeprom-config --edit

Since Rpi 5 does not have audio jack the default alsa config will complain for as long as you do not route your audio over HDMI or a DAC.
Booting Volumio 3 from NVME can be achieved with custom kernel build using Volumio 3 source with skills beyond an average user:

diff -r ../build/recipes/devices/pi.sh ./recipes/devices/pi.sh
< 		"imgpart=/dev/nvme0n1p2" "imgfile=/volumio_current.sqsh"
> 		"imgpart=/dev/mmcblk0p2" "imgfile=/volumio_current.sqsh"
diff -r ../build/scripts/initramfs/init ./scripts/initramfs/init
< BOOTDEV="nvme0n1"
> BOOTDEV="mmcblk0"
diff -r ../build/scripts/initramfs/init.nextarm ./scripts/initramfs/init.nextarm
< BOOTDEV="nvme0n1"
> BOOTDEV="mmcblk0"
< DATADEV=$(echo $DATAPART | grep -o nvme)
> DATADEV=$(echo $DATAPART | grep -o mmcblk)
diff -r ../build/scripts/makeimage.sh ./scripts/makeimage.sh
< BOOT_FS_SPEC="/dev/nvme0n1p1"
> BOOT_FS_SPEC="/dev/mmcblk0p1"

The build process will create a complete Volumio 3 image without “My Volumio” propriety extension. However, if you require “My Volumio” subscription, you take the originally distributed with the Volumio OS volumio_current.sqsh and modify using instructions from this StackExchange thread:
Copy /lib/modules from your build to the volumio_current.sqsh /lib/modules
Update /etc/fstab in volumio_current.sqsh

/dev/nvme0n1p1 /boot                vfat    defaults,utf8,user,rw,umask=111,dmask=000 0 1

Replace volumio_current.sqsh in your custom build with the modified one from the instructions above.
Extend /boot/config.txt with:


Any automated Volumio OS upgrade will overwrite your settings, forcing you to start from scratch.

Happy hacking!

It is in my first post i this thread. I done it.

I will try.


1 Like

Raspberry Pi 5 PCIe NVME M.2 images based on 3.601 TEST. As such, this image should be treated as unofficial Proof Of Concept.

Download from DropBox: Volumio-3.601-2024-01-19-pi-nvme.zip
Please check MD5 sum: 22a7d79531200ed4a5c01dd69e46ce8f

You can image your NVME M.2 with your preferred method.

Since I’m using MicroSD with TEST Volumio:

  1. Mount //volumio/INTERNAL storage on your laptop, PC, etc
  2. Copy Volumio-3.601-2024-01-19-pi-nvme.img to the //volumio/INTERNAL storage
  3. Enable SSH on your Volumio Player: http://<IP.ADDRESS>/dev
  4. Access shell on your Raspberry Pi 5: ssh volumio@<IP.ADDRESS>
  5. Navigate to your internal storage: cd /data/INTERNAL
  6. Flash image to NVME sudo dd if=Volumio-3.601-2024-01-19-pi-nvme.img of=/dev/nvme0n1 status=progress
  7. Shutdown your Raspberry PI 5 and remove MicroSD card.

<IP.ADDRESS> is your Raspberry Pi 5 address IP

Happy hacking!

@volumio - Attached rudimentary overwrite for the volumio3-os:
RPI5-nvme.zip (22.1 KB)

sudo ./build.sh -b arm -d pi-nvme -v 3.601

Perhaps this will initiate future builds.

Happy hacking!

It would be cleaverer not to use fixed device and partition names at all, we have better examples with non-Pi devices booting from not just SD cards, using UUID

See github example

Very elegant and clean approach. Definitely target for the next iteration. UUID is predictable or can be even made static. Thank you for pointing this out.

@nerd ,

Nice attempt, really like this commitment.
Is this image specific for the rPi5 or can we use the same logic for the rPi4?

@Wheaten ,

The POC image is for RPi5 furnished with a PCIe NVME M.2 HAT only. However, the logic will be the same for RPi4. Based on @gkkpch suggestion, the storage device may be anything, for as long as it is a storage device. As such RPi4 would benefit from the approach with likes of USB storages, etc. In turn, use of MicroSD will become a matter of choice, not necessity. Some development effort will be required.

1 Like

I done it…

but after reboot without SD card I lost connection with RPI

Can you put back MicroSD and boot from it please?
Once booted check:

sudo fdisk -l

I wonder, what is using your NVME space.

Happy hacking!

When I start with SD card I can see NVMe:

Second problem, with connected NVMe HAT and boot from SD card I can connect via SSH but my LCD is blank and MyVolumio not start. I have only my second Volumio on PC in app and browser. Some conflict with HAT ??

I done it to check, screen above

bad idea, if you wish to try a new version from SD, you want it to have unique identifiers so it boots with the correct partitions. Always have new UUIDs for new versions, Volumio already takes care of replacing them with OTA updates.

1 Like

From your initial screenshot dd is writing 1.9GB however only 1.8GB succeeded.

Let’s try to nudge the NVME:

sudo fdisk /dev/nvme0n1



sudo reboot

After reboot write image again.

There’s more to be done, x86 (and tinkerboard) have an option to install to internal disk (e.g. when booted from an SD card). x86 has an ultra- fast copy, which should be extended to RPi as well to support people who are technically less talented. This is not a trivial job for an RPi, it needs quite a few modifications.