New approach for Raspberry Pi OMV images

  • 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:

    Code
    - If you want to login to your board with SSH create an own user 
      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).

    • Offizieller Beitrag

    please exchange image

    done.


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

    I will do that later today (hopefully).

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    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.

  • 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?

    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

    Code
    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:


    Code
    root@raspberrypi:~# ls -la /lib/modules/4.9.41-v7+/modules.dep.bin
    -rw-r--r-- 1 root root 224400 Aug 11 19:04 /lib/modules/4.9.41-v7+/modules.dep.bin
  • 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:

    Code
    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).
  • Still got problems with my NTFS drive.

    Not worth an investigation for two reasons :)


    • 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
    • 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': https://www.cnx-software.com/2…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 :) )

  • 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

  • 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.

  • 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 http://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

  • /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 https://github.com/ThomasKaise…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'.

  • Hi all, I'm running OMV with rpi2 since 2 years (with a lot of issue:( )
    Now I know that there are OMV images "dedicated" for rpi2.
    How can I migrate from my OMV3.0 to "OMV for rpi" without loosing settings?

  • Hi all, I'm running OMV with rpi2 since 2 years (with a lot of issue:( )

    As expected, the hardware is not up to the job (NAS).


    Now I know that there are OMV images "dedicated" for rpi2.
    How can I migrate from my OMV3.0 to "OMV for rpi" without loosing settings?

    I fear you can't since the base system is something completely different (ARMv6 Raspbian vs. ARMv7 'original' Debian now). But it's useless to do such a switch anyway since you can't fix hardware in software and the only real possible advantage of the new RPi images is that they contain some monitoring features showing why it's wrong to use Raspberries as NAS: That's raspimon and the 'health' logfile explained in post #2 of this thread.

  • As expected, the hardware is not up to the job (NAS).

    I fear you can't since the base system is something completely different (ARMv6 Raspbian vs. ARMv7 'original' Debian now). But it's useless to do such a switch anyway since you can't fix hardware in software and the only real possible advantage of the new RPi images is that they contain some monitoring features showing why it's wrong to use Raspberries as NAS: That's raspimon and the 'health' logfile explained in post #2 of this thread.

    Ok, rpi isn't the right device to build a nas but my purpose is to have an ftp server and a media server to share media in my network.
    I'm not relying on a rpi to have a rock solid NAS.


    Why you say "ARMv6 Raspbian vs. ARMv7 'original' Debian now"? Rpi2 has an ARMv7 cpu, now I'm running OMV3 on a rpi2 so you are saying that below the line "my OMV" is running using Raspbian ARMv6 version?


    At the end there isn't a way to keep configurations and apply them to a fresh "OMV for RPI" image?

  • Why you say "ARMv6 Raspbian vs. ARMv7 'original' Debian now"? Rpi2 has an ARMv7 cpu, now I'm running OMV3 on a rpi2 so you are saying that below the line "my OMV" is running using Raspbian ARMv6 version?

    All Raspbian packages are built for ARMv6 (that's the whole reason Raspbian exists since back in 2012 upstream Debian already stopped supporting older architectures than ARMv7 so RPi folks had to build an own repo and rebuild all packages to be able to provide a Debian for the old single core ARMv6 Raspberries). The older OMV images for RPi (prior to mid July) relied on Raspbian so regardless which CPU type you use (RPi 3 and RPi 2B V1.1 use even 64-bit ARMv8 CPU cores) with Raspbian you always end up with code 'optimized' for ARMv6.


    Some stuff (eg. the stupid sysbench pseudo benchmark) could benefit a lot when built optimized for ARMv8 but with this use case here (NAS, that means IO and network bound) the differences are negligible (the RPi folks chose pretty good compiler flags so sometimes or even often a Raspbian ARMv6 binary can run faster than one built for Debian Jessie ARMv7)


    At the end there isn't a way to keep configurations and apply them to a fresh "OMV for RPI" image?

    AFAIK not.

  • All Raspbian packages are built for ARMv6 (that's the whole reason Raspbian exists since back in 2012 upstream Debian already stopped supporting older architectures than ARMv7 so RPi folks had to build an own repo and rebuild all packages to be able to provide a Debian for the old single core ARMv6 Raspberries). The older OMV images for RPi (prior to mid July) relied on Raspbian so regardless which CPU type you use (RPi 3 and RPi 2B V1.1 use even 64-bit ARMv8 CPU cores) with Raspbian you always end up with code 'optimized' for ARMv6.
    Some stuff (eg. the stupid sysbench pseudo benchmark) could benefit a lot when built optimized for ARMv8 but with this use case here (NAS, that means IO and network bound) the differences are negligible (the RPi folks chose pretty good compiler flags so sometimes or even often a Raspbian ARMv6 binary can run faster than one built for Debian Jessie ARMv7)


    AFAIK not.

    Ok thanks.
    So starting from scratch with OMV images from the first page (like this one) should be better to run OMV with rpi2, at last to have "healt" information.
    Using these new images also gain ARMv7 packages instead of "ARMv6 running over ARMv7 architecture", isn't it?

  • thanks tkaiser. I will re image the card and start over, this time with patience :). Will let you know the outcome.

    Today I tried with patience of over 20 mins and omv3 got properly setup on RPI3 model b. As you said it is not a good NAS solution (and I agree with you) but it is working good as media server with Plex plugin. I am able to stream 1080p videos through it. Thanks for your help to wait for atleast 20 mins for initial setup.


    sudo raspimon now gives me following output (yay) :
    Time Temp CPU fake/real Health state Vcore
    02:50:22: 72.0'C 1200/1200 MHz 0000000000000000000 1.2625V
    02:50:27: 72.0'C 1200/1200 MHz 0000000000000000000 1.2625V
    02:50:32: 72.0'C 1200/1200 MHz 0000000000000000000 1.2625V
    02:50:38: 72.0'C 1200/1200 MHz 0000000000000000000 1.2625V
    02:50:43: 72.0'C 1200/1200 MHz 0000000000000000000 1.2625V
    02:50:48: 72.0'C 1200/1200 MHz 0000000000000000000 1.2625V
    02:50:53: 73.1'C 1200/1200 MHz 0000000000000000000 1.2625V
    02:50:58: 70.9'C 1200/1200 MHz 0000000000000000000 1.2625V
    02:51:03: 72.0'C 1200/1200 MHz 0000000000000000000 1.2625V
    02:51:08: 72.5'C 1200/1200 MHz 0000000000000000000 1.2625V

  • 02:50:53: 73.1'C 1200/1200 MHz 0000000000000000000 1.2625V

    For the RPi being idle the temperature is way too high and in case the board is pretty active (then temperature could be reasonable) the voltage the CPU cores are fed with is too low (with a good Micro USB cable you should see +1.3V on an RPi 3 under load)

    • Offizieller Beitrag

    do i have any advantage / disadvantage switch to your Arabian image when it comes to performance?

    Maybe a little since the packages are compiled for the right cpu. I doubt you would notice any difference though.

    can I upgrade my old OMV3 raspian installation to OMV4 someday?

    Raspbian would need a stretch version. No idea if they do yet or not. That would probably be a good reason to switch to the armbian based image.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!