Pinned Call for testers: OMV4 for ARM boards

    • Ok, another 4 hours wasted on the most crappy SBC platform OMV is capable to run on :(

      These fixes should've done the job. At least motd (login greeting) is correct now and also generic installed packages are only pulled in from Debian but not raspberrypi.org any more.

      @ryecoaaron or anyone else: please test again: OMV_4_Raspberry_Pi_2_3_3Plus.img.xz

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

    • tkaiser wrote:

      there's a duplicate entry resulting in 'apt update' warning:
      I was going to mention this but forgot.

      tkaiser wrote:

      And then this error occurs for whatever reasons:
      This is a python bug. Upgrade Debian 9 and 4.x

      tkaiser wrote:

      @ryecoaaron or anyone else: please test again:
      I will test it tonight.
      omv 4.1.22 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.15
      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 everyone. I am new at omv and I have just buy a Raspberry Pi 3b+. Yesterday I installed OMV V4 and setup my pi as samba and plex servers. I have copied some files throw the network and seen some videos on plex clients (PS4 and Samsung smart tv). I'm also thinking about setup the pi as a webserver for development tests (nginx + mysql, I guess).
      So if someone give me some instructions I can test further.

      Thanks and sorry for my english, I'm spanish.
    • @tkaiser - thanks for the work on these

      I have tested on my trusty RPi - you'll be pleased to know that I now only use the RPi for testing stuff and not a NAS. :)

      I have a rock64 as my main server. Using the latest ayufan OMV4 build. This is working well.

      Output below from my RPi

      ix.io/1c4Y

      Initial observations are it is good. Only things that i noted in the logs are:

      1. watchdog module not present so it fails - I have disabled watchdog using - systemctl disable watchdog
      2. something is not working with ttyS2. I think this issue was also in the jessie/OMV3 image/build - log entries below.

      Jun 2 16:22:57 RPI systemd[1]: dev-ttyS2.device: Job dev-ttyS2.device/start timed out.
      Jun 2 16:22:57 RPI systemd[1]: Timed out waiting for device dev-ttyS2.device.
      Jun 2 16:22:57 RPI systemd[1]: Dependency failed for Serial Getty on ttyS2.
      Jun 2 16:22:57 RPI systemd[1]: serial-getty@ttyS2.service: Job serial-getty@ttyS2.service/start failed with result 'dependency'.
      Jun 2 16:22:57 RPI systemd[1]: dev-ttyS2.device: Job dev-ttyS2.device/start failed with result 'timeout'.
    • tkaiser wrote:

      we can move everything to Sourceforge.
      Downloading images now.
      omv 4.1.22 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.15
      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:

      Downloading images now
      @ryecoaaron Thank you. At least the Banana Pi image at sourceforge.net/projects/openm…ngle%20Board%20Computers/ seems to be corrupted. As a reference the MD5 hashes from my server:

      Source Code

      1. e387b82ef6f88ac45f54f8ccde9b98e4 OMV_4_Banana_Pi.img.xz
      2. 0ea8cc6c0e1040ebbd9d0a871d9a2019 OMV_4_Banana_Pi_M2_Plus.img.xz
      3. 789b3c50ccfab607c942de69b2d4fcb3 OMV_4_Banana_Pi_Pro.img.xz
      4. 8772de3602a742687b0cd35f2b826a9b OMV_4_Cubietruck.img.xz
      5. 2e711e6946cfb70d22239dfe95797a7b OMV_4_Espressobin.img.xz
      6. 831007e758953c903cd2346cb59e3e06 OMV_4_NanoPi_M1_Plus_2.img.xz
      7. 192803563d01fe0bde74e0ed8d6b1572 OMV_4_NanoPi_NEO_2.img.xz
      8. 1df0a3775a593652cdc73720543754f8 OMV_4_Odroid_C2.img.xz
      9. 66569cfe1c0f4627c4f611aa68c08737 OMV_4_Odroid_XU4_HC1_HC2.img.xz
      10. 0a0f0062523f7a383386a1256a97dd3f OMV_4_Orange_Pi_PC_2.img.xz
      11. 0a1fbe286f06b7051c86338f902e5e83 OMV_4_Orange_Pi_PC_Plus.img.xz
      12. cc9a0741ab16a1fc2c7f94ebbc9e7537 OMV_4_Orange_Pi_Plus_2E.img.xz
      13. 8314af7395c4ad637f462b652bac1caa OMV_4_Orange_Pi_Plus.img.xz
      14. a34d1575dba4cecd7b86f7aba784c6d1 OMV_4_Orange_Pi_Zero_Plus.img.xz
      15. d55bbbbbc33e7bb32f66d5edd24dd04c OMV_4_Pine64.img.xz
      16. c9d833c608e42dbda98538c02f9da9a5 OMV_4_Raspberry_Pi_2_3_3Plus.img.xz
      17. c6f924a3a7a44b2ab54fd33b76ea3d52 OMV_4_Tinkerboard.img.xz
      Display All

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

    • tkaiser wrote:

      At least the Banana Pi image at sourceforge.net/projects/openm…les/4.x%20armhf%20images/ seems to be corrupted. As a reference the MD5 hashes from my server:
      I had some problems uploading at the beginning (using sftp). I deleted the bad image and the new image is uploading now.
      omv 4.1.22 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.15
      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:

      Now what to do with the older directories?
      I think they should stick around for another month or so.
      omv 4.1.22 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.15
      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:

      But it would be great if you could rename the directory to 'OMV 4 for Single Board Computers' since currently it's IMO a bit confusing and misleading
      Works for me. Changed.
      omv 4.1.22 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.15
      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,
      did some testing with the OMV 4.1.7 image for the Odroid HC1 ("OMV_4_Odroid_XU4_HC1_HC2.img.xz"). I had to roll back to 3.0.99 because of some problems. I'm not an Linux/Debian expert, so maybe ive just made a mistake.
      Here are my findings after the initial boot with a newly flashed sd-card:

      1.) The ethernet adapter has a very strange name "enx001122334455" where "001122334455" is the MAC-address of the adapter. In the old build (3.0.99) it was just the usual "eth0".
      2.) I wasnt able to add the interface in the network settings of the gui (see screenshot).
      3.) The check for available updates did not work (see screenshot).

      After that I switched back to my old installation. I have saved the syslog and the system-information->report file. If one of the moderators is interested, I can send them.

      Thanks for your effort!

      p.parker
      Images
      • openmediavault-system-aktualisierungsverwaltung.png

        192.89 kB, 1,663×902, viewed 292 times
      • openmediavault-system-netzwerk.png

        177.27 kB, 1,663×902, viewed 258 times
      Odroid HC1 | HGST Travelstar 7K1000 | OMV 4.1.20-1 (Arrakis) | 4.14.94-odroidxu4
    • jata1 wrote:

      I think the long name for eth0 is by design?
      Of course: freedesktop.org/wiki/Software/…bleNetworkInterfaceNames/

      While in Debian 9 (OMV4's basis) it's still possible to use the names from last century neither will this work with next Debian release nor will I share how since predictable interface names should be fine. Other distros switched to predictable names already years ago.
    • jata1 wrote:

      ...I think the long name for eth0 is by design?
      Hi,
      regarding to my good friend google your right. its a "feature" named "consistent network device naming". Here's a thread with some Info.
      In this thread is a fix for odroid (possibly for other single board computers).

      Source Code

      1. root@odroid:~# cat /etc/udev/rules.d/70-persistent-net.rules
      2. SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth0", NAME="eth0"

      maybe this will help...

      p.parker
      Odroid HC1 | HGST Travelstar 7K1000 | OMV 4.1.20-1 (Arrakis) | 4.14.94-odroidxu4
    • tkaiser wrote:

      peterparker wrote:

      In this thread is a fix for odroid (possibly for other single board computers)
      This is not a 'fix' since those predictable en... names are neither a problem nor a bug but a solution for a long standing problem with the stupid/primitive/anachronistic interface names like eth0 (exchange position of PCIe cards and the naming of your network interfaces changes!)
      uhhh. ok. then I will apologize for my " stupid/primitive/anachronistic" link. I really should be more carefull and I didnt know that "namig network interfaces" could possibly be a science (or maybe a religion...). ;)
      Anyway. Maybe I make another try with this knowledge and the error messages that I posted above will magically disappear.

      p.parker
      Odroid HC1 | HGST Travelstar 7K1000 | OMV 4.1.20-1 (Arrakis) | 4.14.94-odroidxu4