New approach for Raspberry Pi OMV images

    • tkaiser wrote:

      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.
      Since I'm running a core i3 along side of an R-PI 2, with both running OMV, I do have a rough idea of the difference in performance. Still, for the purpose of backing up the i3's files (where the Pi's slowness has no user impact at all), the R-PI is doing fine. At just a bit over $150 for 4TB of backup storage, at around 12 AC watts, it's a bargain for that purpose.

      However, the "dog slow" comment was way out of line. My dog, who can run down a rabbit, wouldn't appreciate it....
      (Just kidding! :D )

      Seriously, as long as you're willing to produce quality R-PI images (complete with integrated diagnostics - very nice, BTW - thanks for that), I think you'll find that the R-PI community will appreciate your good work. I do and I'll be looking forward to your notes on R-PI's and any new images you may have to offer.
      Good backup takes the "drama" out of computing
      ____________________________________
      OMV 3.0.81 Erasmus
      ThinkServer TS140, 12GB ECC /
      32GB USB3.0 / 4TB SG / 1TB WD

      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
    • Small performance update: From time to time some people try to convince me that using DietPi is the way to go at least with Raspberries since 'diet, lightweight, fast, optimized, $insert-your-favourite-marketing-BS-here'. Since my work with ARM devices the last years was concentrated on low-level stuff like optimized settings (both consumption and performance), kernel (again settings and security) and security in general and I see not a single of these aspects covered by DietPi I'm somewhat skeptical.

      The results of my DietPi tests in the past weren't that great (tried it first on an Orange Pi PC and there DietPi performance was disastrous due to stupid thermal/dvfs settings) but since someone told me DietPi would be magic also for NAS use cases and I had my RPi 3 running today to test through other stuff I simply tried it out.

      This time only installing Samba since I found no 'convenient' way to install Netatalk within DietPi (the whole purpose of this distro is to guide clueless people with menu driven tools so I didn't want to mess with 'apt install' or anything else everyone able to read is able to execute). Default settings used with both DietPi and OMV. Also same SD card, same 2.5" HDD in same enclosure, same RPi 3 with same PSU and USB cable.

      DietPi first (based on Raspbian, ARMv6 packages, obviously no tweaks like IO optimized ondemand cpufreq governor settings, no IO scheduler class/priority tweaking, most probably also no IO scheduler optimizations):

      Now OMV (based on Armbian, ARMv7 packages, Armbian tunables set and the additional tweaks we developed within the last 4 months over there):

      As expected settings matter. I also tried quickly 'Lightweight justice for your Odroid' (WTF? Justice?) that means DietPi for ODROID-XU4, again wasted a few minutes with DietPi's countless reboots and nag screens, let Samba install and fired up a quick LanTest. Pulled the plug when seeing 53MB/s sequential write. No thanks, I think I'll still prefer distros/images that take care of kernel and settings and will stay away from marketing BS like 'diet', 'lightweight' and so on... settings matter. It's really that easy.
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • Little security advisory. According to RPi-Foundation the Broadcom wireless chip contained in RPi 3 and Zero W is affected by the so called 'BroadPwn'' flaw (please google yourself). Cypress (formerly Broadcom) provided an updated firmware which is part of Raspbian's latest firmware-brcm80211 package which gets automatically updated on Raspbian based OMV images.

      It's really just two simple files replaced (a .txt and a .bin blob). If you're affected by BroadPwn on your Raspberry it's this:

      Source Code

      1. root@raspberrypi:~# md5sum /lib/firmware/brcm/brcmfmac43430-sdio.*
      2. 9258986488eca9fe5343b0d6fe040f8e /lib/firmware/brcm/brcmfmac43430-sdio.bin
      3. 8c3cb6d8f0609b43f09d083b4006ec5a /lib/firmware/brcm/brcmfmac43430-sdio.txt
      4. root@raspberrypi:~# dmesg | grep brcm
      5. [ 3.063731] usbcore: registered new interface driver brcmfmac
      6. [ 3.261842] brcmfmac: Firmware version = wl0: Aug 29 2016 20:48:16 version 7.45.41.26 (r640327) FWID 01-4527cfab
      7. [ 9.624987] brcmfmac: power management disabled
      If you have the fix it looks like this:

      Source Code

      1. root@raspberrypi:~# md5sum /lib/firmware/brcm/brcmfmac43430-sdio.*
      2. 5f520a38ab4e943bfa1ba102f80fb2a0 /lib/firmware/brcm/brcmfmac43430-sdio.bin
      3. 9a88b55134d9f8f3ad2331b93f4b7b79 /lib/firmware/brcm/brcmfmac43430-sdio.txt
      4. root@raspberrypi:~# dmesg | grep brcm
      5. [ 3.079435] usbcore: registered new interface driver brcmfmac
      6. [ 3.242599] brcmfmac: Firmware version = wl0: Aug 7 2017 00:46:29 version 7.45.41.46 (r666254 CY) FWID 01-f8a78378
      7. [ 9.756847] brcmfmac: power management disabled
      Unfortunately on latest RPi OMV image /lib/firmware/brcm/brcmfmac43430-sdio.* is part of armbian-firmware package. So if Wi-Fi/BT is not needed a simple 'apt purge armbian-firmware' already fixes the problem. And doing an 'apt install firmware-brcm80211' makes Wi-Fi usable again with fix included. But it's important to fetch the package from archive.raspberrypi.org and not from upstream Debian repositories since there it's still the old firmware from 2016. On most recent RPi OMV image an 'apt list -a firmware-brcm80211' shows these 3 packages available:


      Source Code

      1. firmware-brcm80211/now 1:0.43+rpi6 all [installed]
      2. firmware-brcm80211/jessie-backports 20161130-3~bpo8+1 all
      3. firmware-brcm80211/oldstable 0.43 all
      Next problem: Kernel updates. The kernel we get with current apt source configuration is still 4.9.35 while when switching to stretch sources we would get 4.9.41 'already' (4.9.47 is latest 4.9LTS release but hey...):

      Source Code

      1. root@raspberrypi:~# grep -v '#' /etc/apt/sources.list.d/raspberry.list
      2. deb https://archive.raspberrypi.org/debian/ jessie main
      By switching the archive.raspberrypi.org repo to stretch we're able to fetch latest RPi kernel update:

      Source Code

      1. sed -i 's/jessie/stretch/' /etc/apt/sources.list.d/raspberry.list
      2. apt update
      3. apt install firmware-brcm80211 libraspberrypi-bin libraspberrypi0 raspberrypi-bootloader raspberrypi-kernel
      4. reboot
      And now we're at 'Linux raspberrypi 4.9.41-v7+ #1023 SMP Tue Aug 8 16:00:15 BST 2017 armv7l GNU/Linux'. But now also a lot of other packages are upgradeable:


      Source Code

      1. root@raspberrypi:~# apt list --upgradable
      2. Listing... Done
      3. device-tree-compiler/testing 1.4.4-1 armhf [upgradable from: 1.4.1-1+rpi1]
      4. e2fslibs/jessie-backports 1.43.3-1~bpo8+1 armhf [upgradable from: 1.43.3-1~bpo8+1]
      5. e2fsprogs/jessie-backports 1.43.3-1~bpo8+1 armhf [upgradable from: 1.43.3-1~bpo8+1]
      6. libcairo2/testing 1.14.8-1+rpi1 armhf [upgradable from: 1.14.0-2.1+deb8u2+rpi1]
      7. libcomerr2/jessie-backports 1.43.3-1~bpo8+1 armhf [upgradable from: 1.43.3-1~bpo8+1]
      8. libpam-modules/testing 1.1.8-3.6+rpi1 armhf [upgradable from: 1.1.8-3.1+deb8u2+rpi3]
      9. libpam-modules-bin/testing 1.1.8-3.6+rpi1 armhf [upgradable from: 1.1.8-3.1+deb8u2+rpi3]
      10. libpam-runtime/testing 1.1.8-3.6+rpi1 all [upgradable from: 1.1.8-3.1+deb8u2+rpi3]
      11. libpam0g/testing 1.1.8-3.6+rpi1 armhf [upgradable from: 1.1.8-3.1+deb8u2+rpi3]
      12. libss2/jessie-backports 1.43.3-1~bpo8+1 armhf [upgradable from: 1.43.3-1~bpo8+1]
      Display All
      And if we would start an upgrade now we get a 'nice' mixture of Raspbian and Debian armhf packages:


      Source Code

      1. Get:1 https://archive.raspberrypi.org/debian/ stretch/main libpam0g armhf 1.1.8-3.6+rpi1 [120 kB]
      2. Get:2 http://httpredir.debian.org/debian/ jessie-backports/main e2fsprogs armhf 1.43.3-1~bpo8+1 [907 kB]
      3. Get:3 http://httpredir.debian.org/debian/ jessie-backports/main e2fslibs armhf 1.43.3-1~bpo8+1 [199 kB]
      4. Get:4 https://archive.raspberrypi.org/debian/ stretch/main libpam-modules-bin armhf 1.1.8-3.6+rpi1 [102 kB]
      5. Get:5 http://httpredir.debian.org/debian/ jessie-backports/main libcomerr2 armhf 1.43.3-1~bpo8+1 [62.5 kB]
      6. Get:6 http://httpredir.debian.org/debian/ jessie-backports/main libss2 armhf 1.43.3-1~bpo8+1 [66.0 kB]
      7. Get:7 https://archive.raspberrypi.org/debian/ stretch/main libpam-modules armhf 1.1.8-3.6+rpi1 [289 kB]
      8. Get:8 https://archive.raspberrypi.org/debian/ stretch/main libpam-runtime all 1.1.8-3.6+rpi1 [212 kB]
      9. Get:9 https://archive.raspberrypi.org/debian/ stretch/main device-tree-compiler armhf 1.4.4-1 [349 kB]
      The OS survived a reboot but this is clearly something we want to avoid.


      Since I lack sufficient experiences with apt pinning may I ask more advanced users here (hoping for @ryecoaaron ;) :( How could we deal with this situation to ensure that we'll get in active OMV installations latest kernel/firmware updates from upstream archive.raspberrypi.org repo? Is it possible to switch this repo to stretch but only allow these five packages to be installed/upgraded from there?

      Source Code

      1. firmware-brcm80211 libraspberrypi-bin libraspberrypi0 raspberrypi-bootloader raspberrypi-kernel
      '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 wrote:

      Is it possible to switch this repo to stretch but only allow these five packages to be installed/upgraded from there?
      The raspberry pi repo needs to be in a sources.list.d/whatever file and should be able to create a pin file like:


      Shell-Script

      1. cat <<EOF > /etc/apt/preferences.d/99raspberrypiorg
      2. Package: firmware-brcm80211 libraspberrypi-bin libraspberrypi0 raspberrypi-bootloader raspberrypi-kernel
      3. Pin: release a=stretch, origin archive.raspberrypi.org
      4. Pin-Priority: 1000
      5. EOF
      It is possible that we may have to pin the packages with the same name in a different repo with a lower priority but I doubt it.
      omv 4.0.5 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.0.2
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • Thank you. Added the file, did an 'apt update', get one package as update candidate and it looks like this:

      Source Code

      1. root@raspberrypi:~# apt list -a libcairo2
      2. Listing... Done
      3. libcairo2/testing 1.14.8-1+rpi1 armhf [upgradable from: 1.14.0-2.1+deb8u2+rpi1]
      4. libcairo2/now 1.14.0-2.1+deb8u2+rpi1 armhf [installed,upgradable to: 1.14.8-1+rpi1]
      5. libcairo2/oldstable 1.14.0-2.1+deb8u2 armhf
      Which is wrong anyway since on a 'pure Debian armhf' installation it should be '1.14.0-2.1+deb8u2 armhf [installed,automatic]' instead (just checked on a Banana Pi where it's exactly like this).

      So this image is already in a mixed state :\

      Here's /var/log/dpkg.log: sprunge.us/SRCB

      At '2017-09-08 02:13:15' a few packages are installed as part of 'firstrun' procedure. But then later the first plain Debian armhf packages get replaced by their Raspbian/Jessie variants:

      Source Code

      1. 2017-09-08 11:31:51 upgrade libpam0g:armhf 1.1.8-3.1+deb8u2 1.1.8-3.1+deb8u2+rpi3
      2. 2017-09-08 11:31:53 upgrade libpam-modules-bin:armhf 1.1.8-3.1+deb8u2 1.1.8-3.1+deb8u2+rpi3
      3. 2017-09-08 11:31:55 upgrade libpam-modules:armhf 1.1.8-3.1+deb8u2 1.1.8-3.1+deb8u2+rpi3
      4. 2017-09-08 11:32:08 upgrade libfreetype6:armhf 2.5.2-3+deb8u2 2.6-2rpi1rpi1g
      5. 2017-09-08 11:32:13 upgrade libpixman-1-0:armhf 0.32.6-3 0.33.3+git20151011-7de61d8-rpi1
      6. 2017-09-08 11:32:26 upgrade libpam-runtime:all 1.1.8-3.1+deb8u2 1.1.8-3.1+deb8u2+rpi3
      7. 2017-09-08 11:32:42 upgrade libcairo2:armhf 1.14.0-2.1+deb8u2 1.14.0-2.1+deb8u2+rpi1
      8. 2017-09-08 11:32:50 upgrade device-tree-compiler:armhf 1.4.0+dfsg-1 1.4.1-1+rpi1
      I'm somewhat surprised that this works at all :)


      But it seems it's time for a strategy to prevent these things happen and obviously a new RPi image too...
      '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 wrote:

      Which is wrong anyway since on a 'pure Debian armhf' installation it should be '1.14.0-2.1+deb8u2 armhf [installed,automatic]' instead (just checked on a Banana Pi where it's exactly like this).
      The rpi repo must be pinned higher than the debian repo. What is the output of: apt-cache policy libcairo2
      omv 4.0.5 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.0.2
      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:

      What is the output of: apt-cache policy libcairo2
      Currently with Raspbian stretch repo active:

      Source Code

      1. root@raspberrypi:~# apt-cache policy libcairo2
      2. libcairo2:
      3. Installed: 1.14.0-2.1+deb8u2+rpi1
      4. Candidate: 1.14.8-1+rpi1
      5. Version table:
      6. 1.14.8-1+rpi1 0
      7. 500 https://archive.raspberrypi.org/debian/ stretch/main armhf Packages
      8. *** 1.14.0-2.1+deb8u2+rpi1 0
      9. 100 /var/lib/dpkg/status
      10. 1.14.0-2.1+deb8u2 0
      11. 500 http://httpredir.debian.org/debian/ jessie/main armhf Packages
      12. root@raspberrypi:~# grep -v '#' /etc/apt/sources.list.d/raspberry.list
      13. deb https://archive.raspberrypi.org/debian/ stretch main
      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.
    • tkaiser wrote:

      Currently with Raspbian stretch repo active:
      They are pinned the same. So, it will use the higher version in that case. If we change the pinning on one of the repos to be lower or higher, it should fix the problem. I believe we can do the following:

      Shell-Script

      1. cat <<EOF > /etc/apt/preferences.d/99raspberrypiorg
      2. Package: *
      3. Pin: release a=stretch, origin archive.raspberrypi.org
      4. Pin-Priority: 490
      5. Package: firmware-brcm80211 libraspberrypi-bin libraspberrypi0 raspberrypi-bootloader raspberrypi-kernel
      6. Pin: release a=stretch, origin archive.raspberrypi.org
      7. Pin-Priority: 1000
      8. EOF
      omv 4.0.5 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.0.2
      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:

      If we change the pinning on one of the repos to be lower or higher, it should fix the problem.
      Thank you. I gave it a try but had to release that I would need 'release n=' instead of 'release a='. But still to no avail:

      Source Code

      1. root@raspberrypi:~# cat /etc/apt/preferences.d/99raspberrypiorg
      2. Package: *
      3. Pin: release n=stretch, origin archive.raspberrypi.org
      4. Pin-Priority: 490
      5. Package: *
      6. Pin: release n=jessie, origin archive.raspberrypi.org
      7. Pin-Priority: 490
      8. Package: firmware-brcm80211 libraspberrypi-bin libraspberrypi0 raspberrypi-bootloader raspberrypi-kernel
      9. Pin: release n=stretch, origin archive.raspberrypi.org
      10. Pin-Priority: 1000
      11. root@raspberrypi:~# apt update
      12. Ign file: InRelease
      13. Ign file: Release.gpg
      14. Ign file: Release
      15. Ign file: Translation-en_US
      16. Ign file: Translation-en
      17. Ign file: Translation-en_US.UTF-8
      18. Hit http://security.debian.org jessie/updates InRelease
      19. Hit http://security.debian.org jessie/updates/main armhf Packages
      20. Hit http://security.debian.org jessie/updates/contrib armhf Packages
      21. Hit http://security.debian.org jessie/updates/non-free armhf Packages
      22. Hit http://security.debian.org jessie/updates/contrib Translation-en
      23. Hit http://security.debian.org jessie/updates/main Translation-en
      24. Hit https://openmediavault.github.io erasmus InRelease
      25. Ign http://httpredir.debian.org jessie InRelease
      26. Hit http://security.debian.org jessie/updates/non-free Translation-en
      27. Hit https://archive.raspberrypi.org stretch InRelease
      28. Hit https://openmediavault.github.io erasmus-proposed InRelease
      29. Get:1 https://dl.bintray.com jessie InRelease
      30. Ign https://dl.bintray.com jessie InRelease
      31. Hit http://httpredir.debian.org jessie-updates InRelease
      32. Hit https://openmediavault.github.io erasmus/main armhf Packages
      33. Hit https://dl.bintray.com jessie Release.gpg
      34. Get:2 https://openmediavault.github.io erasmus/main Translation-en_US [9,340 B]
      35. Hit http://httpredir.debian.org jessie-backports InRelease
      36. Hit https://dl.bintray.com jessie Release
      37. Get:3 https://openmediavault.github.io erasmus/main Translation-en [9,340 B]
      38. Get:4 https://openmediavault.github.io erasmus/main Translation-en_US.UTF-8 [9,340 B]
      39. Hit https://openmediavault.github.io erasmus-proposed/main armhf Packages
      40. Hit http://httpredir.debian.org jessie Release.gpg
      41. Get:5 https://openmediavault.github.io erasmus-proposed/main Translation-en_US [9,340 B]
      42. Hit https://archive.raspberrypi.org stretch/main armhf Packages
      43. Hit http://httpredir.debian.org jessie Release
      44. Get:6 https://openmediavault.github.io erasmus-proposed/main Translation-en [9,340 B]
      45. Get:7 https://openmediavault.github.io erasmus-proposed/main Translation-en_US.UTF-8 [9,340 B]
      46. Get:8 https://openmediavault.github.io erasmus/main Translation-en_US [9,340 B]
      47. Get:9 https://openmediavault.github.io erasmus/main Translation-en [9,340 B]
      48. Get:10 http://httpredir.debian.org jessie-updates/main armhf Packages/DiffIndex [8,392 B]
      49. Get:11 https://openmediavault.github.io erasmus/main Translation-en_US.UTF-8 [9,340 B]
      50. Get:12 https://openmediavault.github.io erasmus-proposed/main Translation-en_US [9,340 B]
      51. Hit http://httpredir.debian.org jessie-updates/contrib armhf Packages
      52. Get:13 https://archive.raspberrypi.org stretch/main Translation-en_US [339 B]
      53. Get:14 https://openmediavault.github.io erasmus-proposed/main Translation-en [9,340 B]
      54. Get:15 https://openmediavault.github.io erasmus-proposed/main Translation-en_US.UTF-8 [9,340 B]
      55. Get:16 http://httpredir.debian.org jessie-updates/non-free armhf Packages/DiffIndex [736 B]
      56. Get:17 https://openmediavault.github.io erasmus/main Translation-en_US [9,340 B]
      57. Get:18 https://openmediavault.github.io erasmus/main Translation-en [9,340 B]
      58. Hit https://dl.bintray.com jessie/main armhf Packages
      59. Get:19 https://openmediavault.github.io erasmus/main Translation-en_US.UTF-8 [9,340 B]
      60. Get:20 https://openmediavault.github.io erasmus-proposed/main Translation-en_US [9,340 B]
      61. Hit http://httpredir.debian.org jessie-updates/contrib Translation-en
      62. Get:21 https://archive.raspberrypi.org stretch/main Translation-en [336 B]
      63. Get:22 http://httpredir.debian.org jessie-updates/main Translation-en/DiffIndex [3,196 B]
      64. Get:23 https://openmediavault.github.io erasmus-proposed/main Translation-en [9,340 B]
      65. Get:24 https://openmediavault.github.io erasmus-proposed/main Translation-en_US.UTF-8 [9,340 B]
      66. Get:25 https://openmediavault.github.io erasmus/main Translation-en_US [9,340 B]
      67. Get:26 https://dl.bintray.com jessie/main Translation-en_US
      68. Get:27 https://openmediavault.github.io erasmus/main Translation-en [9,340 B]
      69. Get:28 http://httpredir.debian.org jessie-updates/non-free Translation-en/DiffIndex [736 B]
      70. Get:29 https://dl.bintray.com jessie/main Translation-en
      71. Get:30 https://openmediavault.github.io erasmus/main Translation-en_US.UTF-8 [9,340 B]
      72. Get:31 https://openmediavault.github.io erasmus-proposed/main Translation-en_US [9,340 B]
      73. Get:32 https://dl.bintray.com jessie/main Translation-en_US.UTF-8
      74. Get:33 https://archive.raspberrypi.org stretch/main Translation-en_US.UTF-8 [345 B]
      75. Get:34 https://dl.bintray.com jessie/main Translation-en_US
      76. Get:35 http://httpredir.debian.org jessie-backports/main armhf Packages/DiffIndex [27.8 kB]
      77. Get:36 https://dl.bintray.com jessie/main Translation-en
      78. Get:37 https://dl.bintray.com jessie/main Translation-en_US.UTF-8
      79. Get:38 https://dl.bintray.com jessie/main Translation-en_US
      80. Get:39 https://openmediavault.github.io erasmus-proposed/main Translation-en [9,340 B]
      81. Get:40 https://openmediavault.github.io erasmus-proposed/main Translation-en_US.UTF-8 [9,340 B]
      82. Get:41 https://openmediavault.github.io erasmus/main Translation-en_US [9,340 B]
      83. Ign https://openmediavault.github.io erasmus/main Translation-en_US
      84. Get:42 https://openmediavault.github.io erasmus/main Translation-en [9,340 B]
      85. Ign https://openmediavault.github.io erasmus/main Translation-en
      86. Get:43 https://openmediavault.github.io erasmus/main Translation-en_US.UTF-8 [9,340 B]
      87. Ign https://openmediavault.github.io erasmus/main Translation-en_US.UTF-8
      88. Get:44 https://archive.raspberrypi.org stretch/main Translation-en_US [339 B]
      89. Get:45 http://httpredir.debian.org jessie-backports/contrib armhf Packages/DiffIndex [25.3 kB]
      90. Get:46 https://dl.bintray.com jessie/main Translation-en
      91. Get:47 https://openmediavault.github.io erasmus-proposed/main Translation-en_US [9,340 B]
      92. Ign https://openmediavault.github.io erasmus-proposed/main Translation-en_US
      93. Get:48 http://httpredir.debian.org jessie-backports/non-free armhf Packages/DiffIndex [8,530 B]
      94. Get:49 https://dl.bintray.com jessie/main Translation-en_US.UTF-8
      95. Get:50 http://httpredir.debian.org jessie-backports/contrib Translation-en/DiffIndex [7,468 B]
      96. Get:51 https://dl.bintray.com jessie/main Translation-en_US
      97. Get:52 https://dl.bintray.com jessie/main Translation-en
      98. Get:53 https://openmediavault.github.io erasmus-proposed/main Translation-en [9,340 B]
      99. Ign https://openmediavault.github.io erasmus-proposed/main Translation-en
      100. Get:54 https://openmediavault.github.io erasmus-proposed/main Translation-en_US.UTF-8 [9,340 B]
      101. Ign https://openmediavault.github.io erasmus-proposed/main Translation-en_US.UTF-8
      102. Get:55 https://dl.bintray.com jessie/main Translation-en_US.UTF-8
      103. Get:56 https://archive.raspberrypi.org stretch/main Translation-en [336 B]
      104. Get:57 http://httpredir.debian.org jessie-backports/main Translation-en/DiffIndex [27.8 kB]
      105. Get:58 https://dl.bintray.com jessie/main Translation-en_US
      106. Ign https://dl.bintray.com jessie/main Translation-en_US
      107. Get:59 https://dl.bintray.com jessie/main Translation-en
      108. Ign https://dl.bintray.com jessie/main Translation-en
      109. Get:60 http://httpredir.debian.org jessie-backports/non-free Translation-en/DiffIndex [17.2 kB]
      110. Get:61 https://dl.bintray.com jessie/main Translation-en_US.UTF-8
      111. Ign https://dl.bintray.com jessie/main Translation-en_US.UTF-8
      112. Hit http://httpredir.debian.org jessie/main armhf Packages
      113. Get:62 https://archive.raspberrypi.org stretch/main Translation-en_US.UTF-8 [345 B]
      114. Hit http://httpredir.debian.org jessie/contrib armhf Packages
      115. Get:63 https://archive.raspberrypi.org stretch/main Translation-en_US [339 B]
      116. Hit http://httpredir.debian.org jessie/non-free armhf Packages
      117. Hit http://httpredir.debian.org jessie/contrib Translation-en
      118. Get:64 https://archive.raspberrypi.org stretch/main Translation-en [336 B]
      119. Hit http://httpredir.debian.org jessie/main Translation-en
      120. Hit http://httpredir.debian.org jessie/non-free Translation-en
      121. Get:65 https://archive.raspberrypi.org stretch/main Translation-en_US.UTF-8 [345 B]
      122. Get:66 https://archive.raspberrypi.org stretch/main Translation-en_US [339 B]
      123. Get:67 https://archive.raspberrypi.org stretch/main Translation-en [336 B]
      124. Get:68 https://archive.raspberrypi.org stretch/main Translation-en_US.UTF-8 [345 B]
      125. Get:69 https://archive.raspberrypi.org stretch/main Translation-en_US [339 B]
      126. Ign https://archive.raspberrypi.org stretch/main Translation-en_US
      127. Get:70 https://archive.raspberrypi.org stretch/main Translation-en [336 B]
      128. Ign https://archive.raspberrypi.org stretch/main Translation-en
      129. Get:71 https://archive.raspberrypi.org stretch/main Translation-en_US.UTF-8 [345 B]
      130. Ign https://archive.raspberrypi.org stretch/main Translation-en_US.UTF-8
      131. Fetched 127 kB in 9s (13.8 kB/s)
      132. Reading package lists... Done
      133. Building dependency tree
      134. Reading state information... Done
      135. 1 package can be upgraded. Run 'apt list --upgradable' to see it.
      136. root@raspberrypi:~# apt list --upgradable -a
      137. Listing... Done
      138. libcairo2/testing 1.14.8-1+rpi1 armhf [upgradable from: 1.14.0-2.1+deb8u2+rpi1]
      139. libcairo2/now 1.14.0-2.1+deb8u2+rpi1 armhf [installed,upgradable to: 1.14.8-1+rpi1]
      140. libcairo2/oldstable 1.14.0-2.1+deb8u2 armhf
      141. root@raspberrypi:~# apt-cache policy libcairo2
      142. libcairo2:
      143. Installed: 1.14.0-2.1+deb8u2+rpi1
      144. Candidate: 1.14.8-1+rpi1
      145. Version table:
      146. 1.14.8-1+rpi1 0
      147. 490 https://archive.raspberrypi.org/debian/ stretch/main armhf Packages
      148. *** 1.14.0-2.1+deb8u2+rpi1 0
      149. 100 /var/lib/dpkg/status
      150. 1.14.0-2.1+deb8u2 0
      151. 490 http://httpredir.debian.org/debian/ jessie/main armhf Packages
      152. root@raspberrypi:~# apt-cache policy raspberrypi-kernel
      153. raspberrypi-kernel:
      154. Installed: 1.20170811-1
      155. Candidate: 1.20170811-1
      156. Package pin: 1.20170811-1
      157. Version table:
      158. *** 1.20170811-1 1000
      159. 490 https://archive.raspberrypi.org/debian/ stretch/main armhf Packages
      160. 100 /var/lib/dpkg/status
      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.
    • Not sure why the pinning of the debian repo dropped to 490 when your pin config only changes the raspbian repos. Try pinning the debian repo as well.
      omv 4.0.5 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.0.2
      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:

      Try pinning the debian repo as well.
      That was an adventure (especially since I realized way too late that all this pinning stuff with an already f*cked up installation -- I installed already Raspbian/Stretch packages 'for fun' -- is just misleading again and again).

      I think I got it now: OMV_3_0_88_RaspberryPi_2_3_4.9.41.img.xz

      Settings now:

      Source Code

      1. root@raspberrypi:~# grep -v '#' /etc/apt/sources.list.d/raspberry.list
      2. deb https://archive.raspberrypi.org/debian/ stretch main
      3. root@raspberrypi:~# cat /etc/apt/preferences.d/99raspberrypiorg
      4. Package: firmware-brcm80211 libraspberrypi-bin libraspberrypi0 raspberrypi-bootloader raspberrypi-kernel
      5. Pin: release n=stretch, origin archive.raspberrypi.org
      6. Pin-Priority: 1000
      7. Package: *
      8. Pin: release n=stretch, origin archive.raspberrypi.org
      9. Pin-Priority: 490
      10. Package: *
      11. Pin: release n=jessie, origin httpredir.debian.org
      12. Pin-Priority: 500
      Display All

      Et voilà:
      Tested on RPi 3 with an amazingly fast 64 GB Samsung Pro: sprunge.us/iHXV
      And tested again on RPi 2 with an amazingly fast 16 GB SanDisk Extreme Plus: sprunge.us/jBGg
      I wanted to test also with some ultra slow and crappy 4 GB cards (since now the fsresize wants 8 GB as everywhere else) but Etcher sent them all to the trash:
      Changelog:
      • kernel 4.9.41 active by default and raspberry.org stretch repo also active to receive future kernel updates
      • BroadPwn fix due to replaced armbian-firmware package
      • apt-pinning hopefully correct so only firmware-brcm80211 raspberrypi-bootloader raspberrypi-kernel libraspberrypi-bin packages from raspberry.org, everything else from upstream Debian repos
      • automatic update to latest OMV 3.x on first boot
      • some more hidden changes (like setting timezone automagically) reflected in OMV GUI (please check /etc/init.d/firstrun)
      • zram additionally activated (but due to vm.swappiness=0 only for emergency situations when the Raspberry is really running out of memory)
      Please test and if sufficient replace at SF. I'll add then this information also to first post and then we need to find a solution/script for the ~10,000 users of current OMV_3_0_79_RaspberryPi_2_3_4.9.35.img
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • For updating already existing installations I came up with this function:

      Shell-Script

      1. #!/bin/bash
      2. update_rpi_omv() {
      3. # check version
      4. OLD_VERSION=$(awk -F"=" '/^VERSION/ {print $2}' </etc/armbian-release 2>/dev/null)
      5. [ "X${OLD_VERSION}" != "X5.27" ] && return
      6. # switch archive.raspberrypi.org repo to stretch and pin it so only
      7. # wireless firmware, bootloader and kernel are fetched from there
      8. sed -i 's/jessie/stretch/' /etc/apt/sources.list.d/raspberry.list
      9. cat <<-EOF > /etc/apt/preferences.d/99raspberrypiorg
      10. Package: firmware-brcm80211 libraspberrypi-bin libraspberrypi0 raspberrypi-bootloader raspberrypi-kernel
      11. Pin: release n=stretch, origin archive.raspberrypi.org
      12. Pin-Priority: 1000
      13. Package: *
      14. Pin: release n=stretch, origin archive.raspberrypi.org
      15. Pin-Priority: 490
      16. Package: *
      17. Pin: release n=jessie, origin httpredir.debian.org
      18. Pin-Priority: 500
      19. EOF
      20. apt -q update
      21. apt-get -y -q purge -y armbian-firmware
      22. apt-get -y -q install firmware-brcm80211 libraspberrypi-bin libraspberrypi0 raspberrypi-bootloader raspberrypi-kernel
      23. [[ $? -eq 0 ]] && sed -i 's/VERSION=5.27/VERSION=5.32/' /etc/armbian-release
      24. sync
      25. } # update_rpi_omv
      26. update_rpi_omv
      Display All
      Works as expected (armbianmonitor -u output -- see at the bottom after last reboot), updates firmware and bootloader/kernel but doesn't solve the issues with packages that have unfortunately already been updated in the meantime due to missing apt-pinning before. Applies currently to the following packages


      Source Code

      1. root@raspberrypi:~# apt list --upgradable | grep rpi
      2. libcairo2/testing 1.14.8-1+rpi1 armhf [upgradable from: 1.14.0-2.1+deb8u2]
      3. libpam-modules/testing 1.1.8-3.6+rpi1 armhf [upgradable from: 1.1.8-3.1+deb8u2]
      4. libpam-modules-bin/testing 1.1.8-3.6+rpi1 armhf [upgradable from: 1.1.8-3.1+deb8u2]
      5. libpam-runtime/testing 1.1.8-3.6+rpi1 all [upgradable from: 1.1.8-3.1+deb8u2]
      6. libpam0g/testing 1.1.8-3.6+rpi1 armhf [upgradable from: 1.1.8-3.1+deb8u2]
      At this point I'm lost since all my attempts with further apt-pinning end up with debian-backports packages being installed :(
      '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 wrote:

      At this point I'm lost since all my attempts with further apt-pinning end up with debian-backports packages being installed
      What a mess... This is the problem a lot of times with multiple repos providing the same package. I guess you could pin the backports repo lower??

      tkaiser wrote:

      Please test and if sufficient replace at SF.
      I'll try it in a bit.
      omv 4.0.5 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.0.2
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • tkaiser wrote:

      Please test and if sufficient replace at SF. I'll add then this information also to first post and then we need to find a solution/script for the ~10,000 users of current OMV_3_0_79_RaspberryPi_2_3_4.9.35.img
      Tested fine. Uploading now.
      omv 4.0.5 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.0.2
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • tkaiser wrote:

      I'll add then this information also to first post and then we need to find a solution/script for the ~10,000 users of current OMV_3_0_79_RaspberryPi_2_3_4.9.35.img
      Is that a real stat - roughly 10,000 OMV - R-PI users?
      Good backup takes the "drama" out of computing
      ____________________________________
      OMV 3.0.81 Erasmus
      ThinkServer TS140, 12GB ECC /
      32GB USB3.0 / 4TB SG / 1TB WD

      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:

      Is that a real stat - roughly 10,000 OMV - R-PI users?
      No, this is the upper number of potential users of this specific image version that has been now replaced by the newer one which does not only fixed this issue.

      When you check this link sourceforge.net/projects/openmediavault/files/ you see the number of 'weekly downloads' next to each directory. I neither know how Sourceforge defines 'download' (just clicking on the link or really downloading the whole file) nor what users do when they downloaded the installation image: burning it (successful? -- many SBC user fail horribly with this and that's what's Etcher for), keeping it somewhere, using the installation later (intensively or at all).

      So it's just a number allowing to estimate that for whatever reasons a lot of people think about using OMV on the most insufficient devices for this use case :) The older image has been 'downloaded' ~14,000 times within a few weeks so I thought we could talk about up to ~10,000 potential users here.
      '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 wrote:

      So it's just a number allowing to estimate that for whatever reasons a lot of people think about using OMV on the most insufficient devices for this use case :) The older image has been 'downloaded' ~14,000 times within a few weeks so I thought we could talk about up to ~10,000 potential users here.
      I've never given much thought to SourceForge download numbers, but I wouldn't disagree with the overall rough estimate. Of full downloads, I imagine there's a lot of shopping around being done, but if even 1 in 20 adopt and continue to use OMV, a 10K + R-PI user base is not an unreasonable estimate. It might even be on the conservative side.
      _______________________________

      But,, that's just a staggering amount of inefficiency! 8o
      If those numbers are any indicator, R-PI downloads far exceed the number of all other SBC downloads combined and come close to being roughly 1/3 of the user base. :/
      I mean (in the absence of empirical test data) what are they thinking? ?(

      Maybe, after testing OMV on an R-PI and assessing their actual needs /wants in a server:
      Perhaps some of them might get around to buying a server platform or repurposeing an old PC for a bit more horsepower. One never knows... :D In any case, I believe the R-PI purchase price (of $29 to $35) is worth it for a bit of real world testing and for the lessons learned.
      _______________________________

      Again, I believe I'm speaking for more than a few of the 10K+ users, in expressing appreciation for what you're doing with R-PI images.

      Thanks.
      Good backup takes the "drama" out of computing
      ____________________________________
      OMV 3.0.81 Erasmus
      ThinkServer TS140, 12GB ECC /
      32GB USB3.0 / 4TB SG / 1TB WD

      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
    • Users Online 4

      4 Guests