OMV 3 for ODROID-XU4/HC1/HC2/MC1

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • OMV 3 for ODROID-XU4/HC1/HC2/MC1


      OMV 3 for ODROID-XU4/HC1/HC2/MC1


      All these Exynos 5422 based ODROID devices share one single OMV 3 image: OMV_3_0_88_Odroidxu4_4.9.46.img.xz

      It's based on OMV 3.0.88, kernel 4.9 LTS and an Armbian/Jessie userland (everything updated from official repos so you get all latest fixes automagically). The rootfs is a btrfs with active transparent filesystem compression combined with zram instead of swap. In case your installation media is 16 GB or more in size a 3rd partition gets automatically created on first boot you have to put a filesystem on manually to make use of it (eg. use it as an OMV share for small amounts of data that always have to be accessible to allow connected HDDs entering sleep/standby mode)

      Important to know:
      • If you want to use this image on XU3/XU4 together with a Hardkernel eMMC module unfortunatly you need an SD card (of any size) as first step. This is due to Hardkernel's eMMC modules still hosting a really outdated u-boot version in the hidden eMMC boot partitions that are not accessible when you burn the image on your PC/Mac. So simply burn the OMV image to an SD card with Etcher, attach eMMC and SD card to your XU3/XU4, adjust the boot switch to 'SD card' and boot the board. Once it rebooted automatically after few minutes log in through Web UI, change passwords and activate 'permit root login' on the SSH service section. Then login as root via SSH, call 'nand-sata-install' and choose 'Boot from eMMC - system on eMMC'. When finished 'nand-sata-install' will poweroff the board. Remove SD card now, adjust the boot switch and let the board boot from eMMC from then on. Of course it's also possible to transfer the installation to permanently attached USB/SATA storage using the same method (but then the SD card has to remain attached since the bootloader can only be loaded from either SD card or eMMC on these boards)
      • When you choose an external USB3 disk enclosure try to get one that contains an 'USB Attached SCSI (UAS)' capable USB-to-SATA bridge. Chips known to work are for example ASMedia ASM1153 and JMicron JMS578, JMS567 or JMS561. Please be aware that some HDD brands use these bridge chips combined with branded/broken firmwares (eg. many external Seagate disk enclosures). In such cases it might be possible that you have to 'blacklist UAS' (visit ODROID forum and search there for these words)
      • When you run into any storage hassles with ODROID-XU3/XU4/MC1 please always keep in mind that cable/contact problems and underpowering are the most common reasons for this. Always check this first and also check the links from my signature. Why aren't HC1 and HC2 listed? Since those are designed to prevent both powering and cable/contact hassles :)
      • In case you're adventurous and have applications running that require huge amounts of memory you might want to adjust the vm.swappiness value in /etc/sysctl.conf. The default value vm.swappiness=0 ensures that the system only relies on zram in emergency situations when really running out of physical memory. With an adjusted vm.swappiness value you might be able to benefit from compressed memory and let more memory hungry applications run at the same time (always check 'free' output first, usually this will not be the case unless you have some very special needs). Please be aware that this is neither tested nor recommended. If things break you're on your own!
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.

      The post was edited 1 time, last by tkaiser ().

    • BTW: I wrote a small HC1 mini review already weeks ago: forum.armbian.com/index.php?/topic/4983-odroid-hc1/

      And just to elaborate on these LanTest screenshots used there and when talking about other ARM devices running OMV. I use LanTest since two decades now since it allows to conveniently test 'overall NAS performance' testing network and server storage at the same time and checking a bit more stuff than just sequential transfer speeds.

      The various operation modes (and why LanTest numbers usually are lower than what Windows Explorer might tell) are explained here: helios.de/viewart-de.html?id=1711

      So when choosing different LanTest profiles not only the amount of data varies (300 MB, 3 GB or 12 GB) but more importantly the block size of read and write requests (128K, 1M and 4M).

      When testing with 300 MB / 128K it looks like this:
      With 3 GB / 1M block size we're already talking about this (my standard settings to be able to compare between different devices):
      And with 4MB block size we're reaching the 100 MB/s barrier in single threaded (!) operation:
      All these tests were done with a direct GbE connection between HC1 and my test client (MacBook Pro with Gigabit Ethernet adapter using the usual Broadcom BCM57762). When a GbE switch is in between especially sequential writes can be somewhat affected (with the Netgear switch I currently test with it's almost 6-10 MB/s less -- always keep this in mind). But all of this won't affect real-world performance at least when we're talking about Windows Explorer or macOS' Finder since they dynamically optimize settings in the background and will exceed 100MB/s anyway in case a fast enough HDD/SSD is connected to your ODROID.
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • @tkaiser
      I dd'ed the image (OMV_3_0_88_Odroidxu4_4.9.46.img.xz) to an odroid-XU4 sd, tried to nand-install it to emmc. but it doesn't boot.
      * screen (hdmi) shows only a blinking cursor,
      * no network connection,
      * HeartBeat LED beating,
      * fan running high-speed

      repeated the nand-install after zeroing out the 1M of the emmc, no change.
      sorry, no uart avail.

      any ideas?
    • chymian wrote:

      any ideas?
      Yep, nand-sata-install on this image is somewhat buggy. Please try again after replacing contents of /usr/sbin/nand-sata-install with raw.githubusercontent.com/armb…sr/sbin/nand-sata-install

      Tested right now on XU4 with SD card installation moved to eMMC (poweroff, ejected SD card, adjusted boot switch to eMMC, booted --> works). Please provide output from 'armbianmonitor -u' after reboot when running off eMMC :)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.

      The post was edited 2 times, last by tkaiser: Updated link to latest nand-sata-install commit. ().

    • DHGE wrote:

      I flashed an older image (~86?) via the sd-card adaptor directly to the emmc.
      That booted fine.
      Well, then you got a brand new eMMC module since on the older an incompatible u-boot (only capable to access FAT partitions and not ext4) is residing.

      Hardkernel's Justin just wrote me this morning:

      "We’ve started to ship eMMC modules with the latest u-boot recently. But some old stock in distributors should have old u-boot for a couple of months probably.
      In our new official Ubuntu images, it updates the u-boot in the first boot process to avoid any unpredictable issues.
      If users have a problem with incompatible u-boot, users can recovery/install the latest u-boot with this annoying method. forum.odroid.com/viewtopic.php?f=53&t=6173"

      With latest nand-sata-install from Github it should work now (I'm still busy updating/fixing this tool since it should work on all +50 boards Armbian supports with all kernel variants... somewhat challenging...)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • chymian wrote:

      the log is here sprunge.us/DNRi
      Merde, /etc/init.d/firstrun gets called again and again :(

      But at least searching through the log for '### quick iozone test' shows how insanely fast Hardkernel eMMC modules are (compare the last entry with the former ones -- in order of appearance and values in KB/s: write, rewrite, read, reread, random read and random write)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • I'm a linux noob but after I've installed "OMV_3_0_88_Odroidxu4_4.9.46.img.xz" on an Sd card and booted my XU4 with openmediavault and I log in via SSH and I run "nand-sata-install" at the terminal I Receives the following message from the program - "This tool must run from SD card!" - Why? Please explain it as simple as possible since I'm not a nerd :)


      Thanks in advance :)


      Rene
      Images
      • sd.jpg

        84.95 kB, 1,366×768, viewed 55 times
    • mrperfektone wrote:

      "This tool must run from SD card!" - Why?
      Explained above. The included tool is was buggy and needs to be replaced manually at the moment (an update will fix this in the future). Fixed in the meantime.

      Source Code

      1. wget https://raw.githubusercontent.com/armbian/build/master/packages/bsp/common/usr/sbin/nand-sata-install
      2. /bin/bash ./nand-sata-install
      Since I'm fighting with another related issue (moving installation to an USB/SATA disk) there's no new/fixed image currently. Might change in a few days...
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.

      The post was edited 1 time, last by tkaiser ().

    • N3ST wrote:

      Quick question is it possible to upgrade the firmware from 4.9.37 to 4.9.46 or will I have to reinstall everything from scratch?
      That's the kernel, not 'firmware' :)

      Yes, can be updated on the image with 'apt upgrade' but currently Armbian has not provided new kernel packages. I run with a more recent version since I tested out Anand Moon's patch to improve USB3 stability: forum.odroid.com/viewtopic.php…&t=27548&start=50#p201153

      Igor (Armbian core dev and maintaining the apt repository) today increased Armbian version so maybe in a few hours you get 4.9.50 from the apt repo anyway :)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • Hello tKaiser,

      I noticed that the MD5 hash for the Odroid XU4 is different from the downloaded file.

      Downloaded file hash:
      MD5 (OMV_3_0_88_Odroidxu4_4.9.46.img.xz) = 9dc9f0e61a8e4221a9bac0afe33dbe3b
      Below are MD5 hashes for the compressed images:
      ...

      OMV_3_0_88_Odroidxu4_4.9.46.img.xz: 845f003019b7d22384b34f6e5e1aafb5
      Source: readme.txt, updated 2017-09-10

      ....
    • Laub wrote:

      I noticed that the MD5 hash for the Odroid XU4 is different from the downloaded file
      Thank you for bringing this to our attention. At least I tested with the image @ryecoaaron uploaded to SF multiple times so the MD5 hash in the readme is wrong. I'll check at the weekend if a few tweaks we made in the meantime (fixed nand-sata-install being the most important one) justify a new image and if not I'll ask him to correct the readme.txt
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • O yes, that sounds good. My nand-sata-install does not work although i follow your description
      (start with eMMC Card fails, Odroid XU-4 fan rotates permanently, error report: sed: can´t read /mnt/nand-sata-install.Zfkv7j/bootfs/boot/boot.cmd: No such file or directory + /mnt/nand-sata-install.Zfkv7j/boot/armbianEnv.txt: No such file or directory)

      Furthermore: The Tutorial from Obihörnchen does not work at all. My tranferrate does not reach more than 26 MB/s (?),
      -> NAS HDD´s with USB 3.0 with UASP (Salcar 3,5'' SATA Mobile HDD box)
      -> WLAN 5Ghz, test with iperf: 800Mbit

      So, there is a programming error?

      tkaiser wrote:


      Laub wrote:

      I noticed that the MD5 hash for the Odroid XU4 is different from the downloaded file
      Thank you for bringing this to our attention. At least I tested with the image @ryecoaaron uploaded to SF multiple times so the MD5 hash in the readme is wrong. I'll check at the weekend if a few tweaks we made in the meantime (fixed nand-sata-install being the most important one) justify a new image and if not I'll ask him to correct the readme.txt
    • kevinlomax wrote:

      So, there is a programming error?
      No idea. All I know is
      • XU4 eMMC modules that left Hardkernel prior to July this year carry an old u-boot version that is not sufficient (these modules might be sold by retailers a few more months until out of stock)
      • So it's recommended to always burn image with Etcher (!) to SD card, then boot from it, wait for first reboot, then login
      • Then as outlined above you have to download latest nand-sata-install version from Github to transfer installation to eMMC
      If anything of the above is done differently it can't work, using eMMC for OMV is a huge waste (since the eMMC is super fast but that's not needed to run OMV on it) and if anything goes wrong the output from 'armbianmonitor -u' is needed anyway :)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • Ready to test: OMV_3_0_88_Odroidxu4_4.9.52.img.xz (MD5: ec90048c2972bbc0e2f7fd795b027492)

      Changes:
      • nand-sata-install now working to transfer installation from SD card to eMMC
      • more recent kernel version (4.9.52)
      • countless other fixes


      To transfer to eMMC it's calling 'sudo nand-sata-install' and then






      'armbianmonitor -u' output now running from eMMC: sprunge.us/iXJP

      @ryecoaaron: in case no feedback within the next 2 days (as expected since which user would want to waste his time on testing?!) could you please replace the image with adjusted MD5 sum?
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.

      The post was edited 1 time, last by tkaiser ().

    • tkaiser wrote:

      in case no feedback within the next 2 days (as expected since which user would want to waste his time on testing?!) could you please replace the image with adjusted MD5 sum?
      I was going to test :) I will even test the emmc I have. And yes, I will replace the image and md5sum.
      omv 4.0.6 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!