• This image is not compatible with single core Raspberries (A, B, A+, B+, Zero, Zero W) since they’re too slow anyway and their CPU architecture is not supported any more (it’s not based on Raspbian any longer but on upstream Debian ‘armhf’ branch which supports ARMv6 architecture not any longer)
• For satisfying results burn it only with Etcher (no need to decompress, Etcher will verify burning process and save you from some common SD card troubles). It’s strongly recommended to always test your SD card with either F3 or H2testw first to check for counterfeit/broken cards.
• On first boot OMV installation will be finished. This requires your RPi being connected to network/Internet and might take between 10 and 40 minutes (depends solely on the random write speed of your SD card). After installation is finalized the Raspberry will reboot automatically and can then be used. Be patient please and in doubt watch the green led for activity.
• Flashmemory plugin is enabled and monitoring is disabled to reduce wear on SD card (for reasons see here)
• A quick guide to do initial Wi-Fi setup has been added to the end of the thread.
• RPi 3+ users please read here at the end of the thread.

While this image uses upstream Debian repositories it is configured to fetch kernel/bootloader directly from official archive.raspberrypi.org repositories and also some proprietary binaries to deal with VideoCore IV (eg. vcgencmd, raspividand others).

Not so important (but still worth a read!):

• This image does some ‘health logging’ in /var/log/raspihealth.log. On every shutdown there will be a single line logged that is either a timestamp plus a single zero (0) or a timestamp plus a bunch of digits. If the most left of these digits are a 1 instead of 0 your Raspberry either overheats or is powered insufficiently or both. If you run in instabilities please always check this first
• There’s /usr/local/sbin/raspimon included. This tool executed via SSH as ‘sudo raspimon’ reports real CPU clockspeeds by asking the firmware and also reports throttling, under-voltage and as a result the firmware doing ‘frequency capping’ (reducing all clockspeeds to save you from underpowering hassles negatively impacting performance). For a more detailed explanation please see here.
• If you experience troubles you can always execute in a terminal ‘sudo armbianmonitor -u’ which will try to upload debug info to an online pasteboard service (RPi 3 B+ example here). It’s a great idea to check the output yourself and at least to provide the URL if you ask for help in the forum.
• The image resizes the rootfs automagically to ~7.3GB on first boot and creates a 3rd partition using the remaining space of the SD card you need to initialize manually if you want to use it for OMV shares (‘mkfs.ext4|mkfs.btrfs /dev/mmcblk0p3’)
• While this OMV image looks like Armbian it’s not (no support from Armbian team or in Armbian forum). We only chose the proven way to use Armbian’s build system to generate OMV images for ARM boards now for Raspberries too (technically inclined people should look at the bottom of this post what is different)

Please always keep in mind that on cheap single board computers like Raspberries the most common problem sources aren’t software related but powering and/or SD card troubles. Please always check this first before reporting problems (see above for under-voltage detection, how to ensure to write OMV to SD card properly and if you report problems how to provide a debug log!)

Technical details (nerd stuff!):

• The rootfs of this image has been created fully automated by Armbian’s build system on 12-Jun-2017 for a different ARMv7 device (fully automated means debootstrapped from scratch so no one ever logged in so far)
• It has then been combined with an RPi image skeleton based on pi64 project and contains both a 64-bit 4.11 mainline kernel (inactive by intention) and latest official RPi 4.9.80 as the active 32-bit kernel (since this kernel variant will be updated through an apt repo so security fixes that require kernel updates aren’t an issue). If you’re adventurous you can transform this image into something that runs true 64-bit ARMv8 software on an RPi 3 (don’t ask for support, better check out pi64 instead)
• Since this OMV image has been created by Armbian’s build system it contains a lot of Armbian utilities. Most of these aren’t supported and must not be used. Only exception: ‘sudo armbianmonitor -u’ to provide a debug log.
• /etc/update-motd.d/10-header has been changed to output the RPi model at login: BOARD_NAME=”＄(/usr/bin/awk -F” ” ‘{print ＄1 ＄2″ “＄3}’ </proc/device-tree/model)”
• Two more Armbian specific login hints below /etc/update-motd.d/ have been removed
• /etc/apt/sources.list.d/armbian.list has been removed so you won’t receive any Armbian updates
• /etc/armbian-release has been manually adjusted to mark this image being unsupported and made for Raspberries
• /etc/systemd/system/getty.target.wants/serial-getty@ttyS0.service renamed to reflect the fact that it’s tty1S0 on Raspberries
• /etc/hostname has been set manually to ‘raspberrypi’
• /etc/rsyslog.d/raspberrypi.conf included to filter out some annoying log messages
• /etc/fstab is the standard Raspbian one (you might want to change / mount options to ‘defaults,noatime,nodiratime,commit=600,errors=remount-ro’ to reduce SD card wear out if you can ensure that your RPi is powered appropriately)
• timezone is set automatically on first boot via tzupdate (not yet reflected in OMV UI)
• Minor RPi specific logging/monitoring improvements
• Everything else is from an Armbian armhf userland made for a Clearfog Base with some Raspberry specific additions below /lib/modules/ and /lib/firmware/
• The changes are contained/documented in a repository

tkaiser wrote:

Well, it’s time to not only stop supporting the lousy RPi but SBC in general. Way too frustrating since users all the time blame software for simple hardware issues.

I started using OMV recently on a RPi 3B+. For my case, it works well and I like it. Wireless NAS (!!!), rarely used by two users, and absolutely nothing about speed. 15MB/s transfer speed over WiFi is more than three times of that what needs most speed in my use case (MiniDLNA for some tv shows). I could replace that very well with a simple “apt install samba minidlna” and a small config file for each of the two, but I like how i can configure the shares and the DLNA server in the clicky clicky WebGUI. A welcome alternation to all my other more used servers/services which I have to maintain on the command line. A simple short THANKS for your work!

I can understand your desire to drop RPi support. The Raspberry Pis draw a lot of attention and pull a lot of n00Bs into the business. Most n00Bs stay with the RPi, the freaks and more interested go with other platforms. If the other platforms would do more marketing, they would pull in also more people of the kind, that attach a rocked down 15-20 year old 100MBit cable (the blue Netgear cable, we all have at least one of them somewhere) and complain about speed. But I like the Pis because of the price point and the availability. I’m especially interested in the ROCK64 (and also looking at the Asus tinker board probably just for some marketing reasons), but it’s double the price in europe, or you need to order it from china and wait weeks for it. I can get a new Pi in 15 minutes from home.

To cut the long story short now: How is your actual view about the Pi things? Do you think you gonna support it in the future, or would you better drop the “apt install samba minidlna” line on a fresh raspbian lite in my case?