New approach for Raspberry Pi OMV images

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


    Code
    root@raspberrypi:~# md5sum /lib/firmware/brcm/brcmfmac43430-sdio.*
    9258986488eca9fe5343b0d6fe040f8e /lib/firmware/brcm/brcmfmac43430-sdio.bin
    8c3cb6d8f0609b43f09d083b4006ec5a /lib/firmware/brcm/brcmfmac43430-sdio.txt
    root@raspberrypi:~# dmesg | grep brcm
    [ 3.063731] usbcore: registered new interface driver brcmfmac
    [ 3.261842] brcmfmac: Firmware version = wl0: Aug 29 2016 20:48:16 version 7.45.41.26 (r640327) FWID 01-4527cfab
    [ 9.624987] brcmfmac: power management disabled

    If you have the fix it looks like this:

    Code
    root@raspberrypi:~# md5sum /lib/firmware/brcm/brcmfmac43430-sdio.*
    5f520a38ab4e943bfa1ba102f80fb2a0 /lib/firmware/brcm/brcmfmac43430-sdio.bin
    9a88b55134d9f8f3ad2331b93f4b7b79 /lib/firmware/brcm/brcmfmac43430-sdio.txt
    root@raspberrypi:~# dmesg | grep brcm
    [ 3.079435] usbcore: registered new interface driver brcmfmac
    [ 3.242599] brcmfmac: Firmware version = wl0: Aug 7 2017 00:46:29 version 7.45.41.46 (r666254 CY) FWID 01-f8a78378
    [ 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:



    Code
    firmware-brcm80211/now 1:0.43+rpi6 all [installed]
    firmware-brcm80211/jessie-backports 20161130-3~bpo8+1 all
    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...):

    Code
    root@raspberrypi:~# grep -v '#' /etc/apt/sources.list.d/raspberry.list
    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:


    Code
    sed -i 's/jessie/stretch/' /etc/apt/sources.list.d/raspberry.list
    apt update
    apt install firmware-brcm80211 libraspberrypi-bin libraspberrypi0 raspberrypi-bootloader raspberrypi-kernel
    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:



    And if we would start an upgrade now we get a 'nice' mixture of Raspbian and Debian armhf packages:



    Code
    Get:1 https://archive.raspberrypi.org/debian/ stretch/main libpam0g armhf 1.1.8-3.6+rpi1 [120 kB]
    Get:2 http://httpredir.debian.org/debian/ jessie-backports/main e2fsprogs armhf 1.43.3-1~bpo8+1 [907 kB]
    Get:3 http://httpredir.debian.org/debian/ jessie-backports/main e2fslibs armhf 1.43.3-1~bpo8+1 [199 kB]
    Get:4 https://archive.raspberrypi.org/debian/ stretch/main libpam-modules-bin armhf 1.1.8-3.6+rpi1 [102 kB]
    Get:5 http://httpredir.debian.org/debian/ jessie-backports/main libcomerr2 armhf 1.43.3-1~bpo8+1 [62.5 kB]
    Get:6 http://httpredir.debian.org/debian/ jessie-backports/main libss2 armhf 1.43.3-1~bpo8+1 [66.0 kB]
    Get:7 https://archive.raspberrypi.org/debian/ stretch/main libpam-modules armhf 1.1.8-3.6+rpi1 [289 kB]
    Get:8 https://archive.raspberrypi.org/debian/ stretch/main libpam-runtime all 1.1.8-3.6+rpi1 [212 kB]
    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?


    Code
    firmware-brcm80211 libraspberrypi-bin libraspberrypi0 raspberrypi-bootloader raspberrypi-kernel
  • 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:



    Bash
    cat <<EOF > /etc/apt/preferences.d/99raspberrypiorg
    Package: firmware-brcm80211 libraspberrypi-bin libraspberrypi0 raspberrypi-bootloader raspberrypi-kernel
    Pin: release a=stretch, origin archive.raspberrypi.org
    Pin-Priority: 1000
    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 5.5.5 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    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:

    Code
    root@raspberrypi:~# apt list -a libcairo2
    Listing... Done
    libcairo2/testing 1.14.8-1+rpi1 armhf [upgradable from: 1.14.0-2.1+deb8u2+rpi1]
    libcairo2/now 1.14.0-2.1+deb8u2+rpi1 armhf [installed,upgradable to: 1.14.8-1+rpi1]
    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: http://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:


    Code
    2017-09-08 11:31:51 upgrade libpam0g:armhf 1.1.8-3.1+deb8u2 1.1.8-3.1+deb8u2+rpi3
    2017-09-08 11:31:53 upgrade libpam-modules-bin:armhf 1.1.8-3.1+deb8u2 1.1.8-3.1+deb8u2+rpi3
    2017-09-08 11:31:55 upgrade libpam-modules:armhf 1.1.8-3.1+deb8u2 1.1.8-3.1+deb8u2+rpi3
    2017-09-08 11:32:08 upgrade libfreetype6:armhf 2.5.2-3+deb8u2 2.6-2rpi1rpi1g
    2017-09-08 11:32:13 upgrade libpixman-1-0:armhf 0.32.6-3 0.33.3+git20151011-7de61d8-rpi1
    2017-09-08 11:32:26 upgrade libpam-runtime:all 1.1.8-3.1+deb8u2 1.1.8-3.1+deb8u2+rpi3
    2017-09-08 11:32:42 upgrade libcairo2:armhf 1.14.0-2.1+deb8u2 1.14.0-2.1+deb8u2+rpi1
    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...

  • 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 5.5.5 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • What is the output of: apt-cache policy libcairo2

    Currently with Raspbian stretch repo active:


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


    Bash
    cat <<EOF > /etc/apt/preferences.d/99raspberrypiorg
    Package: *
    Pin: release a=stretch, origin archive.raspberrypi.org
    Pin-Priority: 490
    Package: firmware-brcm80211 libraspberrypi-bin libraspberrypi0 raspberrypi-bootloader raspberrypi-kernel
    Pin: release a=stretch, origin archive.raspberrypi.org
    Pin-Priority: 1000
    EOF

    omv 5.5.5 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

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

  • 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 5.5.5 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

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


    Et voilà:
    Tested on RPi 3 with an amazingly fast 64 GB Samsung Pro: http://sprunge.us/iHXV
    And tested again on RPi 2 with an amazingly fast 16 GB SanDisk Extreme Plus: http://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

  • For updating already existing installations I came up with this function:

    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



    Code
    root@raspberrypi:~# apt list --upgradable | grep rpi
    libcairo2/testing 1.14.8-1+rpi1 armhf [upgradable from: 1.14.0-2.1+deb8u2]
    libpam-modules/testing 1.1.8-3.6+rpi1 armhf [upgradable from: 1.1.8-3.1+deb8u2]
    libpam-modules-bin/testing 1.1.8-3.6+rpi1 armhf [upgradable from: 1.1.8-3.1+deb8u2]
    libpam-runtime/testing 1.1.8-3.6+rpi1 all [upgradable from: 1.1.8-3.1+deb8u2]
    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 :(

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

    Please test and if sufficient replace at SF.

    I'll try it in a bit.

    omv 5.5.5 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • 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 5.5.5 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • 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 https://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.

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

  • Many thanks for your work!
    But after executing your update script I get the following after apt-get upgrade:


    I have installed the cups-plugin.

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


    2 tweaks/fixes included that are currently not part of latest OMV release for Raspberries

    • Fix for the crontab issue
    • Now also uploading raspihealth.log if available when doing an 'armbianmonitor -u' (see the bottom of this example)

    Not sure if these two minor changes justify releasing a new image? I would wait for RPi people pushing a new kernel update (they're still at 4.9.41 while upstream 4.9 LTS is already somewhat ahead)

  • Quick mini tutorial for initial Wi-Fi setup on a Raspberry Pi 3 or 3+. Do NOT follow the tons of tutorials that tell you to fiddle around with /etc/network/interfaces and some wpa_supplicant stuff but just login as root (change the password now if you haven't done already) and simply enter


    Code
    nmtui-connect

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

    Now enter the passphrase and you're already done:

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


    If you want to use the Raspberry as an Access point instead please refer to the tutorial in post #5 of this thread instead (same for better Wi-Fi hardware)

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

    Sure though I don't know whether nmtui/nmcli are installed on Raspbian (your OMV image is based on). But they're just an 'sudo apt-get --no-install-recommends install network-manager' away if not present.


    And I would strongly recommend to read through these two threads if you're interested in a SBC Wi-Fi experience that does not suck:

    (the performance relevant stuff IMO is: at least 2x2 MIMO, if 5GHz band is available then use it)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!