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.

    • Wasn wrote:

      But I think the system does not reboot successful or doesn't finish it's automatic setup.
      Yes, this here

      Source Code

      1. [ 2.259177] SY8106A: Bringing 680000uV into 1000000-1000000uV
      looks suspicious. Seems the voltage regulator is at the lowest level (680mV) for whatever reasons and then CPU clockspeeds that exceed the minimum can cause problems on some boards. See forum.armbian.com/topic/5556-n…findComment&comment=42585

      I doubt there's much you can do currently except trying to mount the 1st partition of a freshly created image and adjust /etc/defaults/cpufrequtils so that max and min values are the same to then boot and try to update everything.
    • tkaiser wrote:

      Wasn wrote:

      But I think the system does not reboot successful or doesn't finish it's automatic setup.
      Yes, this here

      Source Code

      1. [ 2.259177] SY8106A: Bringing 680000uV into 1000000-1000000uV



      looks suspicious. Seems the voltage regulator is at the lowest level (680mV) for whatever reasons and then CPU clockspeeds that exceed the minimum can cause problems on some boards. See forum.armbian.com/topic/5556-n…findComment&comment=42585

      I doubt there's much you can do currently except trying to mount the 1st partition of a freshly created image and adjust /etc/defaults/cpufrequtils so that max and min values are the same to then boot and try to update everything.
      Thank's a lot for your feedback. Even though I'm not quite sure what this means. From my point of view this is no hardware fault itself but more like a tolerance within the manufacturing process, correct? I never had problem's with the device so far (running kernels up to 4.10).

      I changed the values in /etc/default/cpufrequtils


      from, original:

      Source Code

      1. ENABLE="true"
      2. GOVERNOR="ondemand"
      3. MAX_SPEED="1296000"
      4. MIN_SPEED="480000"
      to

      Source Code

      1. ENABLE="true"
      2. GOVERNOR="ondemand"
      3. MAX_SPEED="1296000"
      4. MIN_SPEED="1296000"


      ...right now I give it a shot! Hopefully it will not burn :D
      "This post will remain inaccessible for others until approved by a censor." - George Orwell X/
    • Wasn wrote:

      I changed the values in /etc/default/cpufrequtils
      The other way around would make some sense. Anyway: I started the build system and currently a new build for OPi PC2 is created. I will provide the URL in an hour, will not test anything but if you report everything being fine then I'll rebuild the one for Orange Pi Prime too and try to replace both images at the download location (hmm... NanoPi M1 Plus 2 should also be affected...)
    • tkaiser wrote:

      Wasn wrote:

      I changed the values in /etc/default/cpufrequtils
      The other way around would make some sense. Anyway: I started the build system and currently a new build for OPi PC2 is created. I will provide the URL in an hour, will not test anything but if you report everything being fine then I'll rebuild the one for Orange Pi Prime too and try to replace both images at the download location (hmm... NanoPi M1 Plus 2 should also be affected...)

      Yea, I figured out... it was running as bad as before

      I try this one now:

      Source Code

      1. ENABLE="true"
      2. GOVERNOR="ondemand"
      3. MAX_SPEED="480000"
      4. MIN_SPEED="480000"

      and I will test your image when released :thumbup:
      "This post will remain inaccessible for others until approved by a censor." - George Orwell X/
    • tkaiser wrote:

      Wasn wrote:

      I will test your image when released
      There you go (please wait 15 minutes, it's uploading now): OMV_3_0_94_Orangepipc2_4.14.4.img.xz (MD5: ef8e16c68734d06bdd10cb11fcc8ec3e)
      What can I say?

      It works! Like it should! Non of the previous problems is left! The web gui works like it should and also the console is normally accessible. The device also did the reboot by itself!

      Thank you very much!

      Is there anything I can help with (no drugs & weapons please :P )?

      Here is a 'sudo armbianmonitor -u' just after reboot,adding a user and first login via ssh: sprunge.us/fYfJ
      "This post will remain inaccessible for others until approved by a censor." - George Orwell X/
    • I'm already penetrating my new system and had the following error while installing the (for me) mandatory plugin luksencryption

      Shell-Script

      1. Reading package lists...
      2. Building dependency tree...
      3. Reading state information...
      4. The following extra packages will be installed:
      5. cryptsetup cryptsetup-bin
      6. Suggested packages:
      7. keyutils
      8. Recommended packages:
      9. busybox busybox-static
      10. The following NEW packages will be installed:
      11. cryptsetup cryptsetup-bin openmediavault-luksencryption
      12. 0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
      13. Need to get 372 kB of archives.
      14. After this operation, 1309 kB of additional disk space will be used.
      15. WARNING: The following packages cannot be authenticated!
      16. openmediavault-luksencryption
      17. Authentication warning overridden.
      18. Get:1 http://httpredir.debian.org/debian/ jessie/main cryptsetup-bin arm64 2:1.6.6-5 [173 kB]
      19. Get:2 http://httpredir.debian.org/debian/ jessie/main cryptsetup arm64 2:1.6.6-5 [158 kB]
      20. Get:3 https://dl.bintray.com/openmediavault-plugin-developers/erasmus/ jessie/main openmediavault-luksencryption all 3.0.2 [41.0 kB]
      21. Preconfiguring packages ...
      22. Fetched 372 kB in 0s (809 kB/s)
      23. Selecting previously unselected package cryptsetup-bin.
      24. (Reading database ... (Reading database ... 5%(Reading database ... 10%(Reading database ... 15%(Reading database ... 20%(Reading database ... 25%(Reading database ... 30%(Reading database ... 35%(Reading database ... 40%(Reading database ... 45%(Reading database ... 50%(Reading database ... 55%(Reading database ... 60%(Reading database ... 65%(Reading database ... 70%(Reading database ... 75%(Reading database ... 80%(Reading database ... 85%(Reading database ... 90%(Reading database ... 95%(Reading database ... 100%(Reading database ... 47032 files and directories currently installed.)
      25. Preparing to unpack .../cryptsetup-bin_2%3a1.6.6-5_arm64.deb ...
      26. Unpacking cryptsetup-bin (2:1.6.6-5) ...
      27. Selecting previously unselected package cryptsetup.
      28. Preparing to unpack .../cryptsetup_2%3a1.6.6-5_arm64.deb ...
      29. Unpacking cryptsetup (2:1.6.6-5) ...
      30. Selecting previously unselected package openmediavault-luksencryption.
      31. Preparing to unpack .../openmediavault-luksencryption_3.0.2_all.deb ...
      32. Unpacking openmediavault-luksencryption (3.0.2) ...
      33. Processing triggers for man-db (2.7.0.2-5) ...
      34. Processing triggers for systemd (215-17+deb8u7) ...
      35. Processing triggers for openmediavault (3.0.94) ...
      36. Restarting engine daemon ...
      37. Setting up cryptsetup-bin (2:1.6.6-5) ...
      38. Setting up cryptsetup (2:1.6.6-5) ...
      39. update-initramfs: deferring update (trigger activated)
      40. update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
      41. update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
      42. Setting up openmediavault-luksencryption (3.0.2) ...
      43. Processing triggers for systemd (215-17+deb8u7) ...
      44. Processing triggers for initramfs-tools (0.120+deb8u3) ...
      45. update-initramfs: Generating /boot/initrd.img-4.14.4-sunxi64
      46. cryptsetup: WARNING: failed to detect canonical device of /dev/mmcblk0p2
      47. W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
      48. W: mdadm: no arrays defined in configuration file.
      49. update-initramfs: Converting to u-boot format
      50. Processing triggers for openmediavault (3.0.94) ...
      51. Updating locale files ...
      52. Updating file permissions ...
      53. Purging internal cache ...
      54. Restarting engine daemon ...
      55. Traceback (most recent call last):
      56. File "/usr/sbin/omv-mkaptidx", line 68, in <module>
      57. cache = apt.cache.Cache()
      58. File "/usr/lib/python3/dist-packages/apt/cache.py", line 107, in __init__
      59. self.open(progress)
      60. File "/usr/lib/python3/dist-packages/apt/cache.py", line 154, in open
      61. self._cache = apt_pkg.Cache(progress)
      62. SystemError: E:Problem renaming the file /var/cache/apt/pkgcache.bin.9zEuoX to /var/cache/apt/pkgcache.bin - rename (2: No such file or directory), W:You may want to run apt-get update to correct these problems
      63. Done ...
      Display All
      "This post will remain inaccessible for others until approved by a censor." - George Orwell X/
    • Wasn wrote:

      Is there anything I can help with
      Yes, but feedback here is useless since this already not related to OMV at all (but bleeding-edge kernel and settings stuff for ARM boards that are currently only really supported in Armbian soon).

      You could do some reboot tests and might then again running into problems (since the cpufreq scaling settings allow to downclock to very low clockspeeds and then SY8106A uses a very low VCore voltage, then the board reboots at 816 MHz and might run into troubles again).

      Currently /etc/defaults/cpufrequtils sets 408/816 MHz, maybe it's better to switch to 816/1296 instead. If feedback then please not here but in Armbian forum (see link above).
    • tkaiser wrote:

      Wasn wrote:

      Is there anything I can help with
      Yes, but feedback here is useless since this already not related to OMV at all (but bleeding-edge kernel and settings stuff for ARM boards that are currently only really supported in Armbian soon).
      You could do some reboot tests and might then again running into problems (since the cpufreq scaling settings allow to downclock to very low clockspeeds and then SY8106A uses a very low VCore voltage, then the board reboots at 816 MHz and might run into troubles again).

      Currently /etc/defaults/cpufrequtils sets 408/816 MHz, maybe it's better to switch to 816/1296 instead. If feedback then please not here but in Armbian forum (see link above).
      So just to give feedback already. I had a lot's of reboots today (more than 5) and all worked. The system is super fast an snappy. Didn't had any trouble getting things running.

      Just one question: the flashmemory plugin should be installed by default? Because in my case it isn't. Is the underlying function (caching to ram instead to folder) implemented or is this missing in this release?
      "This post will remain inaccessible for others until approved by a censor." - George Orwell X/
    • @ryecoaaron: Can you please another time replace 3 OMV images (and add one):

      The new one: OMV_3_0_91_Orangepizeroplus_4.13.13.img.xz (MD5: b8c85ea75c40f1251a970f9fa51fc468)

      And the 3 to replace (they all share the same problem: undervoltage due to the voltage regulator not providing sufficient VCore in many situations):


      Thank you!
    • tkaiser wrote:

      Can you please another time replace 3 OMV images (and add one):
      Done.
      omv 4.1.6 arrakis | 64 bit | 4.16 backports kernel | omvextrasorg 4.1.7
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

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

      Is this also applicable to the Espressobin?

      Today I found my EspressoBin, loaded Armbian's Debian_stretch_next.7z image, installed it and let OMV being installed:

      Source Code

      1. armbian-config --> Software --> Softy --> Install OMV
      Took 15 minutes (pretty fast SD card) and now I'm at OMV 4.0.15-1. But not that impressed since with the settings currently active idle consumption with a sleeping disk is at 5.4W (that's 0.5W above ODROID HC2 with same disk connected and also sleeping). But hopefully DVFS will work soon and we figure out how to deactivate stuff that's not needed (doing something like this)
    • tkaiser wrote:

      Frepke wrote:

      Is this also applicable to the Espressobin?
      Today I found my EspressoBin, loaded Armbian's Debian_stretch_next.7z image, installed it and let OMV being installed:

      Source Code

      1. armbian-config --> Software --> Softy --> Install OMV
      Took 15 minutes (pretty fast SD card) and now I'm at OMV 4.0.15-1. But not that impressed since with the settings currently active idle consumption with a sleeping disk is at 5.4W (that's 0.5W above ODROID HC2 with same disk connected and also sleeping). But hopefully DVFS will work soon and we figure out how to deactivate stuff that's not needed (doing something like this)
      Hello tkaiser,

      Finally the Espressobin is back.

      I did the same thing as you described about a wheek ago, unfortunately with some little issues.
      Today I'm starting over again and report my issues.

      - first I'm burning an image on my SD-card with Etcher (ARMBIAN 5.35 user-built Debian GNU/Linux 9 (stretch) 4.14.2-mvebu64)
      - start up the Espressobin without any problem, change the root-password and provide a username.
      - reboot without problems and login again (as root)
      - apt-get update && apt-get upgrade without problems
      - reboot without problems (ARMBIAN 5.36 user-built Debian GNU/Linux 9 (stretch) 4.14.2-mvebu64
      - armbian-config --> Software --> Softy --> Install OMV > also no problems
      - omv-initsystem gives me an error (/usr/sbin/omv-initsystem: 38: /usr/sbin/omv-initsystem: cannot create /var/log/openmediavault/initsystem.log: Directory nonexistent)
      - mkdir /var/log/openmediavault
      - omv-initsystem without problems

      result is an working OMV with GUI on port 80

      - reboot > ERROR ([ OK ] Reached target Shutdown.
      [ 1060.524098] reboot: Restarting system)
      - restart with reset-button an have a couple of ERRORS

      1) [FAILED] Failed to start A high performance …server and a reverse proxy server.
      See 'systemctl status nginx.service' for details.

      2) [FAILED] Failed to start LSB: Starts ProFTPD daemon.
      See 'systemctl status proftpd.service' for details.

      3) [FAILED] Failed to start watchdog daemon.
      See 'systemctl status watchdog.service' for details.

      4) [FAILED] Failed to start watchdog keepalive daemon.
      See 'systemctl status wd_keepalive.service' for details.

      5) And no OMV-GUI

      - mkdir /var/log/nginx solved problem 1 and 5 (and now my reboot problem also)
      - mkdir /var/log/proftpd solved problem 2

      - 3 & 4 still appears and I don't know how to solve these

      Unfortunately after a few hours, the espressobin disappears from my network.
      I can't ping the espressobin anymore. I don't know if this is only a network problem or the espressobin is crashed?

      kr.,
      Frepke

      The post was edited 1 time, last by Frepke: espressobin disappears from my network after a few hours ().

    • Frepke wrote:

      have a couple of ERRORS
      Thank you for the report. Installation routine was buggy and I tried to fix it: github.com/armbian/config/comm…4a2ca78944a2e4683085f0238

      So the best idea is to start over again but this time with Debian_stretch_default.7z (kernel 4.4), then replace the whole contents of /usr/sbin/softy with raw.githubusercontent.com/armbian/config/dev/softy and then try the installation again. Why switching from next branch to default? Since with next branch after OMV installation also all other packages will be updated and then network is gone (so EspressoBin support in Armbian still WiP :( )

      BTW: In case the board does not even boot the kernel it might be necessary to adjust some u-boot stuff. At the u-boot prompt:

      Source Code

      1. setenv fdt_name boot/dtb/marvell/armada-3720-community.dtb
      2. saveenv
      3. reset
      (you might need serial console anyway. When I connect the EspressoBin with a Micro USB cable to my MacBook I do just a 'screen /dev/cu.usbserial 115200,cs8' and am in)
    • tkaiser wrote:

      Frepke wrote:

      have a couple of ERRORS
      Thank you for the report. Installation routine was buggy and I tried to fix it: github.com/armbian/config/comm…4a2ca78944a2e4683085f0238
      So the best idea is to start over again but this time with Debian_stretch_default.7z (kernel 4.4), then replace the whole contents of /usr/sbin/softy with raw.githubusercontent.com/armbian/config/dev/softy and then try the installation again. Why switching from next branch to default? Since with next branch after OMV installation also all other packages will be updated and then network is gone (so EspressoBin support in Armbian still WiP :( )

      BTW: In case the board does not even boot the kernel it might be necessary to adjust some u-boot stuff. At the u-boot prompt:

      Source Code

      1. setenv fdt_name boot/dtb/marvell/armada-3720-community.dtb
      2. saveenv
      3. reset
      (you might need serial console anyway. When I connect the EspressoBin with a Micro USB cable to my MacBook I do just a 'screen /dev/cu.usbserial 115200,cs8' and am in)
      Thank you for your help.

      First of all, 'screen /dev/cu.usbserial 115200,cs8' is very useful for Mac users so no vmware only for a serial connection anymore (Installation of 'PL-2303 Mac OS X Driver v1.6.1' for usbserial was needed).

      Then I did the installation as you described (fresh image, modify softy and nothing more)...
      ...result is an working OMV4 system without errors or manual modifications AND still up and running after 8 hours ^^

      Thanks,
      Frepke

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

    • @tkaiser, do the tweaks you made for the images for ARM devices "survive" an upgrade from OMV3 to OMV4?
      Anything that should be done in addition to "omv-release-upgrade"?

      Sorry if this has already been anwered in one (ore more <X ) posts.
      Odroid HC2 - armbian - OMV4.x | Asrock Q1900DC-ITX - 16GB - 2x Seagate ST3000VN000 (rsnapshot) - 1x Intenso SSD 120GB - OMV4.x 64bit
      :!: Backup - Solutions to common problems in OMV - Must see OMV setup videos - OMV4 Documentation :!:
    • macom wrote:

      do the tweaks you made for the images for ARM devices "survive" an upgrade from OMV3 to OMV4?
      They should survive since they're exactly the same for OMV 3 and 4. But to be honest: I went through the upgrade process maybe 50 times already but never paid attention to these settings so far :(

      So in case you give it a try it would be great if you report back (most important OMV tweaks are additional Samba settings and cpufreq stuff)
    • macom wrote:

      How, what, where to look
      Well, 'performance' before and after the upgrade (I highly recommend Helios' LanTest for this purpose) and then whether settings stick. Most important ones are /etc/defaults/cpufrequtils (that needs some entries in /etc/default/openmediavault -- see here for details), Samba settings and of course whether flashmemory plugin is still active or not.

      BTW: IIRC it was you who recommended the above script procedure to install OMV recently to a PC user? Anyway, I'm not entirely sure whether all of the tweaks done there for slow single board computers are reasonable defaults for people running OMV on x64...
    • tkaiser wrote:

      Regarding performance: In case 'ondemand' should be used I would recommend setting the following also (adding to /etc/rc.local in this case):

      Source Code

      1. echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
      2. sleep 0.1
      3. echo 1 >/sys/devices/system/cpu/cpufreq/ondemand/io_is_busy
      4. echo 25 >/sys/devices/system/cpu/cpufreq/ondemand/up_threshold
      5. echo 10 >/sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
      For up-threshold, with some kernels a setting of up to 29 results in the default behavior, so the lowest is 30. I tried setting mine on 1 and discovered the cpu was not changing speed at that low threshold, so I increased it to 2, rebooted and tried again, repeated for a while, and 30 works.

      For sampling_down_factor, it needs to be a long enough duration on high (since last threshold event) so that the speed doesn't go down in the middle of a file transfer. Here's a shortcut: If the sampling rate is 100000 and the throughput of a NanoPi gigabit or faster, then the minimum sampling down factor is 60. That may be enough for holding the speed and power steady so that it doesn't oscillate while writing files.

      So, I think it looks like this
      echo 100000 >/sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
      echo 1 >/sys/devices/system/cpu/cpufreq/ondemand/io_is_busy
      echo 30 >/sys/devices/system/cpu/cpufreq/ondemand/up_threshold
      echo 60 >/sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor

      That was my guess on a fixed setting that could support all of the different hardware. The greatest difference, of "up to" 5% will be at the target device (arm+usb2+gigabit); however, less than 1% difference to a full scale Xeon file server's throughput.

      The post was edited 2 times, last by deluxecat ().

    • Users Online 1

      1 Guest