So, I’m doing a lot of little tests before I decide to commit my data to the Cube, because it’s been a rocky start, to be honest. (WHY was ZimaOS shipped with a bug that breaks RAIDs?! That undermined my confidence in this storage solution within the first 18 hours of owning it.)
The most important test I’ve done is to ensure that if one of my HDDs fail, I can simply replace it and let the RAID5 rebuild. This test was not a success…
While the Cube/RAID5 was on and active, I removed one of the drives to manually break the RAID. I then reformatted the drive. (At first I may have only initialized it on a PC, but I didn’t set up a volume, and I don’t think the Cube read the drive in this state? I had to make a volume on it, then the drive could be reformatted on the Cube.)
I did a few restarts here and there to make sure the drive manager window was reporting correctly, since it seems very slow to “catch up” to the state of the physical drives.
But, the RAID Recovery option never worked! The first time, the drive showed up but the recovery failed with a red X. The second time, it begins as if it sees the drive, but the drive doesn’t even show up.
Broken RAID with reformatted drive inserted. (Why does it state “At least 0 B” instead of 12TB?)
We are very sorry, but we have disabled the raid replacement feature in 1.2.1 due to a verification issue. The feature will be back soon, but we are unable to help you repair the raid at the moment.
@LinkLeong What’s the ETA? I have since made a new RAID for testing purposes. But I’m not storing my data on this device until I can confirm myself that a RAID can be repaired.
Receiving the Cube has not been a pleasant experience. I appreciate how responsive you all are and how open to feedback you are, but these issues are ridiculous. You shipped me a NAS, that I can’t depend on as a NAS — and can’t even use as a complete NAS, with RAID Recovery being spontaneously disabled and RAID Expansion still “under development.”
I have to make long-term permanent decisions about how to set this thing up. But you all are still tinkering with it! RAID functionality should’ve been #1 priority and 100% solid by now.
The Pro customers are lucky they haven’t received theirs yet. All these issues are for beta testers, which I am not.
So what is the ETA for this NAS being solid and functional?
As of last week we have found a solution, but it still needs to be productized so that users understand the information about raid. So we expect to simply fix the functionality of raid in version 1.2.2, and continue to optimize product-related issues in subsequent versions. I also understand how you feel, we can only tell you by our actions that we are trying to do better.
I’m with 777-Spider. I, too, need to make these same long-term decisions. I have just spent the last three, nearly 4, days loading 22 TB of data into a RAID5 array with four 12 TB disks. I powered down the Zima cube in order to move this unit into its permanent resting position. I waited several minutes before disconnecting the power supply. When the cube was restarted, it recognized that a RAID5 array had been built with these four discs, but no data was available. I apparently have no choice but to reformat and start again . As you might surmise, I am less than happy. I disabled the disk - hoping to re-enable it and force the cube to reload and recognize my data, but that brought me to same starting point 4 days ago of needing to start from scratch - reformat etc etc. Grrr…
I’d advise anyone thinking of setting up an array on their cube to stop thinking that until the RAID functionality is more robust.
There is no red dot in the top left corner of the dashboard. However it could be that my firewall is blocking this. What IP address would that connection be coming from?
Another concern of mine is Zima making sure future updates don’t break anything either…
I’m not a software developer, but if I were involved, I’d make sure every RAID feature and scenario is tested, multiple times, by multiple people, before the software is released. Since that’s how I found all of these quirks/glitches/bugs myself.
(The drive manager is very clunky and slow. Someone mentioned the drives must be idle before they’d show up for RAID creation, which makes sense. But I feel like the drive manager doesn’t reflect real drive status very well. One must wait for it to catch up, or just restart the Cube to reset it.)
@blacksunix There’s a miserable irony that you discovered the “bug of impermanence” after moving it to its permanent home…
For what it’s worth, 1.2.1 did seem to resolve this issue on my end. My test RAID has stayed functional so far.
1.2.1 showed up as a little message for me automatically. Maybe with a red dot in the top left but I don’t remember. I just saw it, clicked it, and downloaded it. I do have the files in the rauc folder like ED209 mentioned.
Once 1.2.2/Recovery comes around, I may go ahead and begin loading my files onto the Cube. (But I feel I’ll keep the original copy on all my old HDDs for a while, if you know what I mean.)
I was also already planning to use Crashplan to keep my Cube backed up off-site. (Too bad Backblaze won’t allow network drives on its normal plan, or at a reasonable price; as their restore option of mailing 8TB HDDs is better than having to download everything.)
/rauc now has a folder called releases containing a child folder called v1.2.1 that contains 2 files: release.yaml and zimaos_zimacube-1.2.1.raucb . Still no option to upgrade in settings. This may be may actually be a partial download (see below) and could be why I am not seeing the option to upgrade.
My firewall may be the issue as it actively refuses connections to and from mainland china and hong kong by default. I told the firewall to allow connections to china for 30 minutes last night before heading to bed and started a manual download of 1.2.1 using this link: https://casaos.oss-cn-shanghai.aliyuncs.com/IceWhaleTech/zimaos-rauc/releases/download/1.2.1/zimaos_zimacube-1.2.1_installer.img . I awoke to find a partial download of the installer which suggests when the firewall again began blocking connections to china, the download was aborted.
Is casaos.oss-cn-shanghai.aliyuncs.com the server that zimacube uses to download its updates? If you tell me what server is being used by zimacube to download its updates, I can create a custom firewall rule to allow the connection and I think that may fix my problem.
Once the connection problem is fixed, will I need to delete the contents of /rauc to force zimacube to redownload the update files?
The firewall was the issue. Download of the update just completed and the update notification showed up in settings finally. Update to 1.2.1 appears successful.
If you would please provide the IP address of the server that zimacube uses to check for updates, I can create a firewall rule that allows it.
@777-Spider Haha ! I’m smiling about it now, but wasn’t so much then. Since the upgrade, I haven’t been able to get the RAID tab to show its face again no matter what I do with respect to disabling drives etc. Guess I’ll need to practice patience until 1.22 arrives.
As for the elusive RAID section: that goes back to my comment about how the drive manager is “slow to catch up,” or maybe just clunky/glitchy. It’s not as 1:1 as you’d think between UI and hardware (or maybe the hardware is doing stuff which the UI isn’t presenting). I remember a recent comment that the drives have to be idle before they’ll show up as available. I’d try disabling all drives and restarting the Cube, then seeing if the RAID section shows up. Alternatively, you could disconnect all the bays, restart, and reconnect one by one. Just try little troubleshoots like that. That’s how I’ve gotten this to work.
At one point I did have to reformat all the drives in an external dock. (Requiring the unscrewing and rescrewing of the 24 screws I had already just screwed in upon receiving the Cube… This is my attempt at amusement in this situation.) I think this was after I broke my RAID intentionally. Disabling all the other drives didn’t seem to make them reappear. I was getting 2/6 visible or something, but not all of them. An external reformat and/or restart so that the drives are all ‘disengaged’ helped.
Confusion is my normal state @timothy . I apologize . I have tried various permutations of disabling/restarting/waiting/disconnecting to no avail. I was wondering about reformatting using my external dock and trying again. I’ll keep at it.
@unlimitedgeek Just been there, done that. Be sure to update your zc to os version 1.2.1. Apparently that fixes the issue. See the above notes. I am in the process of testing that currently.
@timothy Your comments were super helpful. I ended up having to take my drives out of their sleds, reformatting them using another OS (in my case MacOS), reinstalling them in the sleds, and reinstalling in my zc to get the RAID tab come back. Scared me for a bit as MacOS reported my 12 TB drives as only being 1 TB after erasing! The zc correctly reported them though fortunately.
@unlimitedgeek Brent:
Go to Files>ZimaOS-HD>rauc and make sure you see a folder called releases.
If your zc has access to the net and icewhale’s server(s), that folder should soon contain a folder called v1.2.1 and in that folder should be 3 files: checksums.txt, release.yaml, and zimaos_zimacube-1.2.1.raucb .
That last file should be 4GB in size. If smaller, it probably is being downloaded. when finished, you should see a tab in settings alerting you to update.
Once done, you should be able to recreate your array and have it persist between powerups.
. As you might surmise, I am less than happy. I disabled the disk - hoping to re-enable it and force the cube to reload and recognize my data, but that brought me to same starting point 4 days ago of needing to start from scratch - reformat etc etc. Grrr…
! I’m smiling about it now, but wasn’t so much then. Since the upgrade, I haven’t been able to get the RAID tab to show its face again no matter what I do with respect to disabling drives etc. Guess I’ll need to practice patience until 1.22 arrives.