Building OMV automatically for a bunch of different ARM dev boards

  • But I think the system does not reboot successful or doesn't finish it's automatic setup.

    Yes, this here


    Code
    [    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 https://forum.armbian.com/topi…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:


    Code
    ENABLE="true"
    GOVERNOR="ondemand"
    MAX_SPEED="1296000"
    MIN_SPEED="480000"

    to

    Code
    ENABLE="true"
    GOVERNOR="ondemand"
    MAX_SPEED="1296000"
    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/

  • 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...)

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


    Code
    ENABLE="true"
    GOVERNOR="ondemand"
    MAX_SPEED="480000"
    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/

  • 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: http://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

    "This post will remain inaccessible for others until approved by a censor." - George Orwell X/

  • 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).

  • 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!

    • Offizieller Beitrag

    Can you please another time replace 3 OMV images (and add one):

    Done.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

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


    Code
    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)

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


    Code
    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

    HP t630 Thin Cliënt (AMD Embedded G-Series GX-420GI | QuadCore | 8GB)
    7.0.4-2 (Sandworm) | 64 bit | pve-kernel-6.5 | omvextrasorg 7.0

    Einmal editiert, zuletzt von Frepke () aus folgendem Grund: espressobin disappears from my network after a few hours

  • have a couple of ERRORS

    Thank you for the report. Installation routine was buggy and I tried to fix it: https://github.com/armbian/con…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 https://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:


    Code
    setenv fdt_name boot/dtb/marvell/armada-3720-community.dtb
    saveenv
    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 the report. Installation routine was buggy and I tried to fix it: https://github.com/armbian/con…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 https://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:


    Code
    setenv fdt_name boot/dtb/marvell/armada-3720-community.dtb
    saveenv
    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

    HP t630 Thin Cliënt (AMD Embedded G-Series GX-420GI | QuadCore | 8GB)
    7.0.4-2 (Sandworm) | 64 bit | pve-kernel-6.5 | omvextrasorg 7.0

    Einmal editiert, zuletzt von Frepke ()

    • Offizieller Beitrag

    @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.

  • 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)

  • 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...

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


    Code
    echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 
    sleep 0.1 
    echo 1 >/sys/devices/system/cpu/cpufreq/ondemand/io_is_busy 
    echo 25 >/sys/devices/system/cpu/cpufreq/ondemand/up_threshold 
    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.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!