Pinned Call for testers: OMV4 for ARM boards

    • tkaiser wrote:

      In general there's a duplicate entry resulting in 'apt update' warning:
      Currently testing with RockPro64 using ayufan's latest OMV4 armhf image and running in a similar issue with duplicate entries:

      Source Code

      1. W: Target Packages (main/binary-armhf/Packages) is configured multiple times in /etc/apt/sources.list.d/omv.list:1 and /etc/apt/sources.list.d/openmediavault.list:1
      So I would assume this is part of the generic OMV installation routine since both his and mine images are 100% scripted/automated. It's the 'deb packages.openmediavault.org/public/ arrakis main' line that is a duplicate. No idea which file to delete in this case ?(
    • tkaiser wrote:

      No idea which file to delete in this case
      The repo that I found that was duplicated was the backports repo because OMV adds it but it was also in the sources.list. Which files have the openmediavault repo in them? /etc/apt/sources.list.d/openmediavault.list should be the only one.
      omv 4.1.8.2 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.9
      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!
    • Stolirocks wrote:

      any ideas how to fix these duplicate repo entries? It happens when I install omv from armbian-config

      Source Code

      1. rm /etc/apt/sources.list.d/openmediavault-kernel-backports.list
      2. apt update
      Please remember that it's a harmless warning and even if you have 100 times the same entry in different source lists it will be used only once and correctly. It's a cosmetical issue and my understanding is that it's generated by openmediavault-extras installation adding the kernel-backports repo (which is of no use on the ARM boards anyway) another time.
    • It's quite easy to either remove the file or comment out the duplicated line if the etc/apt config file - that's what I did.

      I think what @tkaiser is saying is that it's just the OMV GUI that is reporting there is an error - rather than it being a minor issue with the apt-get update process which still completes OK.

      A tip from me as an intermediate noob is that i always run an apt-get update and apt-get upgrade from the CLI (using ssh) as you get a better view of what happening and any errors.

      I'm not sure about the error with adding an interface using the OMV GUI. Has this been solved or is it still an issue?
    • Stolirocks wrote:

      so I just ignore this?
      At least I have to ignore screenshots since zero information. :)

      If you want to get things resolved you need to provide information. That's the 'Show details' button and then copy and paste in a code block here in the forum. Screenshots are pretty much useless if they contain only fractions of messages.

      jata1 wrote:

      forgot to mention that my rock64 is using the ayufan's latest OMV4 armhf image and it uses eth0 for the network. why/how is this given its OMV 4 / Deb 9?
      It's a kernel 'issue' and one of 'topology'. All SBC that use native networking (MAC inside the SoC mostly combined with an external PHY) still use the ethX scheme while those boards with USB networking (Raspberry Pi and ODROID XU4/HC1/HC2) get those enX names. And all network interfaces that can be plugged into different ports (PCIe and of course USB) now got predictable names to ensure that device names don't change when the same interface is plugged into a different port (can't happen on those ARM boards in question since the USB chip is on the PCB but this was a general design decision and it solved a real issue for people like my who often attach a bunch of RTL8153 dongles connected to SBC)

      So with USB Ethernet there's now predictable network interface names in Debian Stretch (Ubuntu for example switched already 2 years ago) and this is how it should work. Network interfaces work the same as before even if users consider the interface names 'ugly' or whatever.

      jata1 wrote:

      I'm not sure about the error with adding an interface using the OMV GUI. Has this been solved or is it still an issue?
      I tested this yesterday with OMV4 on a NanoPi NEO and when adding the interface with a static IP address I got an error message. At the same time the /etc/network/interfaces file was written correctly containing a static IP configuration. I then reverted the change in the UI, interfaces file remained the same and the config survived a reboot.

      Seems to me like a general problem with OMV4 and nothing special wrt ARM but I might be wrong (but don't care that much anyway -- DHCP works great since decades, service propagation by name works great since decades, it's just users who think they need more 'control' over their setups)
    • Stolirocks wrote:

      Sorry if I offended anyone
      Nobody feels offended. It's still just what I already wrote:

      tkaiser wrote:

      If you want to get things resolved you need to provide information. That's the 'Show details' button and then copy and paste in a code block here in the forum. Screenshots are pretty much useless if they contain only fractions of messages.
      So what about doing this now?!
    • tkaiser wrote:

      Please remember that it's a harmless warning and even if you have 100 times the same entry in different source lists it will be used only once and correctly. It's a cosmetical issue and my understanding is that it's generated by openmediavault-extras installation adding the kernel-backports repo (which is of no use on the ARM boards anyway) another time.
      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.
      omv 4.1.8.2 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.9
      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!
    • tkaiser wrote:

      Stolirocks wrote:

      Sorry if I offended anyone
      Nobody feels offended. It's still just what I already wrote:

      tkaiser wrote:

      If you want to get things resolved you need to provide information. That's the 'Show details' button and then copy and paste in a code block here in the forum. Screenshots are pretty much useless if they contain only fractions of messages.
      So what about doing this now?!
      I dont know how. Sorry but it's a long error window and I dont know how to put it in a code block. I'm new sorry. I'll try to learn.
    • Hi, fellows!

      Received my HC2 a few days ago. Installed your version of OMV 4. Then LMS (a music server was the goal).
      A few details to account for (access rights for LMS) but virtually nothing worth to mention.
      Have to spend some time to understand the ins and out, but I wanted to stress that you did quiet a nice job!

      So, Thank you!!!!!!!
      Odroid HC2 (NAS with LMS)
    • tkaiser wrote:

      Stolirocks wrote:

      so I just ignore this?
      At least I have to ignore screenshots since zero information. :)
      If you want to get things resolved you need to provide information. That's the 'Show details' button and then copy and paste in a code block here in the forum. Screenshots are pretty much useless if they contain only fractions of messages.

      jata1 wrote:

      forgot to mention that my rock64 is using the ayufan's latest OMV4 armhf image and it uses eth0 for the network. why/how is this given its OMV 4 / Deb 9?
      It's a kernel 'issue' and one of 'topology'. All SBC that use native networking (MAC inside the SoC mostly combined with an external PHY) still use the ethX scheme while those boards with USB networking (Raspberry Pi and ODROID XU4/HC1/HC2) get those enX names. And all network interfaces that can be plugged into different ports (PCIe and of course USB) now got predictable names to ensure that device names don't change when the same interface is plugged into a different port (can't happen on those ARM boards in question since the USB chip is on the PCB but this was a general design decision and it solved a real issue for people like my who often attach a bunch of RTL8153 dongles connected to SBC)
      So with USB Ethernet there's now predictable network interface names in Debian Stretch (Ubuntu for example switched already 2 years ago) and this is how it should work. Network interfaces work the same as before even if users consider the interface names 'ugly' or whatever.

      jata1 wrote:

      I'm not sure about the error with adding an interface using the OMV GUI. Has this been solved or is it still an issue?
      I tested this yesterday with OMV4 on a NanoPi NEO and when adding the interface with a static IP address I got an error message. At the same time the /etc/network/interfaces file was written correctly containing a static IP configuration. I then reverted the change in the UI, interfaces file remained the same and the config survived a reboot.
      Seems to me like a general problem with OMV4 and nothing special wrt ARM but I might be wrong (but don't care that much anyway -- DHCP works great since decades, service propagation by name works great since decades, it's just users who think they need more 'control' over their setups)

      Hi everyone, I tryed few days ago a fresh install of OMV in my Odroid XU4.

      It worked like a charm, but I had this problem you refere to about the ETHERNET connection. In my case I need a fixed IP cause I have a NAS which needs outsied access, but as you stated, after setting a fixed IP, the error came, I just reverted the settings but it remain with fix IP.

      The other error I got was related with the updates, I just removed the file /etc/apt/sourceslist.d/kyle1777-ubuntu-ppa-cosmic.list and now everything is fine.

      Thanks for your help and work for the Odroid Xu4.
    • tkaiser - I have just downloaded the 'OMV_4_Raspberry_Pi_2_3_3Plus' image and installed on my new RPi B+. Issue i'm facing is I'm using a Logitech K400+ keyboard and it's not being reconignesd. Is there any way to inject the drivers so that it'll work out the box? I have no issue with RaspBian on same device and same keyboard.
    • ShaneM wrote:

      Is there any way to inject the drivers so that it'll work out the box?
      Neiher know nor care. :)

      It should work since we use exactly the same kernel (= drivers) as Raspbian guys do (from archive.raspberrypi.org) but why connecting display/keyboard anyway? OMV is a headless system, it needs only a network connection and everything else you do in the browser or a SSH console. There's really no need to attach a keyboard and a display (and if I ever touch the image again I'll ensure by adding '/usr/bin/tvservice -o' to /etc/rc.local HDMI will be turned off since this saves 150 mW)

      Both keyboard and display are useless consumers especially on a Raspberry Pi that is plagued by underpowering issues.
    • ShaneM wrote:

      I'm using Wireless due to my setup, so I need to configure the wireless
      Plug it into ethernet to configure it and the wireless before putting it in the cupboard.
      omv 4.1.8.2 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.9
      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!