Building OMV automatically for a bunch of different ARM dev boards

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

    • tkaiser wrote:

      @ryecoaaron

      May I ask to replace all 'other arm images'? At Armbian we investigated about BTRFS (resizing, compression, performance, swap vs. zram) and here we go: kaiser-edv.de/tmp/NumpU8/

      Display Spoiler
      Can you please exchange contents of sourceforge.net/projects/openm…s/Other%20armhf%20images/ with the above?

      Changes: All images updated to kernel 4.12.9 and OMV 3.0.87, btrfs rootfs, zram instead of swap, countless tweaks/fixes. To document image integrity: The following is readme.txt contents:

      Source Code

      1. OpenMediaVault for various ARM devices
      2. Write image in a single step using Etcher https://etcher.io to SD card.
      3. The image can be transferred in a second step to permanently attached
      4. eMMC, USB or SATA storage using included nand-sata-install tool.
      5. Notes:
      6. - No need to decompress images. Simply burn them using Etcher
      7. https://etcher.io -- Etcher decompresses on the fly, verifies
      8. burning results and thereby saves you from common SD card hassles!
      9. - OMV installation finalizes itself at first boot (network connection
      10. needed!) Please be patient since this can take up to 15 minutes.
      11. When done the board automatically reboots once and afterwards OMV
      12. is ready to be used
      13. - SSH keys are regenerated on first boot but SSH login has to be
      14. enabled in web UI prior to usage: Services --> SSH --> Permit root
      15. login
      16. - Please immediately change default passwords!
      17. - The last partition for data use will be automatically resized on
      18. first boot to use all available SD card space. Though you need to
      19. put your filesystem of choice on it (eg mkfs.btrfs /dev/mmcblk0p3)
      20. - openmediavault-flashmemory plugin preinstalled to reduce wear on SD
      21. card/eMMC.
      22. - Wrt Bananas: M2 image is only for old A31 SoC board (not compatible
      23. with later M2 variants! Recent Bananas currently lack both vendor
      24. and community support)
      25. - Banana Pi M1+ shares image with Banana Pi, you need to execute the
      26. following as root to get full functionaly:
      27. sed -i '1isetenv fdtfile sun7i-a20-sinovoip-bpi-m1-plus.dtb' \
      28. /boot/boot.cmd
      29. mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
      30. reboot
      31. Web interface:
      32. - username = admin
      33. - password = openmediavault
      34. Console/SSH:
      35. - username = root
      36. - password = openmediavault
      37. Download integrity:
      38. Below are MD5 hashes for compressed images followed by CRC32 checksum
      39. for uncompressed images (Etcher in the past displayed/checked these
      40. integrity details, hopefully they add this again the future):
      41. OMV_3_0_87_Bananapi_4.12.9.img.xz
      42. MD5 .xz: 260630af29749d5a53ce2261b4d4d206 | CRC32 .img: cd797bfe
      43. OMV_3_0_87_Bananapipro_4.12.9.img.xz
      44. MD5 .xz: a07ae39550a0071a31c230373027f2fc | CRC32 .img: 7221eed4
      45. OMV_3_0_87_Bananapi_M2_4.12.9.img.xz
      46. MD5 .xz: 7adedbdd6d7e8f711b834f44d65cf8b8 | CRC32 .img: 5cb35a73
      47. OMV_3_0_87_Cubietruck_4.12.9.img.xz
      48. MD5 .xz: 663dfbe0e06dfcbc0b04b4608732322b | CRC32 .img: 82b52943
      49. OMV_3_0_87_PcDuino3_4.12.9.img.xz
      50. MD5 .xz: 332e9c04e46f85f3ab1ca410e545281e | CRC32 .img: 75a81a94
      51. OMV_3_0_87_PcDuino3_Nano_4.12.9.img.xz
      52. MD5 .xz: 8640f0a08a830bfb842b9686ac1d4a49 | CRC32 .img: 7ccc3bdb
      53. OMV_3_0_87_Lime2_4.12.9.img.xz
      54. MD5 .xz: 83bac9fc1c64bfe37e92442b6f9df955 | CRC32 .img: cce6c0bd
      55. OMV_3_0_87_Lime2-eMMC_4.12.9.img.xz
      56. MD5 .xz: d7174008d18b35bc45137e9adc1ee31e | CRC32 .img: 020f23cb
      57. OMV_3_0_87_Clearfog_Pro_4.12.9.img.xz
      58. MD5 .xz: 83ddf320e5fb13364cb991679d94cacb | CRC32 .img: 3cfc7b43
      59. OMV_3_0_87_Clearfog_Base_4.12.9.img.xz
      60. MD5 .xz: 11eb34aace5c81f7fd9c4bcbfa512d3e | CRC32 .img: 58fd46bb
      Display All

      Currently Pine64/SoPine images will disappear but that's good since we're close to getting mainline kernel support for these devices.


      Other interesting devices (ROCK64, EspressoBin and others) will follow soon, same with some ODROID images (kernel updates applied, some u-boot finetuning needed).

      I made only tests with a couple of boards... but since all images are created fully automated from scratch it's only necessary to test one image per board family :)

      Banana Pi: sprunge.us/RYBQ
      Banana Pi Pro: sprunge.us/ONeZ
      PcDuino3 Nano: sprunge.us/WdaR
      Clearfog Pro: sprunge.us/SFcc
      I'm curious about the performance of the EspressoBin running OMV :)
    • Thank you! Now to the ODROIDs. I planned to release new images for all 3 different device types we support but still struggle with ODROID-C2 and have given up for now. Plan was one single download subdir on SF but for now we should continue with 3 different download directories.

      C1/XU4 images at the usual location: kaiser-edv.de/tmp/NumpU8/

      readme.txt as follows (has to be splitted now of course for C1 and XU4/HC1/...):

      Source Code

      1. OpenMediaVault for ODROID C0/C1/C1+/C2/XU3/XU4/HC1/HC2
      2. Write image in a single step using Etcher https://etcher.io to SD card
      3. or eMMC using Hardkernel's adapter. When booting from SD card you can
      4. transfer the rootfs in a second step to permanently attached storage
      5. using the included nand-sata-install tool.
      6. Notes:
      7. - for ODROID-XU4/HC1/HC2 use OMV_3_0_88_Odroidxu4_4.9.46.img.xz
      8. - detailed information / discussion:
      9. https://forum.openmediavault.org/index.php/Thread/19618
      10. - for ODROID-C0/C1/C1+ use OMV_3_0_88_Odroidc1_3.10.107.img.xz
      11. - No need to decompress images. Simply burn them using Etcher
      12. https://etcher.io -- Etcher decompresses on the fly, verifies
      13. burning results and thereby saves you from common SD card hassles!
      14. - OMV installation finalizes itself at first boot (network connection
      15. needed!) Please be patient since this can take up to 15 minutes.
      16. When done the board automatically reboots once and afterwards OMV
      17. is ready to be used
      18. - SSH keys are regenerated on first boot but SSH login has to be
      19. enabled in web UI prior to usage: Services --> SSH --> Permit root
      20. login
      21. - Please immediately change default passwords!
      22. - The last partition for data use will be automatically resized on
      23. first boot to use all available SD card space. Though you need to
      24. put your filesystem of choice on it (eg mkfs.btrfs /dev/mmcblk0p3)
      25. - openmediavault-flashmemory plugin preinstalled to reduce wear on SD
      26. card/eMMC.
      27. Web interface:
      28. - username = admin
      29. - password = openmediavault
      30. Console/SSH:
      31. - username = root
      32. - password = openmediavault
      33. Download integrity:
      34. Below are MD5 hashes for the compressed images:
      35. OMV_3_0_88_Odroidc1_3.10.107.img.xz: 6b92fd7721e559efbde0e08182567c31
      36. OMV_3_0_88_Odroidxu4_4.9.46.img.xz: 845f003019b7d22384b34f6e5e1aafb5
      Display All
      Also I would suggest renaming the Odroid-XU3_XU4 directory to 'ODROID-XU3_XU4_HC1_HC2_MC1' since the new image is suitable for all the new devices (wrt HC2 my assumption is that Hardkernel relies here on the 2 port JMS561 we already know from Cloudshell 2 and wrt MC1 while not being equipped with an USB-to-SATA bridge I would assume people might want to use a bunch of MC1 as storage frontends for HC1/HC2 based backends)



      BTW: With ODROID-C2 I run into the problem that with mainline kernel I don't have USB access and with both kernel variants the C2 disappears from (my) network after the first reboot. Since I wasted already a lot of time but have no serial console for C2 I'll give up for now.

      And just for the record: all these OMV images are created from scratch relying on this script (since yesterday ready for OMV 4 too). When you check out Armbian's build system the first time this template gets copied to userpatches/customize-image.sh (but never updated again since this is the place where your modifications happen). By uncommenting the InstallOpenMediaVault line the function will be called and then creates a fresh OMV image for the device in question. So in case you want to give it a try simply update userpatches/customize-image.sh with latest script contents and then let an image build.

      Edit: Debug output (forgot before):
      '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 ().

    • I uploaded the images to a new "odroid images" folder. I will put the C2 image in there as well when it is working. I will give the script a test too.
      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!
    • First Allwinner H3 boards now supported since Armbian currently starts to move mainline kernel support from dev to next branch:

      Orange Pi Plus 2E has 2 GB DRAM, 16 GB pretty fast eMMC, Gigabit Ethernet and 4 USB2 ports in total that do not have to share bandwidth. Tested with my usual EVO840 SSD behind a JMS567 UAS capable SATA bridge:


      This is a Banana Pi M2+ more or less the same as above but just with 1 GB DRAM, one available USB port less (only on solder holes) and only 8 GB (pretty slow) eMMC. And the manufacturer forgot voltage regulation so this board can only run with up 1.2GHz and overheats slightly. Same EVO840 but this time behind an ASM1153 bridge:



      So we're bottlenecked by USB2 here but since currently dvfs/cpufreq scaling isn't working (comes with an update/'apt upgrade' in a few weeks) we'll get a few MB/s more soon (currently CPU cores are clocked with just 1008 MHz, once cpufreq scaling patches are applied it goes up to 1200/1296 MHz and then ~40MB/s NAS throughput are possible, when using btrfs with active compression and compressable data on the shares bandwidth will further increase).

      Images ready for SF upload at the usual location: kaiser-edv.de/tmp/NumpU8/ -- 'armbianmonitor -u' output from Orange Pi Plus 2E after moving installation to eMMC with nand-sata-install: sprunge.us/VZQW -- log for Banana Pi M2 Plus after doing the same: sprunge.us/MHjP and a quick check of OrangePi Plus image (worse choice than OPi Plus 2E since relying on a really crappy onboard USB-to-SATA bridge): sprunge.us/SZeh

      Updated readme.txt:

      Source Code

      1. OMV_3_0_88_Orangepiplus2e_4.13.0.img.xz
      2. MD5 .xz: 05ba3319e28e6dbd4be26542af8ee901 | CRC32 .img: 7da38943
      3. OMV_3_0_88_Orangepiplus_4.13.0.img.xz
      4. MD5 .xz: 0ec679b62cf11ea7e378a0166fee9d79 | CRC32 .img: a69d16a2
      5. OMV_3_0_88_Bananapim2plus_4.13.0.img.xz
      6. MD5 .xz: 44b4e69f0dee99971b652142b3138261 | CRC32 .img: c6333150
      '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 ().

    • And now ODROID-C2: OMV_3_0_88_Odroidc2_3.14.79.img.xz

      Still with legacy kernel (3.14) since mainline is yet not ready. Issues:

      • USB instabilities with mainline
      • bootscript not ready for btrfs
      • no performance increase compared to legacy (3.14 vs. 4.12). Though ODROID-C2 NAS performance is not that great anyway since only USB2 and all ports behind an internal USB hub
      But at least I could identify a potential problem with mainline (missing IRQ affinity adjustment at boot) and fixed that already in preparation for a later 4.13 or 4.14 image. Boot log with 3.14 kernel: sprunge.us/XCVe and this is the necessary line for the ODROID readme.txt:

      Source Code

      1. OMV_3_0_88_Odroidc2_3.14.79.img.xz: 57610461487310371603e0324ea68a12
      @ryecoaaron: could you please test/upload the C2 image and add the 3 'Other armhf images' above to the subdir and add/exchange readme.txt there?

      And could you please delete the 3.0.79/4.9.35 RPi image since causing mixed packages trouble for users and replace the readme.txt there with pastebin.com/D5SYnU0j -- thank you!
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • Frepke wrote:

      I'm curious about the performance of the EspressoBin running OMV
      Read performance is excellent, write performance not that great but yet reasons unknown. I did not play with EspressoBin for a while since it seems we lack vendor support (GlobalScale / Marvell). You might want to check the last pages of this thread: forum.armbian.com/index.php?/t…port-development-efforts/
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • Building OMV automatically for a bunch of different ARM dev boards

      tkaiser wrote:

      Frepke wrote:

      I'm curious about the performance of the EspressoBin running OMV
      Read performance is excellent, write performance not that great but yet reasons unknown. I did not play with EspressoBin for a while since it seems we lack vendor support (GlobalScale / Marvell). You might want to check the last pages of this thread: forum.armbian.com/index.php?/t…port-development-efforts/


      Okay thanks tkaiser,

      Then there's only one option for me...
      ...waiting ^^


      Verzonden vanaf mijn iPhone met Tapatalk
    • Uploaded everything. Still working on the C2 image but I think my SD card is going bad. Need to find another - too many arm boards running right now.
      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!
    • ryecoaaron wrote:

      Uploaded everything. Still working on the C2 image but I think my SD card is going bad.

      Yeah, Etcher allowed me yesterday to throw 3 of them away since one failed already at writing and two at verify stage :)

      Only missing piece is readme.txt in Raspberry directory since the current readme might be confusing: pastebin.com/D5SYnU0j

      I tested the ODROID-C2 image with SD card and eMMC but since this board caused me a lot of troubles (still no serial console available) it would be great if you can double-check :)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • Finally Pine64 / SoPine to replace the older 3.0.71 images on SF:
      @ryecoaaron: the usual stuff for readme.txt -- or take the whole version: kaiser-edv.de/tmp/NumpU8/readme.txt

      Source Code

      1. OMV_3_0_88_Pine64_3.10.107.img.xz
      2. MD5 .xz: 977773727dee7f81074a46ef67559e5c | CRC32 .img: 57cf4f94
      3. OMV_3_0_88_SoPine_3.10.107.img.xz
      4. MD5 .xz: bf0fba49cb3284d7330cc46ec0643ea1 | CRC32 .img: 0dc6b09e
      Also still legacy kernel since mainline is not ready yet. But I would assume that changes within the next 2 months and then maybe 3-4 MB/s more are possible due to mainline kernel supporting 'USB Attached SCSI'. But of course no magic involved since this is again a platform where we're bottlenecked by USB2:
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • ryecoaaron wrote:

      Sourceforge updated
      Thank you (though still waiting for Raspberry Pi readme exchanged with pastebin.com/D5SYnU0j since current readme outdated/confusing).

      BTW: in the meantime I found Hardkernel's 8GB eMMC module for ODROID-C2 again (tested with a 'foreign' eMMC before) and had to discover that the new rootfs resize rule to ensure users go with at least 8GB installation media is not sufficient for this eMMC module since due to two hidden eMMC boot partitions the usable capacity is slightly lower than 7.3 GB here :(

      On C2 with Hardkernel's 8GB eMMC the rootfs will not resize but Armbian's resize2fs service will fail instead and install a motd warning. But affected users will not be aware of even if they login through SSH since all they can do is to 'rm /root/.rootfs_resize && reboot' to have the rootfs resizes to full eMMC capacity.

      What to do?

      I still think that enforcing at least 8GB SD cards is great since it saves users from wasting their time with crappy SD cards (there are zero affordable available with 4GB capacity that do not suck). But the 8GB ODROID eMMC is a different beast since amazingly fast. I doubt many users will run into this problem so maybe just add something like the below to the ODROID readme.txt?

      Source Code

      1. - In case your OMV installation behaves strange and you use an 8GB
      2. eMMC module please try via SSH: rm /root/.rootfs_resize && reboot
      '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 wrote:

      though still waiting for Raspberry Pi readme exchanged
      Oops. Missed that one.

      tkaiser wrote:

      I doubt many users will run into this problem so maybe just add something like the below to the ODROID readme.txt?
      I'm fine with that. Updated the readme.
      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!
    • macoslog wrote:

      tkaiser Can you add OMV image for Orange Pi PC
      Of course not since why? Orange Pi PC has only Fast Ethernet so pretty bad choice for a NAS. But of course you can install OMV yourself, just use Armbian's Debian Jessie flavour and then simply call the advanced OMV installation routine we developed the last months: forum.armbian.com/index.php?/t…findComment&comment=40951

      Even better idea: Wait a few more weeks, choose Armbian's Stretch flavour with mainline kernel when released and start with OMV4 (using armbian-config).

      ryecoaaron wrote:

      Asking on more than one thread won't help either...
      Exactly, I considered not answering at all first and the above is all I've to say to this topic.
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.