Pinned Call for testers: OMV4 for ARM boards

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

    • BTW: RPi 3+ users will experience most probably another loss of performance when updating the next time: raspberrypi.org/forums/viewtopic.php?f=63&t=217056

      The topic talks about Raspbian but this is not true.

      As most people don't know or try to forget about, the primary operating system on every Raspberry Pi is an RTOS called ThreadX running on the VideoCore IV CPU (VC4). This has total control over the hardware unlike secondary operating systems like Linux on the guest ARM processors.

      Since we need to automagically update the so called 'firmware' (that's the proprietary closed source ThreadX thing in reality) all OMV 3 and 4 installations on Raspberries will get this new behaviour soon or got it already. To get back the old behaviour (better performance under full load) you need to edit the ThreadX config file as explained in the link above.

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

    • ryecoaaron wrote:

      Actually this file is generated by OMV itself. Unless you disable backports in /etc/default/openmediavault, it will be recreated any time omv-mkconf apt is called (omv-extras does any time you change a repo). Plus the file is enabling the debian backports repo and pinning the kernel. This shouldn't hurt arm images. So, I would recommend removing the backports repo from /etc/apt/sources.list instead.

      Getting back on the warning about duplicate sources... this is now used by funny people over in Hardkernel forum to run an 'OMV is broken' campaign...

      I didn't pay that much attention to the warning since... it's just a warning. But thinking about it novice or inexperienced users most probably are scared by the amount of messages this single duplicate line generates with every update attempt.

      And I've to admit I still don't get where the duplicate originates from or why. I understood that 'deb httpredir.debian.org/debian stretch-backports main contrib non-free' gets added to /etc/apt/sources.list with an OMV4 installation regardless of $OMV_APT_USE_KERNEL_BACKPORTS defined in /etc/default/openmediavault.

      Once I set OMV_APT_USE_KERNEL_BACKPORTS="YES" in/etc/default/openmediavault and then call 'omv-mkconf apt' the duplicate entry in '/etc/apt/sources.list.d/openmediavault-kernel-backports.list' is created. But backports are enabled all the time anyway since the contents of /etc/apt/sources.list remain unchanged and there it's set.

      So what is the best generic way to get rid of this duplicate in a way it's not re-enabled after clicking around in the OMV UI (which as you said will happen everytime with omv-extras active)?

      Same goes for the Python bug that is part of Debian 9 and most probably will never get fixed in Debain upstream. Once people install OMV 4 on their Debian 9 from then on they get these annoying warnings each and every time they run an apt task and obviously are scared. How to fix this on our side?
    • tkaiser wrote:

      Getting back on the warning about duplicate sources... this is now used by funny people over in Hardkernel forum to run an 'OMV is broken' campaign...

      I didn't pay that much attention to the warning since... it's just a warning. But thinking about it novice or inexperienced users most probably are scared by the amount of messages this single duplicate line generates with every update attempt.

      And I've to admit I still don't get where the duplicate originates from or why. I understood that 'deb httpredir.debian.org/debian stretch-backports main contrib non-free' gets added to /etc/apt/sources.list with an OMV4 installation regardless of $OMV_APT_USE_KERNEL_BACKPORTS defined in /etc/default/openmediavault.

      Once I set OMV_APT_USE_KERNEL_BACKPORTS="YES" in/etc/default/openmediavault and then call 'omv-mkconf apt' the duplicate entry in '/etc/apt/sources.list.d/openmediavault-kernel-backports.list' is created. But backports are enabled all the time anyway since the contents of /etc/apt/sources.list remain unchanged and there it's set.

      So what is the best generic way to get rid of this duplicate in a way it's not re-enabled after clicking around in the OMV UI (which as you said will happen everytime with omv-extras active)?

      Same goes for the Python bug that is part of Debian 9 and most probably will never get fixed in Debain upstream. Once people install OMV 4 on their Debian 9 from then on they get these annoying warnings each and every time they run an apt task and obviously are scared. How to fix this on our side?
      While I think the backports repo shouldn't be added to sources.lit, OMV should probably skip adding it if the repo is detected in another sources file like omv-extras does.. I could have omv-extra remove it but I think the best option would have omv skip it instead of adding it. I will look at a pull request when I get home.
      omv 4.1.15 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!
    • soerenderfor wrote:

      Somebody got the Openmediavault 4.0 image to work?
      No idea and at least I didn't test anything with Tinkerboard. Asus wanted to send me a dev sample in January but I rejected since this board is such a bizarre fail.

      On the other hand it's an automatically generated image by Armbian's build system, there are 100 downloads of the OMV image and I think it's somewhat unlikely that you're the first one reporting that it doesn't work at all (though possible). Again: no idea.
    • tkaiser wrote:

      soerenderfor wrote:

      Somebody got the Openmediavault 4.0 image to work?
      No idea and at least I didn't test anything with Tinkerboard. Asus wanted to send me a dev sample in January but I rejected since this board is such a bizarre fail.
      On the other hand it's an automatically generated image by Armbian's build system, there are 100 downloads of the OMV image and I think it's somewhat unlikely that you're the first one reporting that it doesn't work at all (though possible). Again: no idea.
      Hey tkaiser, thanks for the reply. I agree with you, it is not the most stable board :) I have tried almost all the images from Armbian, i can boot from them all. I always use 'Etcher' to burn the image file to card (Samsung EVO+ / Sandisk Ultra). I also power the board through the gpio. But when i boot, the cursor just blinking in the corner, and nothing else.

      I checked the config file and miqi.dtb was written in it. And in the dtb folder i found a tinker.dtb file, i was just wondering should the tinker.dtb be in the config instead of the miqi.dtb. I am not an expert so maybe it is a dumb question, sorry.

      I love OMV, and is really easy to use for me. The new image for Odroid C2 works without problems. I just got a couple of Asus tinker boards, and want to use them instead of laying around.

      Thanks for your time.
    • tkaiser wrote:

      soerenderfor wrote:

      But when i boot, the cursor just blinking in the corner, and nothing else
      Just regenerated the image: OMV_4_Tinkerboard.img.xz
      Can you please give it a try and report back?

      soerenderfor wrote:

      tkaiser wrote:

      soerenderfor wrote:

      But when i boot, the cursor just blinking in the corner, and nothing else
      Just regenerated the image: OMV_4_Tinkerboard.img.xzCan you please give it a try and report back
      Thanks, tkaiser.

      Yes, i will look at it in a couple of hours. And report back here. Again Thanks.
      Hey tkaiser.

      I have now tryed the new image from your link. Nothing happens, no ip adress or nothing. The orange led on board is blinking at first, and later it always is on. The network led blinks random. And after 25-30 min the board shutdown. And if i turn on, it starts over again and it ends with the board turning off.

      Nothing on the screen if i connect to the tinker board.
    • tkaiser wrote:

      soerenderfor wrote:

      Nothing on the screen if i connect to the tinker board.
      Thanks for the report. Last try: I created another OMV image, this time with mainline (Armbian next branch) instead of Rockchip's 4.4 LTS kernel (default branch). Please re-download the image and test again: OMV_4_Tinkerboard.img.xz (uploads currently, should be finished in 10 minutes).
      Good morning, i will look into it now. Thanks.
    • tkaiser wrote:

      soerenderfor wrote:

      Nothing on the screen if i connect to the tinker board.
      Thanks for the report. Last try: I created another OMV image, this time with mainline (Armbian next branch) instead of Rockchip's 4.4 LTS kernel (default branch). Please re-download the image and test again: OMV_4_Tinkerboard.img.xz (uploads currently, should be finished in 10 minutes).
      Hey tkaiser.

      Back to the blinking cursor, and still no IP address. Thanks, for your time.
    • soerenderfor wrote:

      Back to the blinking cursor, and still no IP address. Thanks, for your time

      Ok, then for you to enjoy OMV it's choosing an Armbian Stretch image from dl.armbian.com/tinkerboard/ and then using armbian-config to install an optimized OMV 4 version as outlined here: OMV4 on ARM boards (kind of a how-to)

      @ryecoaaron: can you please delete the Tinkerboard image from sourceforge.net/projects/openm…ngle%20Board%20Computers/ and while you're at it please replace Renegade and Rock64 image and readme.txt from kaiser-edv.de/tmp/jk4NM5/ (I found a bug in the RK3328 images and readme.txt contains some fixes/clarifications)
    • tkaiser wrote:

      can you please delete the Tinkerboard image
      Done.

      tkaiser wrote:

      while you're at it please replace Renegade and Rock64 image and readme.txt
      Uploading now.

      tkaiser wrote:

      I found a bug in the RK3328 images
      What bug? My renegade image is working well.
      omv 4.1.15 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:

      What bug? My renegade image is working well.

      As already mentioned we made some important changes in Armbian affecting the various optimization/monitoring services that run at boot. We added some features (e.g. zram based compressed ramlog), splitted some service so they got new names but my OMV installation routine still used the old locations (I fixed this stuff the last days).

      Based on timestamps I fear both RK3328 images were affected...
    • tkaiser wrote:

      Based on timestamps I fear both RK3328 images were affected...
      Ok. Just curious. I haven't used it much I will reflash.
      omv 4.1.15 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!
    • tkaiser wrote:

      Then you might want to have a look below /usr/lib/armbian/ (the zram and armbian-ramlog stuff, currently happily co-existing with flashmemory plugin)
      I need to look at the zram stuff some more to see if we should use it with the flashmemory plugin. I don't see a reason not to at the moment.
      omv 4.1.15 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!