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

  • One more thing - rebooting doesn't work from command line. I always need to cut the power - no idea why. I will check this evening when I can take a look at the console.
    armbianmonitor output coming up in a sceond.
    I understand CPU frequenc is not critical for NAS transmission speeds - however, the frontend is A LOT more responsive on 1.4 GHz.

  • One more thing - rebooting doesn't work from command line.

    hmm... I know this from other ARM boards and there it's always some driver crashing the kernel while unloading... Hard to tell without the hardware in hands.


    Thank you for armbianmonitor output. You were right and cpufreq settings need an adjustment since RPi folks decided to do all cpufreq and dvfs stuff in their proprietary RTOS instead of how it's done on ARM (let ATF or the kernel do the work)


    Seems they only define 2 cpufreq OPP for the new board --> 600 and 1400. When highest cpufrequtils setting is lower then the board remains at the 'next' lower frequency which is 600 MHz. Crap.


    Can you please test by adjusting /etc/default/cpufrequtils (1400 max) and then doing an '/etc/init.d/cpufrequtils restart' and report back?


    (How I hate dealing with this closed source crap on Rasperries!)

  • I understand CPU frequenc is not critical for NAS transmission speeds - however, the frontend is A LOT more responsive on 1.4 GHz.


    Oh, keeping the new board at 600 MHz wasn't my intention but I had some hope to skip 1400 MHz and remain at 1200 MHz. Seems this does not work so we either have to find a way to allow 1400 risking even more users running in under-voltage related instabilities (e.g. a kernel panic) or to remain at 600 MHz by default and add notes to the Readme at the download page (no-one is reading).

  • Here the new armbianmonitor output after adjusting /etc/default/cpufrequtils and restarting cpufrequtils



  • My last take on this:


    http://kaiser-edv.de/tmp/jk4NM…berryPi_2_3_4.9.80.img.xz (MD5 hash: cb4c12ce3cbebe9920e143c7f8ffcbac)


    @ryecoaaron please use this and delete the others then.


    The cpufreq settings remained the same so RPi 3 B+ will boot the first time limited to 600 MHz. At first reboot the armhwinfo service checks whether under-voltage occured and if not then removes the /etc/default/cpufrequtils control file so after next boot jumping to 1400 MHz when needed is possible. This ensures that the first critical boot process when installation is finished can run uninterrupted — at least less under-voltage hassles when keeping the CPU cores at 600 MHz (1.2V) vs. 1400 MHz (1.38V). And if no under-voltage occured then full speed is possible with subsequent boots.


    I spent again 20 minutes and monitored twice the first boot process when installation will be finished. It's more or less only I/O bound so here a reduced clockspeed to 600 MHz won't hurt (that much). And buying a new and great A1 rated SD card will make the real difference. Always strongly recommended: stop using crappy SD cards and get one of those: https://forum.armbian.com/topi…n-sbcs/?do=getLastComment


    Edit: sorry, wrong link. This is the 'A1 SD card' one: https://forum.armbian.com/topi…ab=comments#comment-49811

  • @badda thanks a bunch! You were a real help. Maybe you find out about the 'reboot issue' but I've to admit that I don't care that much any more...


    That I touched the RPi image again was result of me finding the small SD card with the image yesterday and all needed steps for image preparation still in my MacBook's bash history. Card and RPi 2 will now go to the bin (crappy spring loaded SD card slot broke right now)


    Edit: Updated 'documentation' to turn any of the other 'OMV for ARM boards' images (ODROIDs and friends) into one for RPi: https://github.com/ThomasKaiser/OMV_for_Raspberries

    • Offizieller Beitrag

    please use this and delete the others then.

    Others deleted and uploading new image now.

    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

    Can you please exchange it as well?

    Done.

    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 am kinda a Linux noob, but lets look at my options:
    1. I install your OMG Image
    or
    2. I try apt dist-upgrade
    right?


    But why shouldn't I just download the latest OMV image for raspberry [from: https://sourceforge.net/projec…/Raspberry%20Pi%20images/] and try that when they patched it for Raspberry Pi 3B+ ?


    Also the performance issue on the RPI3B+ might consider me to keep on RPI2B+ :(

    Einmal editiert, zuletzt von tkaiser () aus folgendem Grund: Removed full quote

    • Offizieller Beitrag

    But why shouldn't I just download the latest OMV image for raspberry [from: sourceforge.net/projects/openm…/Raspberry%20Pi%20images/] and try that when they patched it for Raspberry Pi 3B+ ?

    tkaiser is the one who created the sourceforge image. I just upload 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!

  • But why shouldn't I just download the latest OMV image for raspberry [from: sourceforge.net/projects/openm…/Raspberry%20Pi%20images/] and try that when they patched it for Raspberry Pi 3B+ ?

    Yep, in the meantime I assembled the necessary parts to a new image that is available for download on SF now:


    • ThreadX (the 'firmware') is updated which is most basic requirement for any secondary OS (like Linux) to run on the new RPi (this was the most important part)
    • Updated kernel and device-tree (without this no network for example)
    • Some precautions since the new RPi is much more power hungry

    So simply give it a try from the download page. If you run into issues you most probably suffer from under-voltage as an awful lot of other RPi users. When you see a yellow lightning bolt on a connected display that's the firmware signaling that input voltage dropped below 4.65V. Then the firmware clocks everything down (CPU, DRAM, GPU, VPU) but if input voltage still drops the SoC gets severely under-volted and then you experience freezes, crashes, kernel panics.


    The new board has a higher consumption and is therefore able to trigger under-voltage related issues way more easy compared to older Raspberries. There are some workarounds possible as we currently implement (only using Fast Ethernet by default and allowing the new board to clock at its higher clockspeed only if no under-voltage at 600 MHz occured). Another workaround if you don't need Wi-Fi and BT is to simply disable them (saves another 250mW:(


    Code
    sudo rfkill block all

    But the only real solution is to improve powering. If you use a random phone charger with a random Micro USB cable chances are great that you suffer from under-voltage all the time. Replacing the whole with a good PSU with fixed cable is the only way to go. Unfortunately the majority of RPi users is not even aware what a crappy idea 'powering through Micro USB' is...


    TL;DR: if the new OMV image doesn't work for you on power hungry RPi 3 B+ please check powering first


    Edit: And given how the RPi Foundation deals with this problem (ignoring it instead of fixing) users are not able to get a clue what's going on. Here for example an additional USB gadget connected at startup creates the voltage drop that let's the board freeze :)

  • But if I do not wan tto overwrite my SD card with a fresh .ISO, can I also do an upgrade so I won't lose all my OMV + plugins settings?

    Yes, this should work. I've been able to only test with an RPi 2 and there it definitely works (the result of an 'apt upgrade' -- the relevant files are updated afterwards). But it should be obvious in the meantime that stuff that smells like 'our software is broken' is often with Raspberries just 'your hardware is broken' instead.


    If you currently run on a RPi 2 and have updated the image there you should check /var/log/raspihealth.log. If it reports under-voltage already on your RPi 2 then with same PSU and cable you will for sure run into troubles on the new power hungry RPi 3+


    Read here how to access the log file or run the test tool 'raspimon': New approach for Raspberry Pi OMV images

  • Ok, now I was able to closely inspect the boot and shutdown behavior. On boot, the very first messages right after the RGB test image is:

    Code
    vc_vchi_sm_init: failed to open VCHI service (-1)
    vc_sm_connected_init: failed to initialize shared memory service
    [Failed] Failed to start Load Kernel Modules.


    The first two error messages, I was able to solve by setting gpu_mem=32 in /boot/config.txt


    However, the message regarding the Kernel Modules remains.
    Here the respective entry from systemctl


    Code
    systemd-modules-load.service     loaded failed   failed     Load Kernel Modules

    What could be the cause for that?


    Funny enough, I was not able to reproduce the erroneous shoutdown behavior now that I'm checking the console. I will keep you posted when I'm able to reproduce it.

  • watchdog: watchdog0: watchdog did not stop!

    https://unix.stackexchange.com…own-watchdog-did-not-stop


    And keeping gpu_mem at the absolute minimum (16 MB AFAIK) seems like a good idea to me since Raspberries unlike more modern SBC have only 1 GB DRAM so we shouldn't allow the VideoCore to steal RAM for nothing. It's a harmless info message and intended behaviour.

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

    I will try again with the latest firmware on my Rpi 3b+, the kernel panic I was seeing was 'Kernel panic not syncing: Attempted to kill init! Exited" see attached


    Never mind, they shipped me 2 Model B+, not 3 Model B+ doh!

Jetzt mitmachen!

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