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

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?

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.

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.

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:

raspberrypi.org/forums/viewtop…=207921&start=25#p1288832 (that's what you get when using slow ARM boards without our 'NAS on ARM' performance improvements, moving Samba's cache into RAM, 4 simple lines added to smb.conf + improved I/O scheduler and I/O priority settings would most probably already cure it. 115Mbps with Gigabit Ethernet versus around 75Mbps with Fast Ethernet PI 3 B is a joke. With appropriate settings it has to be slightly above 150 Mbps at the application layer with RPi 3 B+ and even up to ~300 Mbps when the client pushes data to the RPi as long as the stuff fits into filesystem buffers

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?

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

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)

@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)

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

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': 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).

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)

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)

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.

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.