New approach for Raspberry Pi OMV images

    • Just for the record. All the needed modifications I did to transform the fully automated OMV image for a Clearfog Base board into one that runs on Raspberries are collected now here: github.com/ThomasKaiser/OMV_for_Raspberries

      2 tweaks/fixes included that are currently not part of latest OMV release for Raspberries
      • Fix for the crontab issue
      • Now also uploading raspihealth.log if available when doing an 'armbianmonitor -u' (see the bottom of this example)
      Not sure if these two minor changes justify releasing a new image? I would wait for RPi people pushing a new kernel update (they're still at 4.9.41 while upstream 4.9 LTS is already somewhat ahead)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • Quick mini tutorial for initial Wi-Fi setup on a Raspberry Pi 3. Do NOT follow the tons of tutorials that tell you to fiddle around with /etc/network/interfaces and some wpa_supplicant stuff but just login as root (change the password now if you haven't done already) and simply enter

      Source Code

      1. nmtui-connect
      Then choose the wireless network you want to connect to from the list (in case you try to connect to a 'hidden' network which is NOT hidden anyway you would have to use 'nmtui-connect $name-of-the-network' instead before).

      Now enter the passphrase and you're already done:

      Please note that the above does not work if 'wlan0' has been added manually to /etc/network/interfaces, that you can simply adjust network settings by calling 'nmtui --> Edit connection' and please also note that onboard Wi-Fi performane is pretty crappy (single antenna and 2.4 GHz band only).

      If you want to use the Raspberry as an Access point instead please refer to the tutorial in post #5 of this thread instead (same for better Wi-Fi hardware)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.

      The post was edited 1 time, last by tkaiser: Added link to https://www.howtogeek.com/howto/28653/debunking-myths-is-hiding-your-wireless-ssid-really-more-secure/ ().

    • Would the above utility work with an R-PI 2, with a USB wireless dongle? wlan0 is recognized by Debian.

      (I'm assuming the above is captured from your latest OMV R-PI image. I haven't migrated yet.)

      Thanks
      Good backup takes the "drama" out of computing
      ____________________________________
      OMV 3.0.88 Erasmus
      ThinkServer TS140, 12GB ECC / 32GB USB3.0
      4TB SG+4TB TS ZFS mirror/ 3TB TS

      OMV 3.0.81 Erasmus - Rsync'ed Backup Server
      R-PI 2 $29 / 16GB SD Card $8 / Real Time Clock $1.86
      4TB WD My Passport $119
    • flmaxey wrote:

      Would the above utility work with an R-PI 2, with a USB wireless dongle? wlan0 is recognized by Debian.
      Sure though I don't know whether nmtui/nmcli are installed on Raspbian (your OMV image is based on). But they're just an 'sudo apt-get --no-install-recommends install network-manager' away if not present.

      And I would strongly recommend to read through these two threads if you're interested in a SBC Wi-Fi experience that does not suck:
      (the performance relevant stuff IMO is: at least 2x2 MIMO, if 5GHz band is available then use it)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • I got one an ultra cheap USB to wireless, Tenda, on "sale for $5" at Microcenter item, so I doubt that good performance is even possible.

      I tried the apt-get line above. While all appeared to download correctly, nmtui-connect didn't work but that's fine. I have to do the image upgrade soon.

      Knowing a few things about RF, I read the above links with interest. Antennas are definitely important and, while passive, they can be more important than the gain of final amp. While a full or 1/2 wave length wire works fine for most home applications, antenna design is yet another use case consideration.
      _____________

      If you're interested, the following is what happened. (The result of past manual edits?)

      root@openmediavault:~# nmtui-connect

      **
      nmtui:ERROR:nmt-newt-listbox.c:333:update_active_internal: assertion failed: (priv->active >= 0 && priv->active < priv->entries->len)
      Aborted
      root@openmediavault:~#
      ______________

      Again, thanks
      Good backup takes the "drama" out of computing
      ____________________________________
      OMV 3.0.88 Erasmus
      ThinkServer TS140, 12GB ECC / 32GB USB3.0
      4TB SG+4TB TS ZFS mirror/ 3TB TS

      OMV 3.0.81 Erasmus - Rsync'ed Backup Server
      R-PI 2 $29 / 16GB SD Card $8 / Real Time Clock $1.86
      4TB WD My Passport $119
    • Somewhat continuing the security related discussion from here I've implemented now on the RPi image both a mandatory root passwd change on first login and also defined 'PermitRootLogin no' (recent changes here). In other words: SSH with a known default password on Raspberries is not possible any more with latest image since first step is either creating a new sudo enabled user or allowing root SSH login and then the passwd has to be changed anyway. Will then look like this:

      So 2 x 'openmediavault' followed by 2 x the new password. I've seen not just one person failing with this already :(

      Unfortunately those lazy Raspbians ;) still do not provide a new 4.9 LTS kernel package (4.9.53 vs. 4.9.41 in their repo) so latest image shares name with one from a few weeks ago: OMV_3_0_88_RaspberryPi_2_3_4.9.41.img.xz (MD5 sum: b18007156c92dedab53df4a0898d0400)

      Tested with both RPi 3 (armbianmonitor -u after Arrakis upgrade) and RPi 2 (armbianmonitor -u -- please enjoy dmesg output rebooting RPi 2 automatically after 930 seconds compared to 470 on RPi 3 before, that's the difference an 'average' SD card vs. a good Samsung can make. With a real crappy SD card the time between first boot and automatic reboot might be even much longer than 15 minutes)

      Areas of testing:
      @ryecoaaron -- please exchange image, no other stuff needs to be updated since image name remains the same and MD5 sum is available through SF.

      Wrt all the other ARM images the needed fix is upstreamed to Armbian, but I won't regenerate images now since in a few weeks a new major Armbian release is to be expected and unlike with Raspberries we already disabled root SSH login on all the current images. So only the enforced password change is missing but I think this needs no immediate action and can be postponed a few more weeks.

      Proposed change: Add to each readme.txt in the 3 ARM OMV image download directories:

      Source Code

      1. - If you want to login to your board with SSH create an own user
      2. account in the web interface and add it to groups sudo and ssh.
      And a final note to all moderators: If users report any sort of problem with Raspberries or other ARM devices always the first thing to ask for is output from 'armbianmonitor -u' (see example output above).
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.

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

    • tkaiser wrote:

      please exchange image
      done.

      tkaiser wrote:

      Proposed change: Add to each readme.txt in the 3 ARM OMV image download directories:
      I will do that later today (hopefully).
      omv 4.0.6 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • Hi!
      I'm trying to mount my NTFS disk with the latest version and I get errors from FUSE.
      First thing I tried was:
      modprobe fuse
      modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/4.9.41-v7+/modules.dep.bin'

      Then I realize the image is missing the 4.9.41-v7+ headers, it only has the 4.11.2-pi64+ and 4.9.35-v7+ (which in itself is a problem that should be fixed).
      I tried installing them with:
      sudo apt-get install raspberrypi-kernel-headers

      but I still have errors:
      sudo modprobe fuse
      modprobe: ERROR: ../libkmod/libkmod.c:508 kmod_lookup_alias_from_builtin_file() could not open builtin file '/lib/modules/4.9.41-v7+/modules.builtin.bin'

      If you have any idea how to help me, I would gladly that it :)
      Thanks

      EDIT: ok I understood that I have to run depmod before to generate this file (currently empty). When I try to run this command I get another error:
      depmod: WARNING: could not open /lib/modules/4.9.41-v7+/modules.order: No such file or directory
      depmod: WARNING: could not open /lib/modules/4.9.41-v7+/modules.builtin: No such file or directory
      Those files do not exists, so now I'm trying to find a way to fetch them.

      EDIT 2: Got it working. I installed rpi-update and ran it. That bumped the kernel to 4.9.53 (the raspbian people are not too lazy after all :p) and installed the kernel headers at the same time. Now it's working great.

      The post was edited 4 times, last by Sytten ().

    • Sytten wrote:

      Then I realize the image is missing the 4.9.41-v7+ headers, it only has the 4.11.2-pi64+ and 4.9.35-v7+ (which in itself is a problem that should be fixed).
      Well, I only waited for the first report (that happened right now, after ~20,000 downloads of the new RPi image variants). In our experiences (speaking of Armbian team) installation of kernel headers can be considered a random IO benchmark if SBC users rely on average (crappy) SD cards. We have reports of people waiting several hours to days with very slow SD cards. That's the reason I avoided this so far since all these RPi specific packages aren't part of the image anyway but will be installed on first boot.

      Users with an average (slow/crappy) SD card might then have to wait hours until they're able to use their Raspberries if kernel headers are added. But you're talking about modules above aren't you? At least you report missing modules and not kernel headers which could be an indication for your installation having not finished /etc/init.d/firstrun successfully?

      Sytten wrote:

      I installed rpi-update and ran it.
      Always an option for experienced users who read the fineprint (especially the 'unstable, testing' and 'is not guaranteed to work correctly' parts). Glad you resolved it but I really doubt adding headers is a good idea and most probably in your situation a simple

      Source Code

      1. apt-get -q --reinstall -y install raspberrypi-kernel
      should've done the job. Reflashing the latest image and giving it its time to install everything at first boot and then reboot once will also work of course:

      Source Code

      1. root@raspberrypi:~# ls -la /lib/modules/4.9.41-v7+/modules.dep.bin
      2. -rw-r--r-- 1 root root 224400 Aug 11 19:04 /lib/modules/4.9.41-v7+/modules.dep.bin
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.

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

    • Hi, I will try to reinstall today. Still got problems with my NTFS drive.
      It is recognized, but when I try to add it to the SMB share, the device doesn't show up.
      Also I have an error when I try to unmount:

      Source Code

      1. The XPath query '//system/fstab/mntent[((((((fsname='/dev/sda1' or fsname='/dev/disk/by-id/ata-WDC_WD10EADS-00M2B0_WD-WCAV50370373-part1') or fsname='/dev/disk/by-id/wwn-0x50014ee2ada70499-part1') or fsname='/dev/disk/by-label/Backup') or fsname='/dev/disk/by-path/platform-3f980000.usb-usb-0:1.3:1.0-scsi-0:0:0:0-part1') or fsname='/dev/disk/by-uuid/4208652808651C63') or fsname='4208652808651C63')]' does not return the requested number of 1 object(s).
    • Sytten wrote:

      Still got problems with my NTFS drive.
      Not worth an investigation for two reasons :)

      1. Something is wrong with your installation since you reported '/lib/modules/4.9.41-v7+/modules.dep.bin' missing which has to be there by definition (my assumption: something went wrong prior to first automated reboot and installation didn't finished properly). So please reinstall (downloading again since we exchanged the image yesterday to fix few minor issues, see post #46 above) and if issues persist please post output from 'armbianmonitor -u' in any case
      2. NTFS mounted on Linux... I can't remember having done this ever before but IIRC you have to set some special mount options. And performance will be crappy anyway
      I'm stupid. Just remembered that I tested NTFS on an ARM board recently the moment I wrote the words 'crappy performance': cnx-software.com/2017/06/18/na…enchmarks/#comment-544662 (please keep in mind that I tested on a beefy SBC there and not on a slow Raspberry where things are even worse :) )
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • New

      Hello,

      I installed latest version of omv on my Raspberry pi 3 model b today. I am trying to configure WiFi through nmtui-connect. I am getting following error .

      **
      nmtui:ERROR:nmt-newt-listbox.c:333:update_active_internal: assertion failed: (priv->active >= 0 && priv->active < priv->entries->len)
      Aborted


      I am also not able to see wlan0 when I do ifconfig -a. It is similar error that flmaxey has reported in post # 45. Looking forward for your valuable help.

      Thanks
    • New

      kuleen wrote:

      Looking forward for your valuable help.
      Sorry, at least I won't look into since I wasted already way too much time with an OMV platform that simply sucks: Raspberry Pi. These boards suffer from a power design flaw (crappy Micro USB responsible for all sorts of problems) and Wi-Fi on this thing is also just a bad joke (2.4GHz band only, single antenna, mini aerial -- this is ok to transfer some sensor data every few seconds but otherwise useless since you need at least 2x2 MIMO and if you live not in a rural area also 5 GHz band to get any decent Wi-Fi performance).

      You might provide output from both 'armbianmonitor -u' though for others willing to help (and in case you're not using most recent RPi image also a few lines from 'sudo raspimon' to get an idea whether you suffer from undervoltage). Also if nmtui isn't working simply follow any of the available tutorials getting Wi-Fi up and running with Raspbian.
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • New

      tkaiser thanks for your reply. I am using 2.5 amp original pi adapter. Output of armbianmonitor -u is as follows.
      /var/log/armhwinfo.log has been uploaded to sprunge.us/Gfhf

      Output of sudo raspimon
      /usr/sbin/raspimon: line 18: vcgencmd: command not found
      /usr/sbin/raspimon: line 19: vcgencmd: command not found
      /usr/sbin/raspimon: line 20: vcgencmd: command not found
      /usr/sbin/raspimon: line 22: vcgencmd: command not found
      13:23:08: 600/ MHz 0000000000000000000
      /usr/sbin/raspimon: line 18: vcgencmd: command not found
      /usr/sbin/raspimon: line 19: vcgencmd: command not found
      /usr/sbin/raspimon: line 20: vcgencmd: command not found
      /usr/sbin/raspimon: line 22: vcgencmd: command not found
      13:23:13: 1200/ MHz 0000000000000000000
      /usr/sbin/raspimon: line 18: vcgencmd: command not found
      /usr/sbin/raspimon: line 19: vcgencmd: command not found
      /usr/sbin/raspimon: line 20: vcgencmd: command not found
      /usr/sbin/raspimon: line 22: vcgencmd: command not found
      13:23:18: 600/ MHz 0000000000000000000
    • New

      kuleen wrote:

      /usr/sbin/raspimon: line 18: vcgencmd: command not found
      That's what I was looking for. It seems you were either not patient (and disrupted the first boot before the necessary bits are installed), or your board had no network connection at first boot or something went wrong.

      I would strongly recommend to reimage the card and start over and this time give the system at least 20 minutes (or wait until it reboots) at first boot WITH ETHERNET connected and a working internet connection.

      This stuff here github.com/ThomasKaiser/OMV_fo…init.d/firstrun#L264-L293 wasn't executed and that's why there's no Wi-Fi (no firmware, no driver) and also no vcgencmd command to query Raspberry 'firmware'.
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.

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