Just wondered if anyone else has come across this issue - unit was functioning fine. Then after a reboot just get’s stuck @ dashboard “Almost There…”.
This thing must have some backdoor ssh or terminal (without drobo apps) - As I am currently waiting for support to get back to me (and it’s the weekend so I expect nothing until Monday).
As a day job I am a computer engineer therefore I decided to have a look through the diagnostics logs. It shows a few ports open 5000,5001,5002,5003
and also 444. but nothing really to go on.
A telnet to 5000 spews back a load of XML config data.
Reboots return to the same situation - can access advanced controls to blink lights and reboot etc. but nothing to do with fileshares etc.
Basically I downgraded the firmware - changed a few settings and then upgraded back to current firmware (UPDATE: going back to current firmware causes problems still!!!).
If you are following this - I take no responsibility for your data - but it enabled me to get on using my Drobo again.
CTRL + Click on Check for updates in Dashboard install older firmware (I suggest not going back too far - it might damage your data).
Finally turn off things that are not essential to the MAIN purpose of your drobo (ie. turn off Drobo apps).
Good Luck… Worked for me
“I appreciate what Tech Support do - because that’s what I do for my customers. Unfortunately the process of fault finding by someone else is just not quick enough for me.”
I’ve been having similar issues since day 1 with my Drobo FS, although I’ve only ever had firmware 1.0.5. About 1 in 4 boots will fail with all lights on the unit looking correct (green lights for the drives, blue lights indicating proper capacity), and a completely unresponsive unit. Well, not quite - I can ping it, so I know it’s alive and on the network - but anything else fails. It doesn’t appear in the Finder/Explorer, in Drobo Dashboard, or SSH.
My best guess is something is causing a race condition that’s preventing the boot process from completing. Everything else finishes up in parallel (thus the lights), but some job is hung and thus it doesn’t finish booting. Sadly the logs haven’t been useful and tech support - from what I’ve seen - is out of ideas.
(Yet another reason that I feel DRI’s Linux engineers aren’t exactly the cream of the crop. Watching their response to user/password/security issues for DroboApps has left a general sense of failure.)
Jeff B of DRI Tier 3 support had previously identified one of my drives - a Hitachi 1TB pulled from an Apple Time Capsule - as a potential problem since it had “Apple HDD Firmware 2007” applied per the drive label. I was doubtful, thinking a SATA drive is a SATA drive.
Well, long story short, I purchased a new 2TB Western Digital Caviar Green drive to replace the Apple 1TB Hitachi Deskstar, and after a dozen boots for test purposes it passed with flying colors. No more freezes on boot. Looks like the DRI tech support folks were right on the money!
I’ve said it before - I may be very critical of how DRI has handled DroboApps, the design of the Dashboard, and the registration wall on these forums - but their phone tech support is simply the best I’ve ever dealt with.
LATER… Yeah, nevermind. That first day I had a dozen or so boots flawless. Today, two failed boots out of three. Meanwhile, I’m now outside the phone support period so… I guess so much on opening a case, and I just deal with buggy firmware.
To add to the picture: I have the same issue with my Drobo FS: About 1-2 in four boots fail to complete, while the lights on the unit indicate that it should be working correctly. In my system are four plain WD Caviar Green 2TB, so I don’t have any funny firmware there.
I usually manually switch it off and on again, in most cases it then boots through. The worst I got so far was 3 tries until it finally worked. Consequently, I don’t switch it off ever again, unless I am away for a week or more.
Regards, Martin
On the one hand, I’m sorry others have this problem. On the other hand, I’m relieved I’m not alone. On a third hand (damn radiation), I doubt that any of this is going to get DRI to actually fix their product, based on their past history and the lack of updates to the FS in the last six months.
It’s been sometime since my original post and I thank all the contributors to the thread.
Well after a successful few weeks with firmware 1.0.3 (as 1.0.4 or 1.0.5 would not get past “…almost there”) - I noticed that a completely new version had arrived (yipee I thought). So after manually updating firmware (CTRL + check for updates then browse for firmware file) - after the firmware required reboot - I return to the same old “almost there…” - but instead of being able to go back to previous firmware - it would appear the new firmware has altered something on the “Volume” in that backward compatibility has become broken.
So I now have no access to my files and am extremely Peased Off - So being from the UK and reading the comments above I have contacted Drobo support in the US and am working my way towards 3rd line support (but not there yet!).
I wonder what it is between 1.0.3 and 1.0.4 (and 1.0.5) that has stopped my drobo from doing a full successful boot and also what has happenend between 1.0.5 and 1.1.0 to the Volume… - Answers on a postage stamp…
If only they had a firmware with SSH built in so that I could try a few things - I feel so helpless being locked out.
As I am a Computer Engineer by trade I have a fair bit of knowledge and could probably identify why the “Samba” (windows file share) service is not able to run (if only I had firmware low level SSH - as dropbear Drobo App does not load in this state.).
God Damn it…
I bought this thing to enable expandability and reliance of my data - but the problems I have had really are starting to make me wonder if I should have built my own “BeyondRAID” system.
Well, the firmware does have SSH built-in, the dropbear app is just a script to start the SSH server. Maybe DRI has some secret way of starting the SSH server without needing to have the droboapp there?
@rikski:
Have you called Data Robotics support?
Email is convenient and all, but if you’re going out of your mind, it’s best to call. I read your post that you’re waiting for tier 3, but wasn’t sure whether that was via email or phone.
[quote=“bhiga, post:10, topic:2099”] @rikski:
Have you called Data Robotics support?
Email is convenient and all, but if you’re going out of your mind, it’s best to call. I read your post that you’re waiting for tier 3, but wasn’t sure whether that was via email or phone.[/quote]
Hi Bhiga,
Yes have called support - they are polite and are trying to be helpful, but it seems to take hours and hours between each suggestion and call back (on drobo’s side - I action the requests within minutes).
They are now suggesting that the var/passwrd file may have been changed - if so I would have thought a patched firmware or backdoor via ssh could easily resolve this.
As I say I am a Computer Engineer with over 15 years experience - I have tried everything on the forums relating to “almost there” lock ups - in order to avoid the process of try and see’s…
I would really like someone from drobo who has a deeper understanding to call me - that way I could probably get to the bottom of this within minutes rather than days or weeks…
Thanks again for your suggestion - and I hope I have not offended you - as that is not my intention.
No offense taken at all. I monitor a user forum in my day job, and it’s surprising how umm… shy people get sometimes with regard to picking up the phone. So I just like to make sure all the bases are covered.
Sometimes it helps when calling support to politely ask for a manager or upper-tier support engineer. Sometimes it works, sometimes it doesn’t, really depends on the person you get.
Hope you get it solved soon, and please let us know what the outcome is!
I have the same issue. What I did:
What I Did:
Drobo FS with 1.1.1 Firmware, activated jumbo packetsize of 9000, everything working “ok” (even though extremely slow transferspeed of about 3 MB/s, no matter if directly connected to GBit port on PC or Switch). Installed apps: apache, droboadmin, fuppes, rsync (weeks ago, not used in the last weeks, no changes in the last weeks).
I opened an incident 110224-000130 with drobo to get that sorted out.
As suggested from the support I changed the Jumbo Packetsize back in drobo dashboard (unchecking the check mark, old entry was 9000). Then I installed and tried the IOMeter software on the PC and tried that it worked for about a minute. Then I restarted the Drobo-FS.
Since then
the Drobo-FS boots “ok”, the blue capacity LEDS might take longer to reach the final capacity (after the usual boot up only 3 LEDS are lit, after a few minutes goes up to the 6 LEDS that represent the correct fill level). That gives me hope that my data is still available.
The drobo dashboard starts recognizing the drobo-fs (something like “almost there”), I can enter the drobo dashboard menu meanwhile (shows
wrong (smaller) used data capacity (see above), admin account can not be set (greyed out), network can not be set back to jumbo frames, but there is a connection.
After completing the bootprocess drobo dashboard changes to the start screen with no drobo available, but
the drobo-fs is reachable using ping (direct connected with giving my PC
IP-Adress works, using router with dhcp-server also works, drobo-fs gets an internal ip and is pingable)
the webinterface (app) is not reachable anymore, not even using direct
ip-adress instead of name
if I pull all the drives, drobo dashboard can connect to the drobofs, but
still the admin account is greyed out!
What now? Is there a way to reset the drobofs to defaults in a way my data
is saved? Is there another way to access the data? I desperately need at
least read access to the data.
I tried:
pulling all the drives
manually reinstalling 1.1.0 firmware (admin account still geyed out)
then update again to 1.1.1
installing the drives again - no change, problem still as described above
pulling all the drives again
manually reinstalling 1.0.5 firmware (admin account still geyed out)
then update again to 1.1.1
installing the drives again - no change, problem still as described above
Long story short. If you can map the shares without the Dashboard, then mount the DroboApps share and move everything out of there. Misbehaving droboapps are usually the reason why Drobos get “stuck”* on boot.
*: Technically they are not stuck, since you can even mount a share. But the process that is responsible for responding to the Dashboard does get stuck if a droboapp misbehaves.
Tried
\192.168.178.24\Public
with combinations of users/passwords
root/root
Admin/root
Admin /“my password”
my normal user
none of that worked (but of course did before the problems).
Hmm, if you don’t have the SSH droboapp, you don’t have access to the droboadmin/apache droboapp, and can’t mount shares I’m not really sure how this can be fixed. I think this is a job for DRI support.
