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.

    • nasnas wrote:

      Thank you for sharing the great news
      Still interested in feedback made with original USB3 Seagate disk enclosures using this new image (since a potential kernel fix is also included -- but since I don't own Seagate disk enclosures and don't want to waste my money for such things I can't test)
      '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 everyone,

      I'm Frepke and new on the forum and waiting for my ordered Espressobin.
      I would like to run OMV on the Espressobin, is this possible already?
      And if yes, is this done trough the installer in Armbian or an already build image?

      Thanks for any help... ^^


      kr.,
      Frepke
    • Frepke wrote:

      I would like to run OMV on the Espressobin, is this possible already?
      I let a new OMV build run at the moment, will upload it later.

      Please keep in mind that this image is based on a WiP (work in progress) Armbian configuration using Marvell's legacy kernel with a few unresolved issues yet. So please consider this being a preview and not a fully stable/supported OMV image yet. At least I won't release any official OMV images for Espressobin unless mainline kernel support is there (since Marvell's 4.4 BSP kernel might not be supported that long)

      You can watch progress over there: forum.armbian.com/index.php?/t…velopment-efforts/&page=5 (please remember: it's WiP for a reason and currently only developer feedback is needed and no end-user support available)
      '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:

      Frepke wrote:

      I would like to run OMV on the Espressobin, is this possible already?
      I let a new OMV build run at the moment, will upload it later.
      Please keep in mind that this image is based on a WiP (work in progress) Armbian configuration using Marvell's legacy kernel with a few unresolved issues yet. So please consider this being a preview and not a fully stable/supported OMV image yet. At least I won't release any official OMV images for Espressobin unless mainline kernel support is there (since Marvell's 4.4 BSP kernel might not be supported that long)

      You can watch progress over there: forum.armbian.com/index.php?/t…velopment-efforts/&page=5 (please remember: it's WiP for a reason and currently only developer feedback is needed and no end-user support available)
      Thanks tkaiser,

      I hope there's a stable build available soon, but in the mean time I follow the Armbian forum.


      kr.,
      Frepke
    • Frepke wrote:

      I hope there's a stable build available soon, but in the mean time I follow the Armbian forum.
      Here you go: OMV_3_0_86_Espressobin_4.4.79.7z

      But I wouldn't call this stable atm -- quite the opposite to be honest. Starting with this release no SSH login as root is possible by default so you have to login through the web UI first, access the SSH service and allow root login. I already talked to @ryecoaaron about a mandatory password change on first login (that then also changes the root passwd) and still hope this gets implemented soon (re-enabling SSH login for root might then be an option after password change).

      I couldn't test any further with this image since It seems I'm somewhat unlucky with Espressobin so far (this is my 2nd board, I'm never able to access a writeable serial console, this 2nd board also overheats a lot). Won't look into this for the next three weeks since too busy with other stuff.
      '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:

      Frepke wrote:

      I hope there's a stable build available soon, but in the mean time I follow the Armbian forum.
      Here you go: OMV_3_0_86_Espressobin_4.4.79.7z
      But I wouldn't call this stable atm -- quite the opposite to be honest. Starting with this release no SSH login as root is possible by default so you have to login through the web UI first, access the SSH service and allow root login. I already talked to @ryecoaaron about a mandatory password change on first login (that then also changes the root passwd) and still hope this gets implemented soon (re-enabling SSH login for root might then be an option after password change).

      I couldn't test any further with this image since It seems I'm somewhat unlucky with Espressobin so far (this is my 2nd board, I'm never able to access a writeable serial console, this 2nd board also overheats a lot). Won't look into this for the next three weeks since too busy with other stuff.
      Thanks tkaiser,

      I thought I give it a try when my espressobin arrives, but I saw your message at the Armbian forum forum.armbian.com/index.php?/t…findComment&comment=36984. That made me doubt, maybe I'll wait for a more stable version of Armbian.

      kr.,
      Frepke

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

    • Frepke wrote:

      That made me doubt, maybe I'll wait for a more stable version of Armbian.
      Well, currently this looks like a simple hardware issue called overheating needing either hardware fixes (active cooling) or software (checking at which voltage the CPU is fed, if possible optimize this. We don't need to think about another countermeasure called throttling since currently I get these symptoms even with an idle board).

      Let's wait and see. I'll run the Linpack benchmark the next 12 hours with active fan and heatsink and if the board survives that IMO it's obvious that we've a hardware issue. See also espressobin.net/forums/topic/overheating/
      '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 just wanna thank @tkaiser, Armbian and OMV for providing the best OMV installation since OMV 2.x. I just switched to it on Friday and I am more than pleased with my XU4 performance and overall behaviour. My USB 3.0 HDD (4TB Seagate Hub) does not have the UAS issues, luckily.
      Riddle me this, riddle me that
      Who is afraid of the big, black bat?
      I write on a blog (Romanian mostly)
      Testing (latest) OMV 3.0.xx on an oDroid XU4
    • Building OMV automatically for a bunch of different ARM dev boards

      tkaiser wrote:

      Frepke wrote:

      I hope there's a stable build available soon, but in the mean time I follow the Armbian forum.
      Here you go: OMV_3_0_86_Espressobin_4.4.79.7z

      But I wouldn't call this stable atm -- quite the opposite to be honest. Starting with this release no SSH login as root is possible by default so you have to login through the web UI first, access the SSH service and allow root login. I already talked to @ryecoaaron about a mandatory password change on first login (that then also changes the root passwd) and still hope this gets implemented soon (re-enabling SSH login for root might then be an option after password change).

      I couldn't test any further with this image since It seems I'm somewhat unlucky with Espressobin so far (this is my 2nd board, I'm never able to access a writeable serial console, this 2nd board also overheats a lot). Won't look into this for the next three weeks since too busy with other stuff.


      Hello tkaiser,

      A few days ago I received my espressobin from @Lupus. After I installed Putty on my MacBook, I set the environment variables and try to boot an image from the sd-card.

      With Armbian_5.32_Espressobin_Ubuntu_xenial_default_4.4.78.7z it's possible to boot. But I like to run OMV on the Espressobin, so I tried OMV_3_0_86_Espressobin_4.4.79.7z

      Unfortunately it's not possible for me to boot this image from an sd-card.

      Should it be possible to run this Image?


      Kr.,
      Frepke


      Verzonden vanaf mijn iPhone met Tapatalk

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

    • ryecoaaron wrote:

      I know you aren't a big xu4 fan but what do you think of the odroid-hc1?

      Looks very promising! Some more info here.



      I already suggested few pages back to avoid USB3 cable/contact hassles by putting the USB-to-SATA bridge on the PCB with RK3328/ROCK64 in mind but Hardkernel already delivered. The idea to use the metal enclosure as giant heatsink is also great and they even thought about the 3.5" HDD use case, there's a 12V connector on the HC1 board that feeds the 12V pins on the SATA power connector. There are also some rumours wrt a HC2 (with the ability to connect two disks most probably using JMS567 as on the Cloudshell 2 which I won't consider a great solution. Adding either an USB hub or a port multiplier adds more complexity).

      Hardkernel sent out 2 HC1 review samples that should arrive soon and I'll report back here my findings (already curious how SSD performance will look like since on HC1 there's no USB3 hub in between host and disk). But to be honest: Now that XU4's Achilless heel is avoided (USB3 contact problems), that voltage-drops are less likely to happen (Cloudshell 1 problem) and that a good USB-to-SATA bridge is used avoding potential UAS hassles the only remaining question is about how efficient heat dissipation will be. HC1 single disk NAS performance will be as good as any x86 box maxing out Gigabit Ethernet 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.

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

    • ryecoaaron wrote:

      what do you think of the odroid-hc1?

      Small update: I'm still struggling with obscure network performance problems in my lab (only affecting XU4 and HC1 but other devices not for whatever reasons. Tried now the 3rd switch after my normal test switch died but to no avail). So still no full review and just some information.

      I collected some performance data and observations with regard to heat dissipation and thermal/throttling behaviour with OMV's kernel variant today: See comments here: cnx-software.com/2017/08/21/ha…-is-now-available-for-49/

      Also today over at Armbian we did some testing wrt AES performance. ODROID's Exynos SoC doesn't support ARMv8 crypto extensions (since being a 32-bit ARMv7 SoC with A15/A7 cores) so if we're talking about encryption/decryption performance (eg LUKS) other platforms might have a clear advantage here. Currently RK3328 on ROCK64 is best performer when judging by synthetic benchmarks (openssl --speed). ROCK64 AES single and multi threaded performance are 9 to 11 times better compared to HC1: forum.armbian.com/index.php?/t…findComment&comment=37829

      We're preparing a few more realistic tests covering LUKS encryption and then local IO performance (iozone tests) as well as NAS performance (LanTest). But this might take some time...
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • ODROID-HC1 mini review is online: forum.armbian.com/index.php?/topic/4983-odroid-hc1/

      Really impressive NAS performance especially with Ethernet IRQs moved from little to big core (which is something some users might want to revert to slightly lower overall consumption under load). But playing energy efficient NAS with HC1 is somewhat hard anyway (especially when compared with upcoming RK3328 boards with same performance but half the consumption -- but until there are RK3328 boards available that have also an onboard JMS578 or something similar HC1 is in a league of its 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.
    • @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/

      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
      '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:

      May I ask to replace all 'other arm images'?
      Sorry, been busy at VMworld in Vegas. I will start uploading them soon.
      omv 4.0.14 arrakis | 64 bit | 4.13 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!