Pinned Call for testers: OMV4 for ARM boards

    • alexruedi wrote:

      Does Virtualbox-plugin work on HC2? Was 100% i saw it, but cannot find it now... (i saw it on different sd card when I was first testing omv but don't have it anymore)
      HC2 as Odroid HC-2?
      This is the ARM architecture when it comes to the CPU. VirtualBox is a virtualization for the CPU architectures of the x86 family.
      I do not recall the virtualization software that can freely virtualize a bunch of two different CPU architectures for host and guest.
      If you want to use VirtualBox you have to use it on a machine with an x86 CPU just like the systems that will be virtualized must be from the x86 family.
      If you need virtualization on a machine with ARM CPU then kvm / xen or something similar. In this case, also virtualized systems must be for the ARM architecture.
      If, however, you are necessarily interested in virtualization / emulation of ARM / x86 architectures, then you can look at the paid software "ExaGear" from the Eltechs company. There is also free QEMU but remember that compatibility is a big problem and in addition, performance x86 emulation on ARM is a terrible decline in performance.
    • I have a Nanopi Neo Core 2 LTS. I've downloaded the current OMV pre-built image from here, and flashed it.

      Now I've got it booted up, and I'm checking out some basics. I've used OMV's System -> Network to change the hostname (I chose "filesrv1"), and specify a domain name (used in my internal LAN, which is "fritz.box"). Once saved and applied, I can see /etc/hosts contains these now.

      But there is no line saying "search fritz.box" in /etc/resolv.conf. Furthermore, /etc/resolv.conf contains the line "nameserver 1.1.1.1", but I would like the OMV box to use the nameserver 192.168.0.254, which gets dealt out over DHCP from my Fritzbox.

      I'm quite sure the most recent versions of Armbian do this behaviour now, which I just mentioned (quit using nameserver 1.1.1.1 by default, listen to the DHCP server for DNS server). Why do I know this? Because I noticed this worked as I expected once and only once I recently upgraded Armbian (when playing with a Nextcloud install).

      Maybe the pre-built images for OMV 4 need to be re-based off a newer Armbian to get this newer, better DNS-related behaviour included.

      What I can't do at present is this: on the command line in the OMV server, I can't use the command (to successfully resolve):

      host filesrv1

      ...nor:

      host filesrv1.fritz.box

      ...nor:

      host filesrv1 fritz.box

      ...nor:

      host filesrv1.fritz.box fritz.box

      ...but I can resolve the IP of the OMV server using commands like:

      host filesrv1 192.168.0.254

      ...and:

      host filesrv1.fritz.box 192.168.0.254
    • OK, another problem, this time more serious. The locales are not set nicely. I can't regenerate the locales decently with the command:

      dpkg-reconfigure locales

      ...which is the standard way to set and update one's locales in Debian. All I want is to set "en_US.UTF-8" as my default locale, and get no locale-related error messages.

      So what is my broken locale preventing me from doing? Setting up "snapper". After installing snapper, when I try to do command like:

      cd /sharedfolders/share1
      snapper -c share1 create-config .


      ...I get the error message:


      Failed to set locale. Fix your system.

      ...and no snapper configuration file called "share1" was created in /etc/snapper/configs/

      I see someone else also has this problem here, but no solution yet... and a workaround gets linked to there.


      Note that any "apt-get install" does work (as I managed to at least install the snapper package whatsoever), but locale grumbling (warning messages) happen a whole bunch of times during the process, which isn't normally seen on plain old Debian 9 (on a PC).

      Edit: I've got snapper working now.

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

    • esbeeb wrote:

      I think you'll be surprised to hear that on a NanoPi Neo Core 2 LTS, an external 3.5" hard drive (in a USB 3.0 enclosure with a JMS578 controller) ends up being slightly faster, over the network, than a 2.5" SATA SSD connected to the "NAS kit" accessory board

      No idea what the purpose of such a test should be (since when done appropriately the USB2 interface between host and HDD/SSD will always be the limiting bottleneck once filesystem buffers are full), also no idea why you test with 'SMB1' (this is a horrible SMB dialect / protocol revision that should have long died). This is Microsoft's position on SMB1: STOP USING IT!

      As to your numbers from here -- they're bad anyway since with a true Gigabit Ethernet network connection as long as filesystem buffers are empty transfer speeds should exceed 60 MB/s and once buffers are to be flushed to disk USB2 becomes the bottleneck and speeds should drop down to ~35MB/s. No idea what's going on in your installation but your speeds are simply way too low.

      Please look at the transfer speeds generated last year: forum.armbian.com/topic/3953-p…ges-for-sbc-with-armbian/ (and please note that I won't answer at Armbian forum any more since a censorship incident happened on Oct 3 and I simply do not use forums where moderators who don't know what they do abuse their powers to censor stuff).
    • I'm just using the standard SMB support which OMV 4 offers, without hacking the default SMB settings. Is that SMB1, SMB2, or SMB3? Samba supports up to SMB3, apparently. Perhaps I too hastily assumed that I was using SMB1, believing it to be the default.


      Oops, I see I'm using SMB3.11, I got this by running the "smbstatus" command as root on the OMV server.

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

    • tkaiser wrote:

      ~35MB/s
      Yes, that's that fastest I've ever been able to get, on average (as in, I always purposely outrun the disk buffers because I upload/download 2GB worth of files as a test), when downloading over FTP (37 MB/sec, sustained).

      I'm using a lacklustre GbE dongle on my laptop, a TP-Link UE300 (which is better than jack squat, because it's supported in Linux whatsoever), and the fastest I've ever been able to get it to go is 40MB/sec, sustained (when connected do a different server, not this NanoPi). This dongle should be fast enough for my tests, as I've never hit that 40 MB/sec (and topped out). BTW, other laptops in the office, which have Wifi only, no ethernet at all, are only downloading the 2GB worth of tiny files at like 8 to 11 MB/sec. So my slow-sounding results with this TP-link GbE dongle are always substantially exceeding those wifi results on the other machines.
    • esbeeb wrote:

      I'm using SMB3.11, I got this by running the "smbstatus" command
      You do not get the SMB version/dialect this way since client and server negotiate this dynamically. But since you haven't changed settings at least you're not using SMB1 then.

      esbeeb wrote:

      I'm using a lacklustre GbE dongle on my laptop, a TP-Link UE300 (which is better than jack squat, because it's supported in Linux whatsoever), and the fastest I've ever been able to get it to go is 40MB/sec, sustained (when connected do a different server, not this NanoPi).
      So there (at least one of) your problems lives. You reported over at Armbian forum about 940 Mbits/sec tested with iperf so your network connection seems not to be the bottleneck. Since you mention Linux this might explain the poor SMB numbers if you mounted the drive via GUI in Linux. Just do a web search for 'GVFS slow samba' or 'gvfs slow smb' (since it's not a Samba problem at all but a client problem with SMB and Linux).

      As to your other assumptions/conclusions you reported over there forum.armbian.com/topic/8533-n…ab=comments#comment-67622 (I won't be answering there any more!).

      You or let's better say dmesg output reports data corruption. Btrfs is a modern filesystem designed for data integrity. If data corruption happened then btrfs will tell you. You can't make data corruption go away by switching to a more primitive filesystem like ext4 that does no integrity checking. The dmesg output you reported later (what you call 'UAS errors') is not about UAS at all but reports problems 'on the wire' (or on PCB/connectors as it's obviously possible with FriendlyELEC's NAS case).

      Your setup is broken in several ways and you shouldn't base any assumptions/conclusions on this (like the weird statement SSDs are not needed for high random IO performance. The use case you only tested is 'sequential transfers', one time with a large file and another time with a bunch of smaller files). Your numbers are not ideal for a couple of reasons you need to address individually instead of spreading dangerous conclusions.
    • tkaiser wrote:

      If data corruption happened then btrfs will tell you. You can't make data corruption go away by switching to a more primitive filesystem like ext4 that does no integrity checking.
      Yes, I've decided to go back to btrfs for that reason (this same thing about checksums occurred to me too, before I read your reply). Note that btrfs and ext4 seemed to perform about the same anyway, for the hardware I have.

      BTW: I tried a stock Armbian install (using their current version which is a little newer than yours, with a bit newer kernel), and so far I haven't had any disk errors again, when I copy files in and out of my disk on that troublesome USB port. Now I'll try to install OMV from the "softy" menu there, and see if I get the errors from before when transferring files in and out of that USB port on the NAS kit board (over SMB). I'll let you know how that goes.

      BTW: the slow SMB speeds I reported (8 and 11 MB/sec) on the non-Ethernet laptops (wifi only) are plain-jane Windows 10 laptops (one is a Microsoft-brand Surface tablet with detachable keyboard).

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

    • esbeeb wrote:

      I tried a stock Armbian install (using their current version which is a little newer than yours, with a bit newer kernel), and so far I haven't had any disk errors again, when I copy files in and out of my disk on that troublesome USB port
      You can't fix hardware issues by using different software. Btrfs when reporting data corruption caused by broken USB connections is reporting stuff that happens right now (read errors 'over the wire') or already happened in the past (write errors due to 'bad cabling'). I know, it's pointless to emphasize on this since users love to blame software instead of fixing hardware issues (be it fragile USB connections or underpowering which is another popular problem source with USB peripherals).
    • tkaiser wrote:

      You can't fix hardware issues by using different software
      I contemplated which hardware might be the problem. I hooked my external hard drive enclosures up to my laptop and did some testing. They seem to be perfect. I wondered why that one USB port might be problematic. I looked at the pins on the underside of the NAS kit board, for that USB port. The soldering looked a bit sloppy. I scratched between all the pins carefully for that USB port, in case a subtle electrical connection across the pins was happening. I'll see if those error messages come back. I'm using btrfs again, btw.