OpenMediaVault Crashes on Raspberry Pi 3 B+

  • Hey! I'm using the latest OpenMediaVault image on a Raspberry Pi 3 B+ with a 32 GB SanDisk Ultra MicroSDHC SDSQUNS-032G-GN3MN card. I'm also using a 2.1 A power supply w/ an Anker USB-A to MicroUSB cable.


    When I try to create a shared folder and update my configuration, I seem to get a kernel panic and everything dies. The Raspberry Pi slowly reboots.


    Here is a short recording of my issue: https://www.youtube.com/watch?v=Zg4lhN9oQtQ
    Here is a Pastebin of the error log: https://pastebin.com/2968FCij
    System Neofetch: https://pastebin.com/ayfm17Ru
    System dmesg: http://termbin.com/0kox


    What I've tried:

    • Reinstall OpenMediaVault onto the MicroSD card again, using Etcher, multiple times. (Using the image here: https://sourceforge.net/projec…/Raspberry%20Pi%20images/)
    • Switch out different power supplies.
    • Switch out different power cables.
    • Watching for potential power issues using raspimon.
    • Checking /var/log/raspihealth.log. (Doesn't ever exist)
    • Updating the system. (All updates applied, kernel version 4.14.79-v7+)
    • Adding mmc_block.card_quirks=0x80000000 to /boot/cmdline.txt. (Apparently fixes some MicroSD card hardware issues.)
    • Adding dtparam=eee=off to /boot/config.txt. (Apparently also fixes some issues.)


    If you could provide any advice or help, that would be wonderful. I've been trying to fix this for ages now to no avail.
    Thank you in advance & have a wonderful day! <3

    • Offizieller Beitrag

    (I don't know if this will totally fix the issues, however:)


    First, how about slowing down. When you clicked on "Mount" (a drive), you have to wait until the yellow confirm banner comes up, and confirm it. After the yellow banner goes away, "then" your drive is actually mounted. You'll see that in file systems.
    At that point, with a drive that's actually mounted, you'll be able to create a shared folder - where you'll have to wait for the banner again, before proceeding to putting the share on the network (with SMB or NFS).


    After a drive is mounted, you can create a few shared folders at once and confirm them all at the same time - however - you can't layer an SMB share onto a shared folder before it exists (as in you'll have to wait to confirm creation, VIA the banner.)


    Why, you might ask? Arm processors do not compare to i5's, Xeon's, etc., and R-PI's in particular are not known for stellar performance. In fact, they're among the slowest performing SBC's on the market.


    Once you're out of the GUI (which consumes resources), the R-PI will work as a file server for one or two users, and it will stream a 1080p file in native format "if" it's not doing anything else. Just note that it can be easily swamped (CPU at 100%), so adjust your performance expectations and try to be reasonable in what you set it up to do.
    ________________________


    Regarding the Forum error - it's a hosting issue that happens from time to time. If you find that you like OMV perhaps you'd donate $5 US, Euro's, etc., to help out. Hosting is not free.

    • Offizieller Beitrag

    Yup! If you see my video linked above, it seems to crash after making a shared drive.

    Nope :) Just watched it, you click mount then immediately move to create shared folder.


    1) Click mount -> wait for yellow confirmation bar -> click apply -> wait for the changes to be applied to omv
    2) Create shared folder -> again wait for the changes to be applied


    The Pi is notoriously slow, you have to wait to ensure that any changes you make are applied/written to the sd card before moving on.

    • Offizieller Beitrag

    (My bad - where I said shared drive, I meant to say, shared folder.)
    ___________________________________________________________________________


    In your video, this is what I saw:


    You clicked on "Mount" (the drive).


    Then, without waiting to confirm the change with the yellow banner, and waiting for the banner to disappear;
    You created a shared folder. This 2nd action would attempt to to "create a folder and set permissions" before the drive it's to be created on exists.) Obviously, an error dialog is going to result from that action and I honestly couldn't tell you if that created an instability in your install.


    The OMV GUI uses a set of scripts that act on existing Linux command line tools. It maintains a database which tracks the changes to state of the OS, as a result of the actions executed by those tools, and it keeps track of various config files. When actions are taken out of order.... Well, I'm not a Dev. Anything I might say about the result would be idle speculation.


    (BTW: The info you provided was outstanding. Many come on the forum with thin information like - "It doesn't work".)
    ________________________________________________


    The R-PI 3 image is working well for numerous users, who are using identical hardware. Since you're not far into it, rebuild OMV again and since you're using an R-PI, you're going to take things slowly. Be patient and realize that there are concessions to be made when using a $29 computer.

  • This seems to happen on first boot with a fresh copy of the current OpenMediaVault release for Raspberry Pi.Edit


    After this, it reboots, I can sign in. I try to run sudo apt update && sudo apt upgrade and then this happens:


    Edit


    This Raspberry Pi does NOT show a lightning symbol to indicate low power and I'm not sure how I can fix these crashes. This is running from a 2.5 Amp power supply and other power supplies don't seem to stop the crashes occuring.


    Apparently it's running a fresh install of OpenMediaVault 4.1.7 (Arrakis) and the file I'm using to flash is called OMV_4_Raspberry_Pi_2_3_3Plus.img.xz I am using the latest version of Etcher (Now known as balenaEtcher?).


    I'd love some help, I don't know where I'm going wrong.

    • Offizieller Beitrag

    That looks like an SD Card problem test the card using this if that comes out ok format the card using this then write the image using Etcher.


    Wait 20-30 mins then try the gui -> but from the first thread reading through I thought you had this sorted?

    • Offizieller Beitrag

    It you look at the signature below, the User Guide has the processes for testing and flashing SD-cards. There are recommendations for boot drive selection (page 12) and the SBC build process starts on page 24. For SBC's, a wired internet connection is required and a bit of patience is needed while the install completes and updates. (Give it plenty of time.)
    ___________________________________________________
    Beyond the install:


    The things that can go wrong with an SBC (an R-PI or other) are very limited.


    1 The R-PI itself (happens, but fairly rare)
    2. The power supply (not so rare) I use a 3amp supply, similar to this, for an R-PI 2B with a USB powered 2.5" drive.
    3. The SD-card (if it's older, a fake, or a bulk generic, problems are common.)
    4. The software image itself (Other than a very specific bug, or other software nit or pick, - very rare.)


    Problems with the software image usually come from users who don't take the time to confirm the image and skip right to the install, attempts to rush the install, or bad/low quality SD-cards.


    As you consider the possibilities, note that the R-PI image is downloaded by the thousands each week.
    __________________________________________________


    Finally, use the GUI to get any final items up to date, for installing plugin's, and for configuring the server. Other than changing the root password, avoid using the command line until your server is fully configured.


    When you get the install where you want it to be, "clone" your SD card. There's a process for that in the guide as well. After that, with an OS backup in hand, have at it. (You'll have a clone to back out of any problem that may crop up.)

Jetzt mitmachen!

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