OpenMediaVault on the RockPro64: not a happy tale

It should have been so easy.

I wanted to set up a personal cloud server – a beefier version of what I’d already done with an old Pine A64 and NextCloud. And having seen it praised on so many YouTube channels, I went for a RockPro64 as the computer.

And not just the RockPro64 – oh no. A NAS case, dual SATA adapter, 32GB eMMC module, USB-to-eMMC adapter and 12V 5A power supply. And when it all arrived it looked like it was going to be a good solution. I flashed DietPi on to the eMMC and it fired up fine. I got the OS configured to a point, but then put it aside while I waited for the two 2.5in drives to turn up.

When I next plugged in the RockPro64 it failed to boot. I’d handled the board a little bit getting it into the NAS case and thought, maybe the eMMC board had wiggled loose. I pressed down on it (having taken ESD precautions, I should add). It seemed okay and when I powered on again, the board booted.

Soon after I powered down again. And the next time I came to boot, that’s when things really started to get wiggy.

Boot, dammit!

It took maybe seven or eight attempts to get the damn thing to boot from the eMMC. The power LED would come on, but the white LED near the reset switch never showed up. Finally it booted. But that was the last time it ever booted from that eMMC card. On the next attempt – and many after that – nothing.

At one point I thought, let’s try booting from an SD card. That went fine.

Thinking the image on the eMMC had got corrupted, I tried flashing it again. Etcher seemed to write the image okay, but when it came to verifying it, it took forever to complete. And the RockPro64 wouldn’t boot from the module.

I took off the eMMC module and wrote another SD card (the previous one was, by this time, in use elsewhere). It booted. Once. When DietPi rebooted as part of the normal setup process, the computer never came back up again. Pressing the reset and power buttons had no effect. In the end I recycled the power. DietPi started to boot, then reported a corrupt partition.

I reflashed the SD card and tried again. Exactly the same deal. Wouldn’t come back up after the reboot. So that was two corrupt SD cards.

So I dug out that original SD card again. It booted. DietPi commanded a reboot and… the PockPro64 didn’t come back up again. But when I cycled the power, it did reboot and this time there was no damaged SD card. Everything went fine. And then DietPi commanded another reboot (this is normal in the early setup stages) and, of course, the board didn’t come back up. This time, cycling the power had no effect. It was dead again.

Yet another power cycle and, finally, a successful reboot.

But here’s the problem. This is meant to be run as a headless server. Logging in via SSH to do some maintenance and then rebooting is hardly abnormal behaviour. But this damn thing won’t reboot with power cycling. And every time I do that I’ll be concerned about a corrupt SD card.

I tried writing the eMMC module with Pine64’s own modified version of Etcher. It seemed to write okay but then failed during verification, reporting a corrupt card. I also used the Pine64 Installer to write an SD card with an Ubuntu image. Booted once, never again.

Change of plan

Of course, by this time I was hitting the forums. I read good reports of running OpenMediaVault (OMV) on the RockPro64. So, time for Plan B. I wanted a NAS anyway.

I’ll save you the long-winded version. OMV installed fine on an SD card and booted okay the first time. But after the first time, booting is always interrupted by a message on the console requesting that I log in as root to deal with some unspecified configuration problem or hit Ctrl-D to continue booting.

Remember how I wanted to run this headless? -=sigh=-

The logs haven’t been much help. Nor has the OMV forum. There was one suggestion that the problem was the time taken for the disks to spin up. There is a message in the logs about the mount point specified in /etc/fstab not being a valid mount point, even though it is. And OMV didn’t have a problem with slow disks on the first boot.

I mean, once it’s running, OMV is great (mostly). It’s just that every time I reboot this box – hopefully not very often – I’ll have to plug in a keyboard just to hit Ctrl-D. Then I have to go in via the web interface to mount the main hard drives (two 1TB disks configured as RAID 1).

OMV’s web front end is pretty good, with a couple of glaring exceptions. One is that it logs you out after a (configurable) period. And that’s fine and as it should be. But it also throws up a big, bold message on screen, surrounded with a red, flashing border, saying Software Failure!

For one thing, this is flat wrong – it’s not a failure, it’s the software functioning correctly – so that’s inept UI design. And for another, it gives me a bloody heart attack every time I see it.

I’ve already told you twice. Just do it, dammit!

OMV is also annoying in the way it gets you to confirm changes. You make a change in a form and click on ‘Save’. A few moments later, up pops a box asking you to confirm the change. And when you do, there’s another dialogue box asking you to confirm the confirmation. Enough already.

Not reliable

So things seemed to be going okay with the NAS setup. The uptime has been nearly four days at the time of writing and I was about to say how, finally, I’m happy with the setup. Until, that is, I logged into the front end and found that the RAID had gone tits-up.

What was sdb is now sdc. Why?

It seems to have ‘lost’ one of the drives. The /dev/sda drive is still there, but /dev/sdb seems to have mysteriously become /dev/sdc and is no longer part of the RAID config. I can’t just add it, either. So I guess I’ll need to reformat it and then rebuild the RAID.

Thing is, though, I now don’t trust this system. And what’s the point of a NAS that you can’t trust? I’m starting to think this is going to become a $200 paperweight.

Pine in the ass

Oh, and that dead eMMC card? I’ve been having fun and games with Pine64.

While I was battling to get the RockPro64 up and running, I ordered a replacement eMMC card. Then I changed my mind, deciding that I didn’t want to waste more money on Pine64 kit. So I emailed the company and told them I wanted to cancel the order.

No response.

I found a different customer service email address and sent the message again.

No response.

So then I raised a tech support ticket about the dead board. That got a response, though not an especially helpful one. During the back and forth, I again explained that I wanted to cancel. They completely failed to respond to that request. I guess they’d already got my money.

And then the new eMMC card turned up. Oh well, I thought, it’s here now, I might as well use it. Which is what I’m doing.

But as for the dead one, Pine64 fobbed me off with unhelpful responses until eventually running out of ways they could insinuate I was to blame. So they asked me to mail it to California for ‘testing’. Note, there was no indication they would replace it. And the postage (from France) would have been at my expense. Add to that the time involved taking it to the post office and it just didn’t make economic sense for me to return this item.

That’s exactly what I told Pine64 and their response was something to the effect of ‘whatever’. And thus the ticket was closed.

Any company with even half a clue about customer service would simply have replaced the card. Pine64’s approach was high-handed and snotty.

So here I am with an unreliable NAS box, a lot less money and a conviction never to go anywhere near Pine64 again.

[UPDATE] Some Odroid computers arrive in a few days. Yay!





2 thoughts on “OpenMediaVault on the RockPro64: not a happy tale

    1. Machina Post author

      Yeah, I did wonder about that. I used the 5A power supply sold by Pine64, and also ran it from my bench supply to see how much it was pulling. There was plenty of headroom on the power, so it’s not that.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.