[Solved] OpenMediaVault is incompatible with Raspberry PI 3B+?

  • Hi guys,


    This week I was really excited I got my hands on the Raspberry Pi 3B+ (2018).
    Before I switched my SD card from Raspberry Pi 2B I ran the following linux commands:

    • apt-get update
    • apt-get upgrade
    • apt-get update

    So now I was sure my system was uptodate, I was ready to switch the SD card from my older Raspberry Pi 2B to Raspberry Pi 3B+. But no...
    OMV didn't come online. The network card got another IP than the OMV had set to also. Even my router couldn't force a static IP. After hooking it up to a monitor I could see it booted and asking the login.
    After entering a [successfull] login I got no prompt anymore. The device doesn't listen to me anymore.


    Even after downloading a new Raspberry Pi ISO installation, the only thing I got on the Raspberry PI 3B+ I only got an RGB test image. No sign of life, nothing.


    Did anyone of you guys experience this aswell? Am I doing something wrong?

  • Same here, updated OMV first on my Pi 3b, when I use the 3 b+ model I can login, but OMV doesn't seem to start correctly.


    Tried starting without network cable and disks doesn't make a difference.

    • Offizieller Beitrag

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

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


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


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

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

    • Offizieller Beitrag

    Would that also work with OMV3, since you are point to RPi 4.9.80 kernel ?

    Not sure since I don't have an RPI 3b+ but I would guess so since OMV 3.x and 4.x generally use the same kernel on arm images.

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

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


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


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

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

  • Not sure since I don't have an RPI 3b+ but I would guess so since OMV 3.x and 4.x generally use the same kernel on arm images.


    When do you expect OMV3 to run on Raspberry Pi 3b+ without too much hassle than only switching SD card from older Raspberry to new Raspberry Pi 3b+ ? I read about replacing the boot sector, but I'd rather wait for a stable / easy way.

    • Offizieller Beitrag

    When do you expect OMV3 to run on Raspberry Pi 3b+ without too much hassle than only switching SD card from older Raspberry to new Raspberry Pi 3b+ ?

    No idea. I don't have one.

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

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


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


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

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

  • I ran the following linux commands:

    • apt-get update
    • apt-get upgrade
    • apt-get update

    For whatever reasons the RPi folks themselves recommend to do an 'apt dist-upgrade' even on their Stretch Raspbian build (usually an 'apt upgrade' is enough since you do not want to upgrade the distro but just some packages). For whatever reasons (lazyness?) they deliberately don't want any of their users running Jessie any more (which is OMV 3.x based on).


    In the past we tried to solve this problem with apt-pinning (wasted almost one whole day of my life fighting against RPi Foundation's 'one size fits it all' attempt). The simple reason for this: While RPi Foundation simply stopped providing kernel updates via their Jessie repos they provided them through Stretch repos. But back at that time OMV 4 (Stretch based) was not ready so @ryecoaaron and me worked on getting the OMV image in a state it can remain on Jessie but gets the kernel and firmware packages from their Stretch repos (containing important security fixes -- the BroadPwn exploit was my primary reason to waste my time for our RPi OMV users!). Important note: Those bootloader, firmware and kernel packages are totally unrelated to the distro version. It's just RPi Foundation not providing them any more via their Jessie repos so we had to explore ways to get these packages from their Stretch repo while still keeping the Jessie distro since a distro upgrade would totally break every OMV3 installation.


    I thought this would work still with the new board that needs not only new kernel, new device tree BLOB -- the .dtb file on the boot partition -- but most importantly a new version of the proprietary closed source realtime operating system that controls the hardware: that's ThreadX contained in the 'raspberrypi-bootloader' package.


    ThreadX is not just a bootloader but the primary operating system running on every Raspberry Pi and now that they implemented dynamic voltage frequency scaling (DVFS) first time somewhat correctly but in an incompatible way to before ThreadX needs to be updated to be able to adjust Vcore voltage available to the ARM cores. Maybe updating the raspberrypi-bootloader package doesn't work, maybe it's a freshly released package with a different name (and that's what the 'apt dist-upgrade' is for)... neither know nor care any more.


    It's 2018 folks and you should've been aware in the meantime that any Raspberry Pi is a lousy device as NAS due to 'single USB2 port limitation'. The new RPi 3 B+ is not an exception but just another victim of choosing a horribly IO limited SoC for a dev board (BroadCom's VideoCore IV from 2009). The best you could get is 19 MB/s via Gigabit Ethernet when network and IO access happen at the same time -- that's just twice as fast as the older Raspberries. Or a little bit more with 802.11ac Wi-Fi if your RPi sits one or two meters away from your 802.11ac capable AP. It's just too slow to waste any further development efforts on this platform.


    TL;DR: In case you want to get the RPi OMV image to work on the new board you could start to explore what happens when doing 'apt upgrade' vs 'apt dist-upgrade', check /var/log/dpkg.log and so on...


    Or simply install OMV on top of Raspbian with the usual crappy performance as result:

    The behaviour of RPi Foundation forum moderators (trying to keep RPi users clueless and censoring away everything they don't understand) prevented me from buying the new board. Why wasting spare time on something that lousy when you could also enjoy spending your time on improving situation with interesting, power efficient, inexpensive and magnitudes faster ARM boards for the NAS use case? :)

  • RPi user are not aware that Gigabit Ethernet with broken cables can result in way lower throughput compared to Fast Ethernet -- I guess my warning+explanation and proposed diagnostic tool and workaround will be ignored forever -- keeping users clueless seems a priority on RPi land)

    And here you go: https://www.raspberrypi.org/fo…hp?f=63&t=208512#p1289456


    In case anyone ever touches the RPi OMV image again setting Ethernet speed to 100 Mbits/sec by default with ethtool seems like a brilliant idea to keep the forum clean from all those 'Why slower?! It's Gigabit?!' threads...

  • @Sneeuwvos @britaliano @tr59


    Can you please give OMV_3_0_99_RaspberryPi_2_3_4.9.80.img.xz a try on RPi 3 B+ (MD5 hash: 14c432debb979c9136453158163305a1)


    As usual: Only burn with Etcher. Then the board needs Ethernet/Internet connection at first boot, finishes installation by doing an intensive update orgy so without a fast SD card this can take over half an hour... then reboots and is then ready. Once the 'SD card activity' led stops to blink it should be ready.


    Detailed feedback welcomed (serial console and/or pictures from a connected display if it doesn't work as expected)

  • Can you please give OMV_3_0_99_RaspberryPi_2_3_4.9.80.img.xz a try on RPi 3 B+ (MD5 hash: 14c432debb979c9136453158163305a1)

    @ryecoaaron: I think it's worth to replace or add the image anyway to download page. I fixed one known bug triggering each day an email when notifications are enabled and added a few other minor tweaks (e.g. armbianmonitor update now again allowing for debug log upload, correct performance and even network monitoring)


    Also the new image runs latest RPi kernel (4.9.80) and also latest 'firmware'. And I deleted the 64-bit kernel stuff since no one will try it anyway (without a 64-bit userland it's useless and a 64-bit userland on a host with only 1 GB DRAM is not the greatest idea)

    • Offizieller Beitrag

    I think it's worth to replace or add the image anyway to download page.

    I added it. I will remove the old one once a couple people try it.

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

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


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


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

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

  • I just tried this and I am still getting the same kernel panic @tcaiser

    On which hardware? And which 'same' kernel panic?


    I was asking for information above (serial console or photos from display) for a reason. We're neither mind readers nor will we buy the new RPi -- at least I won't since why should I buy in 2018 such an ultra slow SBC for a NAS?)

  • The network card got another IP than the OMV had set to also. ...


    Even after downloading a new Raspberry Pi ISO installation, the only thing I got on the Raspberry PI 3B+ I only got an RGB test image. No sign of life, nothing.


    Getting a new IP address is the result of each RPi having its own MAC address. The so called firmware provides this address to the Linux kernel and then of course a DHCP server will assign a new address and static leases for the old MAC address won't work.


    The older OMV image can not work since containing the old 'firmware' which is in reality the proprietary closed source main OS running on every RPi. Without updated primary OS (AKA ThreadX AKA 'firmware') no secondary OS like Linux/OMV will be loaded. My new image from 12 hours ago should fix at least this.


    Please keep also in mind that the new RPi 3 B+ is a power hog so you're even more likely to run into brownouts than before. RPi users usually are not aware of what a shit show powering any RPi is, focus only on irrelevant amperage ratings of their PSU and are either not willing or able to understand that the problem usually is a voltage drop under load. As a bonus all these underpowering hardware issues are considered and reported as 'software bugs': https://github.com/bamarni/pi64/issues/66


    Given that none of us has the new RPi (and at least I won't buy one for obvious reasons) it would need quality debug information to nail remaining problems down with latest RPi OMV image from 12 hours ago (if there are still any).


    Please also note that RPi Foundation's own firmware update routine fails to update their own NOOBS installations: https://www.raspberrypi.org/fo…ewtopic.php?f=63&t=208596


    This might explain why upgrading OMV to latest versions also does not result in an image ready for their new hardware. Really don't know and also hate dealing with this proprietary closed source crap (the 'firmware' or 'primary OS' in reality living on the /boot partition)

  • Fresh install with the new image on RPi 3B+.
    The CPU is stuck on 600MHz because the governor is wrongly configured (max is 1.2 GHz):

    Code
    hardware limits: 600 MHz - 1.40 GHz
      available frequency steps: 600 MHz, 1.40 GHz
      available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
      current policy: frequency should be within 600 MHz and 1.20 GHz.
                      The governor "ondemand" may decide which speed to use
                      within this range.
      current CPU frequency is 600 MHz (asserted by call to hardware).

    How can I fix this so it persists between reboots?

  • Thank you for confirming that the new image DOES WORK.


    I did not adjust /etc/defaults/cpufrequtils for two simple reasons:


    1) Clocking up to 1.4 GHz provides close to zero performance benefits (with average and especially the NAS use case -- running benchmarks is a different story)


    2) the DVFS settings the firmware currently uses increases Vcore voltage for this laughable 200 MHz step by a whopping 120mV: https://www.raspberrypi.org/fo…hp?f=63&t=208057#p1287477


    No performance benefit while risking a lot more of our users running into the usual RPi underpowering shit show (a kernel panic is almost always the result of the Pi suffering from under-voltage!) --> better not enable the 1.4 GHz DVFS OPP by default.


    But... unlike most other ARM boards on Rasperries the Linux kernel does not have full control over both cpufreq and dvfs. This is all done by the 'firmware'. Could you please provide output from 'raspimon' while in another terminal 'stress -c 4' is running? Maybe 'firmware' clocks at 1.4 GHz anyway. Linux is not a first class citizen on RPi. The master is the closed source RTOS running on the main CPU (the VideoCore IV) and the kernel even has not the slightest idea at which clockspeed the ARM cores run (see 2nd page of the thread in RPi forum)

  • Here you go ...

    Code
    Time       Temp  CPU fake/real     Health state    Vcore
    11:10:52: 52.6'C  600/ 600 MHz 0000000000000000000 1.2V
    11:10:57: 52.6'C  600/ 600 MHz 0000000000000000000 1.2V
    11:11:03: 52.6'C  600/ 600 MHz 0000000000000000000 1.2V
    11:11:08: 52.6'C  600/ 600 MHz 0000000000000000000 1.2V
    11:11:13: 52.6'C  600/ 600 MHz 0000000000000000000 1.2V
    11:11:18: 54.2'C  600/ 600 MHz 0000000000000000000 1.2V

    after "cpufreq-set --max 1400000", I get the following output


    Code
    Time       Temp  CPU fake/real     Health state    Vcore
    11:12:17: 59.1'C 1400/1400 MHz 0000000000000000000 1.3813V
    11:12:22: 62.3'C 1400/1400 MHz 0000000000000000000 1.3813V
    11:12:27: 63.4'C 1400/1400 MHz 0000000000000000000 1.3813V
    11:12:32: 63.9'C 1400/1400 MHz 0000000000000000000 1.3813V
  • BTW: the clockspeed should remain at 600MHz as long as there's nothing to do. Once performance is needed the Pi should clock up automagically (1200 MHz would be my goal, maybe it results is 1400 MHz on the new hardware which would be a pity). The stress test + raspimon output should give an answer.


    Another note: the new image switches Ethernet to 100 Mbits/sec by default for 3 reasons:


    1) Ethernet cables that work fine with 100 Mbits/sec can be faulty with 1000 Mbits/sec. Our image needs a reliable network connection at first boot so we do the 100 Mbits/sec fallback to increase reliability


    2) switching from Gigabit to Fast Etherner reduces idle consumption by around 500mW. That's huge given that so many RPi suffer from under-voltage.


    3) Gigabit Ethernet on Pi 3 B+ provides a NAS performance increase by a laughable 100%. It climbs from 9.5MB/s to 19MB/s since USB2 bottleneck and shared bus. 100 Mbits/sec also prevents bus contention issues.


    People who know what they do can comment out the ethtool call in /etc/rc.local. If then instabilities occur you suffer from under-voltage and need to fix your power supply situation (this includes cable between board and PSU and even the crappy Micro USB receptacle!).


    If NAS performance then gets worse you need to check cables (use iperf3 and not iperf since the former shows retransmits. Use UDP tests to get an idea about quality of cabling) or you run into USB bus contention issues.

  • Here you go ...

    Code
    Time       Temp  CPU fake/real     Health state    Vcore
    11:10:52: 52.6'C  600/ 600 MHz 0000000000000000000 1.2V
    11:10:57: 52.6'C  600/ 600 MHz 0000000000000000000 1.2V
    11:11:03: 52.6'C  600/ 600 MHz 0000000000000000000 1.2V
    11:11:08: 52.6'C  600/ 600 MHz 0000000000000000000 1.2V
    11:11:13: 52.6'C  600/ 600 MHz 0000000000000000000 1.2V
    11:11:18: 54.2'C  600/ 600 MHz 0000000000000000000 1.2V

    after "cpufreq-set --max 1400000", I get the following output


    Code
    Time       Temp  CPU fake/real     Health state    Vcore
    11:12:17: 59.1'C 1400/1400 MHz 0000000000000000000 1.3813V
    11:12:22: 62.3'C 1400/1400 MHz 0000000000000000000 1.3813V
    11:12:27: 63.4'C 1400/1400 MHz 0000000000000000000 1.3813V
    11:12:32: 63.9'C 1400/1400 MHz 0000000000000000000 1.3813V

    Ok, can you please reboot so that old settings are in place? Then in one SSH session run 'sudo armbianmonitor -m' and after 15 seconds start in another SSH session 'stress -c 4'


    Then provide please 5-10 lines from armbianmonitor output.


    Really important for me to get default behavior without altered cpufreq settings! Thank you!

Jetzt mitmachen!

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