Drobo FS - No Dashboard, all green happy lights, "cannot run '-/b" error on tty

Hey everyone,

Been all over the boards here and the internet trying to revive our Drobo FS. It stopped being discoverable and mounting out of nowhere, and of course Drobo’s are completely out of stock, so eBay prices are getting out of hand for used FS/5N/5N2.

The drobo appears to be fine, boots like normal, checks the array, all lights are green and happy and disk status is reported in the blue status lights.

Been through just about everything I can find online. When connecting to the Linux serial port, I get the error:

cannot run '-/b

This error starts popping up right after the startup step “Freeing init memory: 108K” and repeats every second during the balance of the startup, and then anytime I try to type in the terminal the text is replaced with the cannot run error.

I suspect I may need to reload the firmware, but I cannot find any steps to do this without a working dashboard connection.

Any ideas?

Here’s the wall of text when the issue starts:

eth0: started
IP-Config: Guessing netmask
IP-Config: Complete:
device=eth0, addr=, mask=, gw=,
host=DB78xx0, domain=, nis-domain=(none),
bootserver=, rootserver=, rootpath=
eth0: link up, full duplex, speed 1 Gbps
VFS: Mounted root (jffs2 filesystem).
Freeing init memory: 108K
wait_for_init_shared_mem: Exiting Mutex for shared memory init
wait_for_init_shared_mem: Entering Mutex for shared memory init
wait_for_init_shared_mem: Exiting Mutex for shared memory init
Shared Memory Partition Map Addresses:

SHJ1: Start: 0xa6000000, End: 0xaa000000, Phys: 0x1bfff000
HLRC: Start: 0xab000000, End: 0xb1000000, Phys: 0x15dff000
SGLD: Start: 0xa0a00000, End: 0xa0b00000, Phys: 0x158ff000
SHLX: Start: 0xa5400000, End: 0xa5600000, Phys: 0x15bff000
SHVX: Start: 0xa5800000, End: 0xa5a00000, Phys: 0x159ff000

SHARED_MEM: shm_queue_sync_cores: Mapped SHMQ partition at phys addr: 0x1bdff000 in kernel mem for size 0x200000
SHARED_MEM: CPU1: shm_queue_sync_cores: Ready to wait for init of SHMQ
cannot run '-/bSHARED_MEM: CPU1: shm_queue_sync_cores: Queue Init Started CPU0. Waiting on Init Done
SHARED_MEM: CPU1: shm_queue_sync_cores: Init of SHMQ done
handle_intercore_msg: Got Time Valid message
handle_intercore_msg: Got a NET_INFO request
cannot run '-/bhandle_intercore_msg: Got ISCSI_ENABLE message
init_write_buffer: dev: 93da7400, FreeList: a6000200, FreeBlocks: 131071
handle_intercore_msg: QUEUING ISCSI_ENABLE to sysfs
scsi0 : dri_dnas, version 0.1.0 [20090720], Commands: 0, Aborts: 0, Device Resets: 0
scsi 0:0:0:0: Direct-Access DROBO DroboPro 1.00 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 4294967295 512-byte hardware sectors (2199023 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
sd 0:0:0:0: [sda] 4294967295 512-byte hardware sectors (2199023 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
sda: unknown partition table
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
cannot run '-/b

You could try a factory reset (pinhole reset), see if it behaves or will upgrade firmware afterward.
Maybe shut down & stash your disk pack to one side while you attempt that if you have a couple of random spare drives on hand.

I do have more disks I can try in there.

I tried to figure out and follow the procedure to do a pinhole reset, but it didn’t appear to do anything. Does there need to be disks in there to preform the reset?

Maybe I had the procedure wrong.

I can’t say for certain with regards to needing disks or not for the pinhole reset, but having a couple of spare disks to load in does allow you to confirm if the problem is the unit or the disk pack. Also allows you to experiment on an unimportant disk set & only reintroduce your actual set when you have things working again.