New approach for Raspberry Pi OMV images

  • RPi 3. I'm going to turn it into a VPN server

    Worst idea possible. Better throw your RPi 3 away. Broadcom or the mythical RPi Foundation forgot to license ARMv8 crypto extensions so RPi 3 simply sucks at AES encryption/decryption:…findComment&comment=37829

    Better choose any other 64-bit ARM board you can get (except ODROID-C2 -- the other device that lacks ARMv8 crypto support) and configure your VPN to use AES. Will be magnitudes faster.

  • OK. Thanks but my internet ADSL is going to be slow anyway so it's still worth a try as an experiment.

    So how can I get a vanilla armbian install on my pi? Is there part of the script/tool/process that you used to created the OMV image that I could use?

    also... would my banana pi m2u (another bad purchase) be any good for VPN server?

  • Post#1 may have gone out of date, since Raspbian is currently linux 4.97, armv71, updates twice a week and all of the boards pictured don't have the cpu as the limiting factor. Might be good to have more customers and fair game to brief them on screen with their educational devices.
    Perhaps more importantly,
    I was also fascinated by an idea very much like luakit to localhost for showing OMV on the console screen.

  • Post#1 may have gone out of date, since Raspbian is currently linux 4.97, armv71

    Just answering to this:

    Raspbian is a Debian based distro where all packages are built vor the ARMv6 architecture which isn't supported by Debian since 7 or even more years. This simple fact is the only reason why Raspbian exists: no Debian support for outdated CPU cores from 15 years ago (the ARM1136 inside the single core RPi SoCs is from 2002 -- as the name tells it's an ARM11 implementing ARMv6 microarchitecture) so all the gazillions of packages had to be recompiled for the RPi and that's all what Raspbian is about: recompiling and providing Debian packages for the outdated ARMv6 architecture.

    We switched with OMV to 'plain Debian' to get one single package base for all devices (minimizing support hassles). Since Debian supports only ARMv7 or ARMv8 (armhf and arm64 architectures) this doesn't work with the single core Raspberry Pi any more since their CPU core is an ARMv6.

    OMV for RPi uses the RPi foundation's kernel packages (the same that Raspbian uses), they provide one ARMV6 kernel and one ARMv7, the proprietary OS that runs on the VC4 detects the CPU type and then loads the correct kernel accordingly. And that's 4.9.79 currently though the kernel available through is usually some versions behind. So the same moment you get a kernel update with Raspbian you get the same kernel update with OMV too. There's no difference wrt kernel whatsoever

    One minor exception: we provide on the OMV image also a true but somewhat outdated ARMv8 kernel 4.11 but since this kernel receives no updates automagically it's not the default -- so it's up to adventurous users to play with this 64-bit kernel but there's no real reason since Raspberries are way too slow to be used as a good NAS and that's due to their lack of interfaces and not related to CPU cores or the kernel.

  • This Realtek usb gigabit adapter is compatible and can be found for Less than 7 dollars, even with free shipping.

    In 2018, if a computer didn't come with USB3, Gigabit and error correct ram onboard, then you're not supposed to use it as a file server. However, if one would appreciate misusing the Raspberry Pi twice as fast, this adapter may help. See photo. Previous network configuration at eth0 is notwithstanding because this will be eth1. The upgrade will change the Pi from eleven times slower than a normal file server to only five times slower than a normal file server. Even so, the upgrade could expand the number of simultaneous users from 1 to 3.

  • This Realtek usb gigabit adapter is compatible and can be found for Less than 7 dollars, even with free shipping.

    The one you showed looks like the one I had some time ago: It was an USB2 to Gigabit Ethernet adapter with pretty low performance in one direction (for whatever reasons the majoritiy of people forgets to test network and storage gear 'in both directions'). It's 2018 now... please anyone do yourself a favour: Stop to buy USB2 products even if you want to connect it now to USB2 ports only. Buy USB3 stuff instead. This will greatly reduce the risk to buy old and low performing crap from last decade (the controllers inside matter).

    There exist three USB3 Gigabit Ethernet adapters: ASIX AX88179, RealTek RTL8153 and Microchip LAN7800. The first one is known for mediocre performance and driver hassles, the last one has not been found in the wild while RTL8153 performs great and has great driver support (usually already integrated into the OS so you have no trouble not just with Linux but also Android, macOS, Windows, *BSD, maybe even more OS). If you want to buy an external Gigabit Ethernet adapter I can only recommend to look for the chipset first to avoid buying crappy products.

    I got my RTL8153 for $7.50 some time ago but it should be noted that using these things on a Raspberry Pi is not a great idea. Not the adapter sucks but the Raspberry Pi. Their SoCs (system on chip -- the main processor) have only one single USB2 port so everything on RPi is bottlenecked by this single connection. All USB ports and the internal network adapter are behind an internal USB hub so every access that involved disk and network at the same time has to share bandwidth. As you said 2 times faster is all you could expect with Gigabit Ethernet. That's insane...

    Instead of spending 7 to 8 bucks for an external GbE adapter to boost 'RPi as NAS performance' I would spend a few bucks more to replace the RPi and get a whole new and more energy efficient ARM board with native Gigabit Ethernet. Look here for inexpensive and energy efficient devices that are at least 2 times faster than a RPi with GbE dongle or at least 4 times than a RPi with onboard networking: Which energy efficient ARM platform to choose?

  • That one is USB3.0 Says usb3.0 on the cover and there's that blue plug. Also actually tested it.

    But there's a hippo in my bathtub!
    bit flip saved to disk and to backup disk = bit rot (glitches accumulating in movies and music files, slowly worsening over time). Unfortunately, small scale, low wattage, servers with ECC aren't on the market, thus unavailable to purchase, because they didn't promote ECC memory by its practical benefits: Protect music and movies. Just those 4 words.
    Without ECC, then making improvements in network speed and greater storage space actually serves to glitch more files faster (not a real upgrade). So, searching for a real upgrade (to ECC) has been much more intense than simply finding a computer with gigabit onboard.

  • Quick compatibility announcement wrt next RPi model.

    We'll see rather soon a new RPi model (most probably not called RPi 4 but a somewhat extended 3 and Zero with Gigabit Ethernet. Of course not real/fast Ethernet but USB2 attached (I would assume they take Microchip LAN7850)

    And there it is:…-model-bplus-sale-now-35/

    Does this mean this Raspberry Pi would now be a great little NAS? Nope.

    This new board suffers still from the same 'only one single USB2 port' limitation so all USB ports and Ethernet still have to share bandwidth. You won't be able to get any decent NAS performance out of this thing since every single bit has to pass the 'single USB2 port' bottleneck twice.

    Further readings:

    The Wi-Fi is a joke since they chose a single antenna implementation and make not use of MIMO which is most basic requirement to get any decent wireless performance especially as soon as your environment gets 'crowded' and other wireless networks around add to the congestion problem.

    The Gigabit Ethernet is a real joke since due to USB2 bottleneck being limited to less than 20 MB/s when data on disk is accessed and transferred through the network at the same time (see explanation in 2nd link above and the confirmation from Raspberry Pi forum).

  • So maybe my latest OMV image for RPi will boot flawlessly on this new RPi model and can then be updated to latest versions of kernel and 'firmware'. But maybe an adjusted 'firmware' is necessary to boot this new SoC (of course it's not a firmware but a closed source RTOS called ThreadX that runs on the VC4 main CPU)

    If this guy here is right and it requires their latest Raspbian release from yesterday then that's bad news. This means the new board once again requires a ThreadX update (contained in the blobs on the /boot partition) and so our OMV image won't boot on the new model.

    But if my assumption is correct (only affecting ThreadX, that's the so called 'firmware') then it should be easy to replace the blobs on the /boot partition and re-release the OMV image soon.

  • my point is, I miss the old Raspbian images and its little bit strange to switch to the Arabian image, which is build from someone who bash permanent the raspberry pi

    Sorry, can't help you with your understanding problems :)

    In my opinion it's pretty easy to get that any Raspberry Pi is the most lousy SBC possible for NAS use cases since bottlenecked by 'single USB2' and suffering from underpowering problems. No idea how this can be missed if you look more closely at the hardware?

    Then what do you not understand wrt focusing on OMV users? Why shouldn't we care about users any more?

    • Since the RPi is such a lousy choice for a NAS it's important that users be aware of that. So they can choose optimal hardware for the use case they're interested in
    • Since an awful lot of users have already an RPi lying around why not trying to provide them with the best OMV experience possible? Why not letting RPi users too benefit from our 'OMV on ARM devices' journey that started almost a year ago? Why should we exclude them?

    If you're not able to understand how limited every RPi out there is when it's about NAS usage then I'm sorry but I fear nobody can help you. Same with asking to exclude the many RPi users from good software. Why should this happen? Why shouldn't RPi users also be able to run 'best OMV possible'?

    Or are you asking for fanboy behaviour? Sorry, impossible.

    BTW: Since there's a potential performance problem with the freshly announced RPi 3 B+ I thought it's a good idea to both check for this issue with RPi folks and to prepare a new OMV image for RPi that already supports the new board (needs a new 'firmware'), is based on OMV4 and contains the few missing tweaks from the other ARM images.

    I ordered an RPi 3 B+ an hour ago but canceled it right now and deleted the preparations for the new OMV4 image. Thanks for the reminder that it's simply not worth the efforts with this target audience :)

  • For users of freshly released RPi 3 B+

    Since RPi Foundation changed hardware requiring both new 'firmware' and kernel support the currently available OMV image won't boot on the new board. Symptom looks like undervoltage when a display is connected (displaying the yellow lightning bolt) but it's simply the old firmware refusing to boot the new hardware.

    So it's necessary to replace the entire contents of the /boot partition (FAT partition so accessible from a PC or Mac too) with this:…mp/ZCLu0r/RPi_3B_Plus.tgz (archive created with most recent Raspbian Lite image -- please do NOT touch/replace cmdline.txt, see below)

    This should then boot the RPi 3 B+ with latest RPi 4.9.80 kernel, as usual a network connection is needed and the installation will finish itself (depending on the random IO performance of the SD card used this might take between 10 and 40 minutes). Whole procedure is not tested so you're on your own :)

    As a reference the MD5 hashes of the files below:

    Edit: Silly me forgot to add that if you already have an RPi 2 or 3 then booting the OMV image there and applying all available updates (happens at 1st boot anyway) should also lead to an image that is ready for the RPi 3 B+ -- the necessary updates for kernel and bootloader are part of RPi's Stretch repos which the OMV image is able to use (via apt pinning).

    Edit 2:


    The above archive contains cmdline.txt from Rapsbian Lite image which should not be used since referencing the rootfs via an UUID not matching the rootfs from our image and also contains 'init=/usr/lib/raspi-config/' which can't work. So please exclude cmdline.txt when replacing the files on the /boot partition

  • On the subject of the new RPi 3 B+......

    I have updated an existing OMV installation on a RPi 3 as per @tkaiser's post above.

    That worked fine and dandy.

    I put the SD card from this RPi into a new RPi 3 B+.

    Would you expect it to just work?

    It boots up to a command line login prompt but the system itself seems not to be working (I cannot access it through a browser). Also, the static IP address it was running on the older machine is not being used.

    Any pointers very much appreciated.

  • Thanks, @flmaxey, I would like to preserve my existing system with all it's share setups and plugins, if possible.

    I just wanted to know if I am crazy in thinking it might just work if I plug the updated SD card into the new 3B+

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!