New approach for Raspberry Pi OMV images

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • New approach for Raspberry Pi OMV images

      New OMV image for Raspberry Pi 2 and 3!
      Important:
      • This image is not compatible with single core Raspberries (A, B, A+, B+, Zero, Zero W) since they're too slow anyway and their CPU architecture is not supported any more (it's not based on Raspbian any longer but on upstream Debian 'armhf' branch which supports ARMv6 architecture not longer)
      • For satisfying results burn it only with Etcher (no need to decompress, Etcher will verify burning process and save you from some common SD card troubles). It's strongly recommended to always test your SD card with either F3 or H2testw first to check for counterfeit/broken cards.
      • On first boot OMV installation will be finished. This requires your RPi being connected to network/Internet and might take between 2 and 15 minutes (depends solely on the random write speed of your SD card). After installation is finalized the Raspberry will reboot automatically and can then be used. Be patient please and in doubt watch the green led for activity.
      • A quick guide to do initial Wi-Fi setup has been added to the end of the thread.


      While this image uses upstream Debian repositories it is configured to fetch kernel/bootloader directly from official archive.raspberrypi.org repositories and also some proprietary binaries to deal with VideoCore IV (eg. vcgencmd, raspivid and others).

      Not so important (but still worth a read!):
      • This image does some 'health logging' in /var/log/raspihealth.log. On every shutdown there will be a single line logged that is either a timestamp plus a single zero (0) or a timestamp plus a bunch of digits. If the most left of these digits are a 1 instead of 0 your Raspberry either overheats or is powered insufficiently or both. If you run in instabilities please always check this first
      • There's /usr/local/sbin/raspimon included. This tool executed via SSH as 'sudo raspimon' reports real CPU clockspeeds by asking the firmware and also reports throttling, under-voltage and as a result the firmware doing 'frequency capping' (reducing all clockspeeds to save you from underpowering hassles negatively impacting performance). For a more detailed explanation please see here.
      • If you experience troubles you can always execute in a terminal 'sudo armbianmonitor -u' which will try to upload debug info to an online pasteboard service (RPi 3 example here, RPi 2 example there). It's a great idea to check the output yourself and at least to provide the URL if you ask for help in the forum.
      • The image resizes the rootfs automagically to ~3.7GB on first boot and creates a 3rd partition using the remaining space of the SD card you need to initialize manually if you want to use it for OMV shares ('mkfs.ext4|mkfs.btrfs /dev/mmcblk0p3')
      • While this OMV image looks like Armbian it's not (no support from Armbian team or in Armbian forum). We only chose the proven way to use Armbian's build system to generate OMV images for ARM boards now for Raspberries too (technically inclined people should look at the bottom of this post what is different)
      Please always keep in mind that on cheap single board computers like Raspberries the most common problem sources aren't software related but powering and/or SD card troubles. Please always check this first before reporting problems (see above for under-voltage detection, how to ensure to write OMV to SD card properly and if you report problems how to provide a debug log!)

      Technical details (nerd stuff!):
      • The rootfs of this image has been created fully automated by Armbian's build system on 12-Jun-2017 for a different ARMv7 device (fully automated means debootstrapped from scratch so no one ever logged in so far)
      • It has then been combined with an RPi image skeleton based on pi64 project and contains both a 64-bit 4.11 mainline kernel (inactive by intention) and latest official RPi 4.9.35 as the active 32-bit kernel (since this kernel variant will be updated through an apt repo so security fixes that require kernel updates aren't an issue). If you're adventurous you can transform this image into something that runs true 64-bit ARMv8 software on an RPi 3 (don't ask for support, better check out pi64 instead)
      • Since this OMV image has been created by Armbian's build system it contains a lot of Armbian utilities. Most of these aren't supported and must not be used. Only exception: 'sudo armbianmonitor -u' to provide a debug log.
      • /etc/update-motd.d/10-header has been changed to output the RPi model at login: BOARD_NAME="$(/usr/bin/awk -F" " '{print $1$2" "$3}' </proc/device-tree/model)"
      • Two more Armbian specific login hints below /etc/update-motd.d/ have been removed
      • /etc/apt/sources.list.d/armbian.list has been removed so you won't receive any Armbian updates
      • /etc/armbian-release has been manually adjusted to mark this image being unsupported and made for Raspberries
      • /etc/systemd/system/getty.target.wants/serial-getty@ttyS0.service renamed to reflect the fact that it's tty1S0 on Raspberries
      • /etc/hostname has been set manually to 'raspberrypi'
      • /etc/rsyslog.d/raspberrypi.conf included to filter out some annoying log messages
      • /etc/fstab is the standard Raspbian one (you might want to change / mount options to 'defaults,noatime,nodiratime,commit=600,errors=remount-ro' to reduce SD card wear out if you can ensure that your RPi is powered appropriately)
      • timezone is set automatically on first boot via tzupdate (not yet reflected in OMV UI)
      • Minor RPi specific logging/monitoring improvements
      • Everything else is from an Armbian armhf userland made for a Clearfog Base with some Raspberry specific additions below /lib/modules/ and /lib/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 6 times, last by tkaiser: Removed first paragraph since image went live. ().

    • How to interpret /var/log/raspihealth.log?

      This log gets written every time the Raspberry Pi shuts down. It contains a timestamp and then either a single zero (everything ok), 19 zeroes ('0000000000000000000' --> still everything ok) or a mix of 1 and 0 (problems occured).

      The meaning of these bits as follows:

      Source Code

      1. 1110000000000000010
      2. ||| |||_ under-voltage
      3. ||| ||_ currently throttled
      4. ||| |_ arm frequency capped
      5. |||_ under-voltage has occurred since last reboot
      6. ||_ throttling has occurred since last reboot
      7. |_ arm frequency capped has occurred since last reboot
      On Raspberries starting with model A+ and B+ there's under-voltage detection circuitry implemented triggering an alert via a GPIO pin toggled when the firmware detects input voltage dropping below 4.65V. If the under-voltage lasts longer the firmware decides to do 'frequency capping' (reducing clockspeeds of CPU cores, GPU/VPU and DRAM, also support voltages will be lowered).

      The reason is always the same: Insufficient PSU (cheap charger or a good one showing aging effects in the meantime) or insufficient cabling (99% of all USB cables suffer from this since they've tiny power wires with a resistance way too high). If this happens then you risk instabilities and when frequency capping occurs your Raspi performs way lower than it could. Run 'sudo raspimon' if in doubt.

      The other issue is thermal throttling / overheating. If this happens consider applying a heatsink. In tiny enclosures it might even be necessary to add a fan (or choose a better enclosure with some vents). Run 'sudo raspimon' if in doubt.
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • And a quick elaboration on how raspimon can be used to detect powering problems. In the following I used two different cables between my 5V/2A PSU and my Raspberry. The first is a a Micro USB cable I bought in a set with very low resistance (search for 20AWG on amazon.com for example), the second is an average Micro USB cable I found in the drawer.

      I used a somewhat heavy benchmark that is able to generate a lot of heat and consumption: cpuminer (the great thing with cpuminer is the benchmark mode so you really see when your Raspberry starts to behave strange either by frequency capping as below or if it starts to overheat. Since then the displayed khash/sec rates get lower).

      Test with the good 20AWG rated cable: I get 4.6 khash/s on average, the CPU cores clock with real 1200 MHz and the Vcore voltage gets increased to 1.325V. No under-voltage and frequency cap happened:

      Source Code

      1. root@raspberrypi:~# minerd --benchmark 2>&1 | grep Total
      2. [2017-07-14 14:35:03] Total: 4.65 khash/s
      3. [2017-07-14 14:35:08] Total: 4.67 khash/s
      4. [2017-07-14 14:35:13] Total: 4.67 khash/s
      5. [2017-07-14 14:35:18] Total: 4.62 khash/s
      6. [2017-07-14 14:35:23] Total: 4.59 khash/s
      7. [2017-07-14 14:35:28] Total: 4.67 khash/s
      8. ^C
      9. root@raspberrypi:~# raspimon
      10. To stop simply press [ctrl]-[c]
      11. 47.8'C 600/ 600 MHz 0000000000000000000 1.2V
      12. 47.2'C 600/ 600 MHz 0000000000000000000 1.2V
      13. 47.8'C 1200/ 600 MHz 0000000000000000000 1.3250V
      14. 60.1'C 1200 MHz 0000000000000000000 1.3250V
      15. 63.9'C 1200 MHz 0000000000000000000 1.3250V
      16. 67.1'C 1200 MHz 0000000000000000000 1.3250V
      17. 69.3'C 1200 MHz 0000000000000000000 1.3250V
      18. 72.0'C 1200 MHz 0000000000000000000 1.3250V
      19. 63.4'C 1200 MHz 0000000000000000000 1.3250V
      20. 59.1'C 600/ 600 MHz 0000000000000000000 1.2V
      21. ^C
      Display All

      Now repeating the test this time using the 'average' Micro USB cable. Now I get only 2.4 khash/s on average, the CPU cores stay at 600 MHz all the time (while /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq is telling you at the same time the CPU would run at 1200 MHz! Raspberries cheat on you when powering goes wrong) and the Vcore voltage also remains at 1.2V all the time. That's the result of the 'firmware' detecting huge voltage drops and therefore lowering clockspeeds and voltage everywhere:

      Source Code

      1. root@raspberrypi:~# minerd --benchmark 2>&1 | grep Total
      2. [2017-07-14 14:38:16] Total: 2.43 khash/s
      3. [2017-07-14 14:38:21] Total: 2.44 khash/s
      4. [2017-07-14 14:38:26] Total: 2.44 khash/s
      5. [2017-07-14 14:38:31] Total: 2.45 khash/s
      6. [2017-07-14 14:38:36] Total: 2.41 khash/s
      7. ^C
      8. root@raspberrypi:~# raspimon
      9. To stop simply press [ctrl]-[c]
      10. 49.4'C 1200/ 600 MHz 1010000000000000101 1.2V
      11. 48.9'C 600/ 600 MHz 1010000000000000000 1.2V
      12. 50.5'C 1200/ 600 MHz 1010000000000000101 1.2V
      13. 53.7'C 1200/ 600 MHz 1010000000000000101 1.2V
      14. 55.8'C 1200/ 600 MHz 1010000000000000101 1.2V
      15. 55.8'C 1200/ 600 MHz 1010000000000000101 1.2V
      16. 56.9'C 1200/ 600 MHz 1010000000000000101 1.2V
      17. 58.0'C 1200/ 600 MHz 1010000000000000101 1.2V
      18. 58.0'C 1200/ 600 MHz 1010000000000000101 1.2V
      19. 53.7'C 600/ 600 MHz 1010000000000000000 1.2V
      20. ^C
      Display All


      The funny (or sad) part here is that you need tools like raspimon to get a clue what's going on since cpufreq drivers report wrong numbers while in reality the firmware chose to clock everything down to the minimum. If you operate your Raspberry with a connected display that's the yellow lightning bolt appearing in the upper right of the screen. But most OMV installations will run headless and the lightning bolt is just the equivalent to actual under-voltage happening. With raspimon and /var/log/raspihealth.log we have also the ability to detect these situations when they happened in the past between last reboot and now.
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • And a final one to close this chapter: With regard to overheating / thermal problems raspimon can also help since unfortunately on RPi 2 and 3 /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq is again not telling the truth once throttling occurs: On both RPi 2 and 3 the highest allowed clock speed will be shown under load (900 MHz by default on RPi 2, 1200 MHz on RPi 3) while in reality the real clockspeed is already lower once the throttling treshold is exceeded (80°C by default).

      I let cpuminer ran a few minutes and the 4.6 khash/s turned into just 3 khash/s after 5 minutes since the Pi got hotter and hotter and therefore the firmware lowered the real clockspeed constantly once the 80°C have been exceeded:

      Source Code

      1. root@raspberrypi:~# minerd --benchmark root@raspberrypi:~# raspimon
      2. [2017-07-14 15:07:34] Total: 4.59 khash/s To stop simply press [ctrl]-[c]
      3. [2017-07-14 15:07:39] Total: 4.67 khash/s
      4. [2017-07-14 15:07:44] Total: 4.52 khash/s 57.3'C 1200 MHz 0000000000000000000 1.3188V
      5. [2017-07-14 15:07:49] Total: 4.59 khash/s 63.4'C 1200 MHz 0000000000000000000 1.3188V
      6. [2017-07-14 15:07:54] Total: 4.65 khash/s 65.5'C 1200 MHz 0000000000000000000 1.3188V
      7. [2017-07-14 15:07:59] Total: 4.65 khash/s 67.7'C 1200 MHz 0000000000000000000 1.3188V
      8. [2017-07-14 15:08:04] Total: 4.53 khash/s 70.9'C 1200 MHz 0000000000000000000 1.3188V
      9. [2017-07-14 15:08:09] Total: 4.63 khash/s 72.0'C 1200 MHz 0000000000000000000 1.3188V
      10. [2017-07-14 15:08:14] Total: 4.66 khash/s 73.1'C 1200 MHz 0000000000000000000 1.3188V
      11. [2017-07-14 15:08:19] Total: 4.65 khash/s 74.1'C 1200 MHz 0000000000000000000 1.3188V
      12. [2017-07-14 15:08:24] Total: 4.66 khash/s 75.2'C 1200 MHz 0000000000000000000 1.3188V
      13. [2017-07-14 15:08:29] Total: 4.65 khash/s 76.8'C 1200 MHz 0000000000000000000 1.3188V
      14. [2017-07-14 15:08:34] Total: 4.55 khash/s 78.4'C 1200 MHz 0000000000000000000 1.3188V
      15. [2017-07-14 15:08:39] Total: 4.51 khash/s 79.5'C 1200 MHz 0000000000000000000 1.3188V
      16. [2017-07-14 15:08:45] Total: 4.26 khash/s 80.6'C 1200/1149 MHz 0100000000000000010 1.3188V
      17. [2017-07-14 15:08:49] Total: 4.17 khash/s 81.1'C 1200/1074 MHz 0100000000000000010 1.3188V
      18. [2017-07-14 15:08:54] Total: 4.05 khash/s 81.7'C 1200/1021 MHz 0100000000000000010 1.3188V
      19. [2017-07-14 15:08:59] Total: 3.97 khash/s 81.7'C 1200/1009 MHz 0100000000000000010 1.3188V
      20. [2017-07-14 15:09:04] Total: 3.67 khash/s 82.7'C 1200/ 981 MHz 0100000000000000010 1.3188V
      21. [2017-07-14 15:09:09] Total: 3.71 khash/s 82.7'C 1200/ 952 MHz 0100000000000000010 1.3188V
      22. [2017-07-14 15:09:14] Total: 3.73 khash/s 82.7'C 1200/ 940 MHz 0100000000000000010 1.3188V
      23. [2017-07-14 15:09:19] Total: 3.64 khash/s 82.7'C 1200/ 918 MHz 0100000000000000010 1.3188V
      24. [2017-07-14 15:09:24] Total: 3.57 khash/s 82.7'C 1200/ 895 MHz 0100000000000000010 1.3188V
      25. [2017-07-14 15:09:30] Total: 3.51 khash/s 83.8'C 1200/ 888 MHz 0100000000000000010 1.3188V
      26. [2017-07-14 15:09:34] Total: 3.49 khash/s 83.8'C 1200/ 878 MHz 0100000000000000010 1.3188V
      27. [2017-07-14 15:09:39] Total: 3.38 khash/s 83.8'C 1200/ 848 MHz 0100000000000000010 1.3188V
      28. [2017-07-14 15:09:44] Total: 3.39 khash/s 83.8'C 1200/ 848 MHz 0100000000000000010 1.3188V
      29. [2017-07-14 15:09:49] Total: 3.39 khash/s 83.8'C 1200/ 834 MHz 0100000000000000010 1.3188V
      30. [2017-07-14 15:09:54] Total: 3.35 khash/s 83.8'C 1200/ 824 MHz 0100000000000000010 1.3188V
      31. [2017-07-14 15:09:59] Total: 3.35 khash/s 83.8'C 1200/ 827 MHz 0100000000000000010 1.3188V
      32. [2017-07-14 15:10:04] Total: 3.32 khash/s 83.8'C 1200/ 819 MHz 0100000000000000010 1.3188V
      33. [2017-07-14 15:10:09] Total: 3.26 khash/s 83.8'C 1200/ 812 MHz 0100000000000000010 1.3188V
      34. [2017-07-14 15:10:14] Total: 3.21 khash/s 83.8'C 1200/ 806 MHz 0100000000000000010 1.3188V
      35. [2017-07-14 15:10:19] Total: 3.26 khash/s 83.8'C 1200/ 803 MHz 0100000000000000010 1.3188V
      36. [2017-07-14 15:10:24] Total: 3.24 khash/s 83.8'C 1200/ 807 MHz 0100000000000000010 1.3188V
      37. [2017-07-14 15:10:29] Total: 3.22 khash/s 83.8'C 1200/ 810 MHz 0100000000000000010 1.3188V
      38. [2017-07-14 15:10:34] Total: 3.16 khash/s 83.8'C 1200/ 793 MHz 0100000000000000010 1.3188V
      39. [2017-07-14 15:10:39] Total: 3.08 khash/s 84.4'C 1200/ 777 MHz 0100000000000000010 1.3188V
      40. [2017-07-14 15:10:44] Total: 3.14 khash/s 84.4'C 1200/ 776 MHz 0100000000000000010 1.3188V
      41. [2017-07-14 15:10:49] Total: 3.12 khash/s 84.9'C 1200/ 796 MHz 0100000000000000010 1.3188V
      42. [2017-07-14 15:10:54] Total: 3.11 khash/s 83.8'C 1200/ 766 MHz 0100000000000000010 1.3188V
      43. [2017-07-14 15:10:59] Total: 3.08 khash/s 84.4'C 1200/ 770 MHz 0100000000000000010 1.3188V
      44. [2017-07-14 15:11:04] Total: 3.07 khash/s 84.4'C 1200/ 751 MHz 0100000000000000010 1.3188V
      45. [2017-07-14 15:11:09] Total: 2.98 khash/s 84.4'C 1200/ 756 MHz 0100000000000000010 1.3188V
      46. [2017-07-14 15:11:14] Total: 3.08 khash/s 84.4'C 1200/ 758 MHz 0100000000000000010 1.3188V
      47. [2017-07-14 15:11:19] Total: 3.08 khash/s 84.4'C 1200/ 769 MHz 0100000000000000010 1.3188V
      48. [2017-07-14 15:11:24] Total: 3.07 khash/s 84.4'C 1200/ 761 MHz 0100000000000000010 1.3188V
      49. [2017-07-14 15:11:29] Total: 3.07 khash/s 83.8'C 1200/ 754 MHz 0100000000000000010 1.3188V
      50. [2017-07-14 15:11:34] Total: 3.05 khash/s 83.8'C 1200/ 750 MHz 0100000000000000010 1.3188V
      51. [2017-07-14 15:11:40] Total: 2.92 khash/s 83.8'C 1200/ 741 MHz 0100000000000000010 1.3188V
      52. [2017-07-14 15:11:43] Total: 3.00 khash/s 84.9'C 1200/ 751 MHz 0100000000000000010 1.3188V
      53. [2017-07-14 15:11:44] Total: 3.06 khash/s 84.9'C 1200/ 731 MHz 0100000000000000010 1.3188V
      54. [2017-07-14 15:11:49] Total: 3.06 khash/s 84.4'C 1200/ 739 MHz 0100000000000000010 1.3188V
      55. [2017-07-14 15:11:54] Total: 3.04 khash/s 84.4'C 1200/ 751 MHz 0100000000000000010 1.3188V
      56. [2017-07-14 15:11:59] Total: 3.04 khash/s 84.4'C 1200/ 739 MHz 0100000000000000010 1.3188V
      57. [2017-07-14 15:12:05] Total: 3.00 khash/s 84.9'C 1200/ 728 MHz 0100000000000000010 1.3188V
      58. [2017-07-14 15:12:08] Total: 3.00 khash/s 84.4'C 1200/ 739 MHz 0100000000000000010 1.3188V
      59. [2017-07-14 15:12:10] Total: 2.88 khash/s 84.4'C 1200/ 747 MHz 0100000000000000010 1.3188V
      60. ^C ^C
      Display All
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • And another small update, this time wrt Wi-Fi. Since we're running an Armbian userland we can make also use of some Armbian functionality. Since I have a few wireless IoT sensors here (OPi Zero and NanoPi Air) I wanted to setup an own 'IoT Wi-Fi' truly separated from my normal Wi-Fi.

      One single step needed on a RPi 3: 'sudo armbian-config' --> Hotspot --> NAT (you could also choose 'Bridge' instead but I wanted NAT by intention)

      Everything else happens in the background (installing and setting up dnsmasq and routing/filtering) and afterwards there's a new wireless network called 'ARMBIAN' with default passphrase '12345678' on channel 5 available (you need to change this immediately in /etc/hostapd.conf of course).


      On my RPi 2 I tested the same with two dual-band/dual-antenna Wi-Fi sticks. The cheap one based on Ralink RT5572 worked out of the box (driver and firmware included), the more expensive one featuring RTL8812AU (802.11ac) needed an out of tree driver I chose to install via DKMS:
      Please note that for powerful wireless dongles you need a stable 5V/2A power source that does not suffer from voltage drops and you have to define 'max_usb_current=1' in /boot/config.txt to allow 1200mA available at the USB ports and not just the default 600mA (all USB ports share this limit!)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • @tkaiser, as always, great work. Thanks for doing this even though I know you are not a fan of the RPi. I'll buy you a beer sometime :)

      Just tested the new image and it works (and upgrades) fine. I didn't run into any issues. Uploading to sourceforge now.
      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!
    • ryecoaaron wrote:

      Thanks for doing this even though I know you are not a fan of the RPi
      Raspberries are great devices for certain use cases (just not NAS/OMV ;) ) but since we were able to identify/develop a lot of useful OMV/ARM tweaks the last months and we could rely on an automated build by using Armbian it was not that much of an effort to make this useable on Raspberries too.

      To be honest: most of my time spent on this RPi image was related to under-voltage detection/reporting since this is something almost every RPi user is affected from but nobody notices especially on headless Raspberries (since the 'firmware' does such a great job hiding the problem). So I hope awareness is slowly rising and people check /var/log/raspihealth.log and raspimon output if running in troubles or their setup performing extremely poor.

      Anyway: abandoning Raspbian and switching to true Debian should help with support issues (avoiding dependency issues) and using the same base as with all other ARM boards should help also with performance (as already said: not that important on Raspberries since here the main bottleneck is the single USB2 bottleneck between SoC and the outside and everything having to share bandwidth)

      I downloaded the archive from SF, uncompressed it and can confirm MD5 hash of uncompressed image is correct: 4adfa95b7bfbf08049176df358abc4ac :)

      And a final note: The RPi image will install three packages from archive.raspberrypi.org/debian/ on first boot: raspberrypi-bootloader, libraspberrypi-bin and raspberrypi-kernel. This is a lot of stress for the SD card and might take some time so there's some patience needed until the RPi reboots and can be used afterwards. If users try this with really crappy, broken or counterfeit SD cards most probably OMV won't start after the reboot since filesystem is already corrupted. This will save these users a lot of time they would otherwise waste with installing OMV again and again. Just to keep in mind for support questions: if it doesn't work at all then most probably it's the SD card that needs to be replaced (some recommendations).
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • Hey,
      I can confirm RPi 2 is ok with this new image.
      After 1st automatic reboot, date/time set up with the OMV webgui, then system update with "update management" menu, success. Rename the machine raspberrypi > newname + domain.lan
      Changing root password with : passwd root
      Reboot.

      But :
      1. where is /dev/mmcblk0p3 ? "fdisk -l" showing those 3 partitions on sdcard... no problem. But webgui doesn't showing, so there's no way to use it as storage.
      2. previous webgui size was smaller, it was easiest to read more informations on the webpage (not very important ;p only my opinion !)

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

    • petrus wrote:

      previous webgui size was smaller, it was easiest to read more informations on the webpage
      It is a new theme. There is a way to switch to the old theme - read
      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!

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

    • petrus wrote:

      where is /dev/mmcblk0p3
      Quoting the readme.txt on Sourceforge download page: 'A third partition for data use will be automatically resized on first boot but you have to format it manually with the fs of your choice!' and quoting first post above:
      • The image resizes the rootfs automagically to ~3.7GB on first boot and creates a 3rd partition using the remaining space of the SD card you need to initialize manually if you want to use it for OMV shares ('mkfs.ext4|mkfs.btrfs /dev/mmcblk0p3')
      So yes, it requires manual interaction and a decision: not using remaining space is a valid option since it increases longevity of your SD card. A lot of users fear SD cards wearing out too fast and this is one of the strategies to fight this.

      Since we're talking about running this image now with at least kernel 4.9 using btrfs (with transparent file compression) is possible so I thought it would be a better idea to encourage users to think what to do with the 3rd partition. Eg. mounting it as /var/log with btrfs and compress-force=zlib logfiles 40GB in size will fit easily on a 4 GB partition.

      Out of curiousity: Can you please provide output from 'sudo armbianmonitor -u' please after checking the debug info yourself (stuff like IP addresses should already be somewhat obfuscated).
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • About partitions :
      with ssh, as root :
      mkfs.ext4 /dev/mmcblk0p3
      reboot

      If you want to check :
      Tuned /etc/fstab (before using 3rd partition) as described on the documentation, final result (after adding 3rd part°) is :

      # cat /etc/fstab
      proc /proc proc defaults 0 0
      /dev/mmcblk0p1 /boot vfat defaults 0 2
      /dev/mmcblk0p2 / ext4 defaults,noatime,nodiratime 0 1
      #/var/swap none swap sw 0 0
      tmpfs /tmp tmpfs defaults 0 0
      # >>> [openmediavault]
      /dev/disk/by-id/mmc-SD16G_0xda76ad94-part3 /srv/dev-disk-by-id-mmc-SD16G_0xda76ad94-part3 ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,discard,acl 0 2
      # <<< [openmediavault]

      ~# df -h
      Filesystem Size Used Avail Use% Mounted on
      /dev/root 3.6G 1.5G 1.9G 44% /
      devtmpfs 481M 0 481M 0% /dev
      tmpfs 486M 0 486M 0% /dev/shm
      tmpfs 486M 6.9M 479M 2% /run
      tmpfs 5.0M 0 5.0M 0% /run/lock
      tmpfs 486M 0 486M 0% /sys/fs/cgroup
      tmpfs 486M 0 486M 0% /tmp
      /dev/mmcblk0p1 63M 26M 37M 41% /boot
      folder2ram 486M 3.7M 482M 1% /var/log
      folder2ram 486M 0 486M 0% /var/tmp
      folder2ram 486M 416K 486M 1% /var/lib/openmediavault/rrd
      folder2ram 486M 1.2M 485M 1% /var/spool
      folder2ram 486M 9.8M 476M 3% /var/lib/rrdcached
      folder2ram 486M 8.0K 486M 1% /var/lib/monit
      folder2ram 486M 4.0K 486M 1% /var/lib/php5
      folder2ram 486M 0 486M 0% /var/lib/netatalk/CNID
      tmpfs 98M 0 98M 0% /run/user/0
      /dev/mmcblk0p3 11G 41M 9.9G 1% /srv/dev-disk-by-id-mmc-SD16G_0xda76ad94-part3
    • petrus wrote:

      command "armbianmonitor -u" result
      sprunge.us/WWVd
      Thank you!

      For you and other users/mods wanting to understand how to deal with this debug output: The first thing I always do is searching for '### Installed packages:' at the bottom of the log. This lists all installed OMV packages, below starting with '### Current sysinfo:' the avg-cpu values shows what the CPU has done since last reboot (unusual high %iowait values always indicate a problem, eg. an SD card dying) and further below there's swap/memory information and finally last 250 lines of most recent dmesg output.

      If we scroll in the other direction starting from '### Installed packages:' we get IRQ affinity (not worth a look on Raspberries since most IRQs will be spent on the single USB2 port anyway), then there's 'df -h' output as well as /proc/partitions and some information that usually should help nailing down most problems pretty fast. Normally only the bottom part of this log is interesting. A logrotate rule is configured so to get really old info one has to check archived logs: /var/log/armhwinfo.log.*
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • jata1 wrote:

      massive thanks from me. The new image/approach is really great and working well.
      You're welcome and many thanks for you continually reporting issues (even 'cosmetic' ones) since this helped improving user experience with the new RPi OMV image a lot.


      jata1 wrote:

      when can you do the same for my crappy Banana Pi M2U?
      Never. Same with any other more recent Banana crap like the 'Raspberry Pi 3 killer' (LOL!) called 'M2 Berry'. References:
      I've never had to deal again with a SBC vendor behaving that ignorant/stupid (they even refuse to fix security or instability issues they get for free from community as pull requests on github which would take them just seconds, that's just INSANE!). Will never waste time with any of their boards again since they proofed that they're not able or willing to improve. They still fail the same way they failed 2.5 years ago but in the meantime they even improved in failing and now behave just like brain damaged retards also deleting/censoring posts in their own forum that could help their users and them to understand issues. It's a shame.

      BTW: NAS performance of these Banana thingies is higher than Raspberry's but still crappy even with 'native SATA': forum.armbian.com/index.php?/t…findComment&comment=34192
      '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 ().

    • hahaha. I know. The banana pi people are a joke. Totally poor support and generally incompetent.

      The community is ok though. I have managed to update the kernel to 3.10.107, fix the memory issues causing instability and have installed OMV. It seems to be running OK but i'm not prepared to use it instead of my RPi.

      I bought the banana pi from Aliexpress so it was cheap. Tried to return it but BPI people (vendor on Aliexpress) refused to accept the return but that's another story.

      I think my next purchase will be a Rock64. They look good as a low cost NAS (USB3 + Gbit network).

      All the best and thanks again.
    • jata1 wrote:

      The banana pi people are a joke. Totally poor support and generally incompetent.

      The community is ok though.
      forum.banana-pi.org/t/banana-p…-bpi-m2u-sd-emmc-img/3306

      If the 'jata' account belongs to you then I tried to help you over there in the past already (me being the @charles guy -- as soon as the 'sinovoip team bpi' guy realized that 'charles' is 'tkaiser' he started to immediately ban my account as usual and deleted over 50 of my posts, see the beginning of the comment thread where @jata seems to talk to himself).

      I also helped @facat to solve the instability problems and so on. @Tido and me didn't gave up on this weird company for over two years fighting against their ignorance/stupidity but since the Banana CEO officially announced they're happy with behaving like brain damaged retards it's ok now. No one can help them.
      '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:

      ryecoaaron wrote:

      Thanks for doing this even though I know you are not a fan of the RPi
      Raspberries are great devices for certain use cases (just not NAS/OMV ;) )
      I certainly appreciate both your tech ability and the effort you've invested in this. But I'd respectfully disagree with you on using an R-PI as a NAS. To define a use case, one would have to define what a NAS is. In my opinion (and those of who defined the acronym) the traditional NAS is Network Attached Storage. Nothing more. It's it's purest form, a NAS is not a media streamer / transcoder, down loader, a domain controller, a server hosting user home folders, etc., etc.

      I use an R-PI as a NAS. My R-PI (ver2) has been Rsync'ing shares from my main server with reliability, if one discounts the occasional "crappy" SD card event. They seem more than capable of moving files around. However, after a couple years of experience with running the R-PI, I'm forced to agreed with your take on SD Card "crappiness".
      (While I have plenty of SD card clones, I need to upgrade to name brand cards to see if that measurably improves media reliability.)

      Regardless of use cases, opinions, etc.,:
      Since the R-PI is a integral part of my server backup strategy, I sincerely appreciate your efforts in developing OMV to run on R-PI's.

      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:

      To define a use case, one would have to define what a NAS is. In my opinion (and those of who defined the acronym) the traditional NAS is Network Attached Storage
      Exactly. NAS is Network Attached Storage by definition. Using a Raspberry for this is also defined as ISNAS (Insanely Slow Network Attached Storage). That's the point: Raspberries are bottlenecked by their single USB2 connection to the outside and everything having to share bandwidth. If you've already lying a RPi around of course you can make a dog slow NAS out of it. But if you're thinking about buying an inexpensive and energy efficient ARM device to be used as NAS NEVER choose a Raspberry since it's always the worst choice possible.

      A lot of performance numbers can be found over at Armbian forum where the journey started to provide new, performant, stable and unified OMV images for ARM devices: forum.armbian.com/index.php?/t…ges-for-sbc-with-armbian/

      Even a $7 Orange Pi Zero or a $10 NanoPi NEO is able to outperform any Raspberry Pi. But as already said: If the device is already there just use it as (very slow) NAS. But don't think about Raspberries if you want to buy something new to be used with OMV.

      BTW: Raspberries are really great due to the large community around. Even Raspberry Pi used as DAS (Directly Attached Storage) for other vintage hardware is possible in the meantime: geocities.jp/kugimoto0715/rascsi/

      That being said and still speaking about 'vintage': Raspberry Pi featuring only Fast Ethernet (sharing bandwidth with all other USB devices!) is stepping back two decades ago if it's about performance. See below for some anecdotical stuff when Fast Ethernet was 'new' back then.

      But it's 2017 now. When we want to use energy efficient and inexpensive NAS devices these days there are a lot of options. Gigabit Ethernet SBC start at around $15-$20 w/o shipping/VAT/customs (NanoPi NEO 2 or Orange Pi PC 2), we can choose ARM boards that perform just like x86 NAS when we want to rely on USB3 (starting at $25 in ROCK64's case again w/o shipping/VAT/customs) and with reliable storage connections and same high NAS performance we're talking about 50 bucks (see ESPRESSOBin which will soon be fully supported by OMV).

      TL;DR: Using a RPi 2 or 3 as OMV device is ok if you neither care about performance nor reliability. In the meantime there are a lot of other energy efficient and inexpensive ARM devices around that are way more suitable for OMV. But if you want your Raspberry Pi serving as NAS please feel welcomed, use our latest OMV image and check both /var/log/raspihealth.log and /usr/sbin/raspimon output if problems occur or you think your RPi behaves too slow.
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • Users Online 1

      1 Guest