Building OMV automatically for a bunch of different ARM dev boards

    • I am testing our XU4 image and I must say thank you for the great work you did.

      I have a 128 GB MicroSD Card and on the second partition the home and data directorys with btrfs file system in subvolumes mounted and shared via omv.

      The only challenge was the fan control. I now have a modifyd python script from this debian package GitHub - L33thium/xu4fanctl: fan control daemon for odroid xu4


      Python Source Code

      1. #!/usr/bin/env python
      2. # -*- coding: UTF-8 -*-
      3. ##########
      4. ## Fan control for odroid xu4
      5. ## when hit hiTmp manage fan speed until hit loTmp then stop.
      6. ## steps make fan wants to speed down more than speed up, for silence.
      7. ## recommanded governor : conservative
      8. ############################
      9. import os, sys, signal, re, time, collections
      10. # settings
      11. #hiTmp = 90
      12. #loTmp = 50
      13. hiTmp = 60
      14. loTmp = 35
      15. stepUp = 20
      16. stepDown = 5
      17. minSpd = 22 # in percent
      18. # files location
      19. #if os.path.isdir("/sys/devices/odroid_fan.14"):
      20. # fanctl = "/sys/devices/odroid_fan.14"
      21. #elif os.path.isdir("/sys/devices/odroid_fan.13"):
      22. # fanctl = "/sys/devices/odroid_fan.13"
      23. #fanctl = "/sys/devices/platform/pwm-fan:/hwmon/hwmon0"
      24. fanctl = "/sys/class/hwmon/hwmon0"
      25. #fTmp = "/sys/devices/10060000.tmu/temp"
      26. fTmp = "/sys/class/thermal/thermal_zone1/temp"
      27. #fMode = fanctl+"/fan_mode"
      28. fSpd = fanctl+"/pwm1"
      29. class fan():
      30. def __init__(self):
      31. self.tmpLst = collections.deque(maxlen=100)
      32. #def setManual(self):
      33. #with open(fMode, "w") as f:
      34. #f.write("0")
      35. #def setAuto(self):
      36. #with open(fMode, "w") as f:
      37. #f.write("1")
      38. def getTmp(self):
      39. with open(fTmp, "r") as f:
      40. t = f.read()
      41. tmps = re.findall("[0-9]{5}", t)
      42. tmps = map(int, tmps)
      43. #temp = max(tmps) / 1000
      44. temp = sum(tmps) / len(tmps) / 1000
      45. self.tmpLst.append(temp)
      46. tmpAvg = float(sum(self.tmpLst) / len(self.tmpLst))
      47. return [temp, tmpAvg]
      48. def cool(self):
      49. delta = hiTmp - loTmp + 20
      50. tmps = self.getTmp()
      51. temp = tmps[0]
      52. tmpAvg = tmps[1]
      53. time.sleep(1)
      54. while tmpAvg > loTmp:
      55. tmps = self.getTmp()
      56. temp = tmps[0]
      57. tmpAvg = tmps[1]
      58. diff = tmpAvg - loTmp
      59. percent = int(float(diff) / float(delta) * 100)
      60. if temp >= hiTmp:
      61. self.setSpd(100)
      62. else:
      63. self.setSpd(percent)
      64. time.sleep(1)
      65. def setSpd(self, percent=0):
      66. if percent > 100:
      67. percent = 100
      68. pwm = int(float(percent) * 109 / 100)
      69. if pwm < 28 and pwm > 1:
      70. pwm = 28
      71. #if pwm < 1: pwm = 1 # switch fan off
      72. if pwm < 1: pwm = 28
      73. with open(fSpd, "r") as f:
      74. curPwm = int(f.read())
      75. #print curPwm
      76. if not pwm == curPwm:
      77. with open(fSpd, "w") as f:
      78. f.write(str(pwm))
      79. class GracefulKiller:
      80. kill_now = False
      81. def __init__(self):
      82. signal.signal(signal.SIGINT, self.exit_gracefully)
      83. signal.signal(signal.SIGTERM, self.exit_gracefully)
      84. def exit_gracefully(self,signum, frame):
      85. self.kill_now = True
      86. def main():
      87. killer = GracefulKiller()
      88. done = False
      89. #fan.setManual()
      90. #fan.setSpd(0)
      91. fan.cool()
      92. while not done:
      93. if killer.kill_now:
      94. #fan.setAuto()
      95. break
      96. if fan.getTmp()[0] > hiTmp:
      97. fan.cool()
      98. time.sleep(1)
      99. if __name__ == "__main__":
      100. fan = fan()
      101. try:
      102. main()
      103. except Exception as error:
      104. print('caught this error: ' + repr(error))
      105. #fan.setAuto()
      Display All



      mfG Matthias
    • @ryecoaaron Just had a look at SF and realized that it seems we need to rename one image: sourceforge.net/projects/openm…s/Other%20armhf%20images/

      It seems all Pine64 users download OMV_3_0_71_Pine64so_3.10.105.7z which is meant for SoPine and not the normal Pine64 board (won't even boot there due to different DRAM type). Can you please rename OMV_3_0_71_Pine64so_3.10.105.7z to OMV_3_0_71_SoPine_3.10.105.7z? That should already be sufficient to guide Pine64 users :)

      BTW: On the automated ODROID images root pwd is set to openmediavault too as on all the other images as well.
    • schmimat wrote:


      The only challenge was the fan control. I now have a modifyd python script from this debian package GitHub - L33thium/xu4fanctl: fan control daemon for odroid xu4
      Thanks for the script. Please be aware that thermal settings might change (as part of kernel/DT package) and that currently there are some UAS issues with some external USB-to-SATA bridges that get hopefully resolved soon (will required kernel patches but once this is resolved they're available through 'apt upgrade' later :) )
    • tkaiser wrote:

      Can you please rename OMV_3_0_71_Pine64so_3.10.105.7z to OMV_3_0_71_SoPine_3.10.105.7z?
      Done.

      tkaiser wrote:

      On the automated ODROID images root pwd is set to openmediavault too as on all the other images as well.
      Fixed.
      omv 4.1.14 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • I've been reading/following this thread and really good work/input to everyone who has been contributing. Thanks!

      I decided to purchase a banana Pi M2 (Banana PI BPI-M2 Ultra) and compare the performance/stability with my Raspberry Pi 3 that I use as a headless OMV based NAS. The Banana Pi is on its way from China (AliExpress) and I hope to receive it soon. Fingers crossed!

      I am checking to see if there is (or will it be possible) to create a OMV build for my Banana PI BPI-M2 Ultra?

      Looking at the sourceforge site, there is an image named OMV_3_0_71_Bananapim2_4.10.12.7

      Can someone let me know if this will work with the Banana PI BPI-M2 Ultra?

      If not, how can I help to build one for my Banana Pi?

      Also helpful to understand the versioning at the end of the file name above (the 4.10.12.7 part).

      Many thanks,
      Jago
    • Good luck with Banana hardware. You did NOT buy a Banana Pi M2 but something called Banana Pi M2 Ultra which I would consider instable garbage according to all available user reports: forum.banana-pi.org/t/frequent-freeze-ups-of-m2u/2823/ (please look carefully through this thread to get an idea how the vendor deals with the problem that so many boards don't run reliable: simply ignoring it).

      The Banana Pi M2 is still not even remotely supported by Banana Pi folks (only a really horrible kernel 3.3.0 has released by them) but since this is a rather old design and linux-sunxi community is that awesome at least mainline kernel runs on this old board and that's also the reason Armbian (and now OMV) support it.

      Wrt Banana Pi M2 Ultra I doubt this will happen anytime soon, maybe next year linux-sunxi community supports this board, then Armbian might decide to support it and as soon as this happened you can also generate an OMV image automagically.

      In other words: Sorry, you purchased the wrong device :(

      Personal recommendation: Banana Pi, M1, M1+ and Pro are worth a look, every other Banana released later NOT (incompatible anyway and plagued by stupid design decisions, lacking proper documentation and support)

      BTW: There's another Banana Pi M2, this time called Plus, also incompatible and plagued by stupid overvolting (overheats like hell). This time vendor forgot voltage regulation so the M2+'s CPU cores will be fried all the time with 1.3V voltage (according to schematic it's 1.2V but several people measured 1.4V instead which is the maximum allowed according to processor datasheet)
    • @tkaiser - thanks and shit! haha. glad i got it really cheap from Aliexpress... Too late to cancel now but supposedly I get 'buyer protection' so if it doesn't work properly, I will get a refund.

      Is there anything I can do with this board assuming it actually works?

      this will teach me for not doing any proper research before buying. Wanted most powerful board but didn't think about how little support there would be for it...
    • tkaiser wrote:

      Proposed changes for readme.txt of this specific directory (some stuff applies to newer ODROID builds too but there situation with eMMC is different anyway so no adjustments necessary there)
      Changed although I don't use etcher. It isn't in the Debian repos and requires a desktop environment. I write my cards with dd (with fdatasync flag and 1M block size) on command line only linux. Never had an issue in years.
      omv 4.1.14 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      Changed although I don't use etcher. It isn't in the Debian repos and requires a desktop environment. I write my cards with dd (with fdatasync flag and 1M block size) on command line only linux. Never had an issue in years.
      Thank you for exchanging the readme!

      Regarding dd vs. Etcher: Users who know what they do and stay away from cheap SD cards might be fine with dd but from a distributor's point of view it's amazing how many end users are failing with this. The rate of 'it does not boot' reports dramatically decreased one year ago when we started to recommend Etcher only with Armbian.

      Quoting TL Lim (Pine64 founder) who wrote me yesterday: "More than 60% on the technical issue is on user not able to create a correct and useful microSD card build." And Etcher is made by resin.io folks for exactly that reason: Users not able to burn OS images correctly since no other tool out there does a VERIFY (only known exception to me: this 'special' Win32DiskImager from Hardkernel, that implements verify for the same reason: way too much support hassles and time wasted with this)

      It's not just cards being crappy but sometimes USB ports behave strange or external card readers overheat (I personally encountered burning problems USB front ports while those on the back of my Linux host worked flawlessly -- maybe a shielding problem)

      BTW: on Debian based x64 Linux using an Etcher CLI variant is easy: cnx-software.com/2017/02/11/re…ntu-16-04/#comment-539076
    • jata1 wrote:

      Is there anything I can do with this board assuming it actually works?
      You might need some patience since I believe the current stability issues are just due to crappy defaults (voltage regulation and/or dvfs table). Some kind souls from linux-sunxi community are already working on this board and we even have a (non working) preliminary WiP configuration for it: github.com/armbian/build/blob/…oards/bananapim2ultra.wip

      For further information I can only recommend to watch progress in Armbian forum (just do a search for the board name there). But still: for something useable I would assume we're talking about at least half a year more.
    • OK thanks for the advice - much appreciated.

      Silly impulse purchase after reading this thread (but not doing proper research).

      I'm really happy with my RPi 3 with OMV as a low cost / low usage (and high stability) NAS. The only thing that I noticed that annoyed me is the 100mbps ethernet... but i thought a better CPU would also be good so I went for the newer M2 ultra BPI.

      I'll probably have some fun over the next few months getting the BPI running OK - as a little linux / hardware project.
    • tkaiser wrote:

      Users who know what they do and stay away from cheap SD cards might be fine with dd
      I was just referring to what I do. That is why I didn't change what you had. I use cheap SD cards but have a good writer. The writer has caused more issue than anything in my experience.
      omv 4.1.14 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • Hi.

      Im a new user to anything anything else than using macOS GUI.(total beginner) Bought a Raspberry PI 3 B Some months ago. Despite never being using commands, terminal, linux etc. A managed relatively easily to install OMV, and tvheadend.
      So to begin with, I wanna thank for the fantastic software. Hope I never have to switch to anything else.

      But I ran into some limitations with the RPI, so after some good (i thought so) research. I ordered a Odroid XU4. And that's when my, hair started falling of my head...

      The last week or so, i've tried to install "OMV_3_0_71_Odroidxu4_4.9.23.7z" to the emmc. But with no succes.. Just can't get it to boot from the emmc. SD Card no problem. Tried all kind of guides and stuff.. But since i don't have much linux experience, i need to have a step-by-step guide.. and most of them is not accurate enough for newbie user like me.

      Is there somebody here, who can help me, with a step-by-step guide to get "OMV_3_0_71_Odroidxu4_4.9.23.7z" installed on the emmc, using a mac?

      This is my last hope, before giving up for good... :( So Really hope someone here, is able to help me..
      Thanks in advance.

      Ps. Hope you understand my bad school english. :)
    • Why is so important to have OMV installed on emmc? According to this page, the emmc install is broken. But there is no reason you can't use the SD card until it is working.
      omv 4.1.14 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      Why is so important to have OMV installed on emmc? According to this page, the emmc install is broken. But there is no reason you can't use the SD card until it is working.
      I didn't know it was broken. Just read somewhere that it was much faster and more stable than SD card. So bought the XU-4 with the emmc card. I don't have a usable SD card, only a little 4 GB one. So guess I have to go out and buy a good SD card, and hope the soon get the emmc to work properly. Thanks to the supplier pollin.de for assuring me that, i could install newest OMW image to emmc... :thumbdown:
    • new-omv-user wrote:

      Just read somewhere that it was much faster and more stable than SD card.
      Faster? sure but only a marginal amount for the web interface. Most things that write to SD or emmc are writing to ram because of the flashmemory plugin.
      More stable? I don't think it makes a difference other than the emmc will probably last longer.

      new-omv-user wrote:

      So guess I have to go out and buy a good SD card, and hope the soon get the emmc to work properly
      I don't use the emmc on my boards and have no issues.

      new-omv-user wrote:

      hanks to the supplier pollin.de for assuring me that, i could install newest OMW image to emmc
      Technically, you probably could install (haven't tried lately) the older image (omv_xu3_xu4_3.0.65.img.gz) to emmc and update it to the latest. You will end up with OMV 3.0.74 after installing updates from the Updates tab either way.

      new-omv-user wrote:

      I don't have a usable SD card, only a little 4 GB one
      The old images work just fine with a 4GB SD card.
      omv 4.1.14 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      I don't use the emmc on my boards and have no issues.
      Regarding the system drive. What would be the best solution theoretical (Stability, speed etc.) is it a SSD? My data drive is a Toshiba Canvio Desktop 3TB HDD USB 3.0.

      I spend a lot of time in a hospital :( And I primarily would like to use my OMV/Odroid XU4 to stream live tv (from tvheadend) and movies etc. from home, to an ATV or RPI3 box, that use KODI. Emby or whatever is best.
    • Users Online 1

      1 Guest