Dependencies

Before one can install drobo-utils itself, the other packages needed are something like those below (these examples are ubuntu packages, names may vary on other distributions):

python      -- interpreter for python language
parted      -- partitioner, usually included with the distro.

If using Redhat Enterprise Linux (RHEL, aka. CentOS, Scientific Linux etc...), which have python 2.4 [3], then the following are necessary:

python-ctypes -- module for C-interface

On RPM-based distros (such as Redhat & SuSe), it would more likely be 'yum' instead of 'aptitude' and some of the package names will change. A typical difference is that packages for developers have the -devel suffix on Redhat derived distributions, instead of the -dev favoured by debian derived ones.

Here is an example from fedora 7 (courtesy of help4death on the google group):

% yum install python
% yum install PyQt4
% yum install python-devel

NOTE: if X or QT is missing, it will only disable the GUI. Line mode will work without issues. The package should work fine on headless servers using only the command line.

Install From Package

Once dependencies are satisfied, one can install the latest stable package manually.

Point a browser at: http://sourceforge.net/project/showfiles.php?group_id=222830

where the most current packages are available. after downloading a .deb, it is simply a matter of:

# dpkg -i drobo-utils-<version>.deb

done!

Redhat/Fedora users. alien may be used to convert the package. I don't know if it works. Someone to take on RPM packaging would be very welcome! This is a pure python package, so the chances are good that it does work without issue.

There is a Fedora Package

Install From TAR file

Assuming the dependencies are installed/satisfied, the package will actually run fine without being installed in any systemish places. Source code can be directly downloaded run it explicitly from the directory.

Point a browser at: http://sourceforge.net/project/showfiles.php?group_id=222830

download the .tgz preferred, then unpack it:

# tar -xzvf drobo-utils-<version>.tgz
# cd drobo-utils-<version>
# ./drobom status

for all of the examples in the manual one just needs to prepend './' before drobom.

Install from GIT

When a new model comes out, or the stable version is missing a feature, one may elect to follow along with the latest development version. installation of git, is necessary, then use it can be used to get a copy of the source tree:

# apt-get install git
# git clone git://drobo-utils.git.sourceforge.net/gitroot/drobo-utils/drobo-utils
# cd droo-utils
# ./drobom status
# git pull

This gives a read-only copy of the source code that can be updated with the latest changes with 'git pull'. One can also select any stable version of drobo-utils by use of 'git branch -r', and 'git checkout'. For details, consult git documentation.

So, one way or another, drobo-utils is installed. The next step is to try it out.

Try Out the CLI

The first item to verify after installation is to invoke the command line interface (CLI.) and see if something sensible happens... on my system with a drobo[#sdz] the following happens:

% sudo drobom status
/dev/sdz /drobo01 100% full ( ['Red alert', 'Bad disk', 'No redundancy'], 0 )
%

very scary, but my drobo is in bad shape right now... normal result is: [] as a status, which means there is nothing wrong. To get all kinds of information about the drobo, try 'drobom info.' Invocation without arguments at all which will cause it to print out a list of the commands available through the command line interface.

Try Out the GUI

Once the command line functionality is verified, and assuming python-qt4 is installed:

# drobom view

as root starts a GUI for each drobo attached to a computer. There are various tabs to allow one to obtain information from the Drobo, and also change its configuration. For example, one can use the Format tab of the GUI to partition the device and create a single file system for a given LUN.

There are two choices to make when setting up a Drobo: file system type, and LUN size. For a discussion of these choices, please consult: LUNSIZE fits all and Filesystem Choice.

LUNSIZE Fits All?

By default, Drobo creates a separate 'disk' visible to the computer for every 2 Terabytes (TiB) of parity-protected capacity on the unit. The natural usage that a drobo invites in users is to have a single, large device covering all the data on device. For example, on Mac OS/X, users often create 16 TB LUNS on HFS. This allows all the storage to fit on one large pool. The downside of larger LUNS has to do with startup time, and the time to perform a file system check.

Under Linux unfortunately, with a first generation Drobo, one should limit the volume size to 2 TiB[#gen12TiB]_. It is hoped, but not confirmed, that later products support LUNS larger than 2 TiB on Linux. Drobom view therefore limits lunsize to 2 TiB for the moment. The command line interface can be used to create larger LUNS, they just might not work.

ON LUNSIZES >= 2TB:

-- On older distributions, there are a couple of gotchas related to

linux tools which aren't 2TB ready... to exceed 2 TB, you need to:

-- use GPT partitions, which aren´t supported by older fdisk

versions. Tools based on libparted work fine, mostly.

-- gparted fails, and seems to have a 1 TB limit on devices.

(bug #524948 reported to bugzilla.gnome.org) It's just the GUI, as libparted is fine, and other tools based on it still work.

-- on linux kernel < 2.6.24, the USB layer won't let one address

LUNs/offsets > 2 TB. For example, Ubuntu hardy (8.04) released in Spring 2008 has a 2.6.24, and so is OK. I've never been able to test this problem.

-- On linux kernel < 2.6.31 there is are reported firewire problem that will

prevent devices > 2 TiB from working.

-- ext3 with 4K blocks is supposed to allow file system capacity of 8 TiB.

4K blocks seem to be assigned by default. So I think a good max. It would be fun to set the LunSIZE to 8 TiB and test it out...

-- Windows XP does not support LUNS > 2 TiB

What Kind of File System?

Drobos work well under linux with ext3. One can, of course, set up an NTFS or HFS+ or FAT32 if necessary, but it seems actively counter-intuitive on Linux. Developers of Drobo-utils have not tested HFS. Linux does not write to Journalled HFS+ at this point, so HFS support is not present. Good success is reported with Ntfs-3g, but the performance is much lower than what is typically reported with ext3. Unless physical movement of the disk to between systems is required, the native (ext3) format is the best option.

iSCSI Setup

This is a procedure for configuring a Drobo Pro for access via iSCSI. This information is based on a post by Lemonizer on the Google Group 2009/05/16, with updates based on improvements and tests by others in the fall of 2009:

1. Connect the Pro via USB, and manually configure the ip of the dbpro

# drobom info settings
# drobom set IPAddress 192.168.2.80
# drobom set NetMask   255.255.255.0
# drobom set UseStaticIPAddress True

The next step is to disconnect USB, and connect by iSCSI:

2. Install open-iscsi (http://www.open-iscsi.org/): sudo apt-get install open-iscsi
3. Connect the dbpro to host machine via iscsi
4. Query dbpro's id: sudo iscsiadm --mode discovery --type sendtargets --portal 192.168.2.80
5. Copy the id string returned by iscsiadm, something like "iqn.2005-06.com.datarobotics:drobopro.tdb091840080.node0"
6. Connect to the dbpro: sudo iscsiadm --mode node --targetname iqn.2005-06.com.datarobotics:drobopro.tdb091840080.node0 --portal 192.168.2.80:3260 --login

If everything went well, your drobopro should show up under /dev. Also check /var/log/messages to confirm that the iscsi device connected successfully. After that, drobo-utils should be able to detect the Drobo and manage it over ethernet/iSCSI.

(source: http://groups.google.com/group/drobo-talk/browse_frm/thread/453e02e105e9b41?hl=en )

Some people reported data corruption. This link claims to fix one such issue: http://www.drobospace.com/forum/thread/13951/Dropped-iSCSI-connections/?page=2#24792

SAFETY

Those worried about safety of using this software should know: it was developed with assistance from the vendor (Data Robotics Inc.), and in every case, based on vendor documentation, and with at least encouragement, if not outright support. For each release, a QA.txt file is built, demonstrating the functionality tests run. There are multiple checksum verifications built into the firmware upgrade process, so it is next to impossible to brick a drobo using the tools. Drobo-utils verifies firmware checksums before attempting to upload the image to the device, and the device checks the firmware against the checksums as well. New firmware is loaded into an alternate location from the currently active one, and if activation of the new firmware fails, the drobo will simply boot the old one.

On the other hand, common sense rules do apply. Setting the LUN size, or re-formatting a Drobo will erase all data whether it is done on Linux or any other operating system. These are power tools, and they can do some damage data if used without proper care. For example, the reliability of any storage unit does not reduce the need for backups it only makes doing them easier. A Drobo is an excellent place to put backups, but not a substitute for them. Backups are the only way to address error 18 (the number of inches in front of the keyboard the source of the issue lies.) and no storage unit can protect against fire or flood.

Firmware Compatibility

Drobo has been tested with every old firmware version. Any Drobo should be upgradable to modern firmware using the dashboard.

for Drobo v1's (only models available to me used for QA)

NOTE: really need at least 1.1.1 to use Linux & ext3.

just use the tools to upgrade firmware ASAP.

1.01 - very old... bad idea to install this, need to write

a script to get out, because it isn't in the revision table. not much works except firmware upgrade. DO NOT USE. UPGRADE ASAP

1.0.2 - works ok in CLI And GUI to view, and upgrade firmware.

DO NOT USE. UPGRADE ASAP

1.0.3 - GUI and CLI work OK, can upgrade firmware.

Used ntfs3g for a few months under ubuntu 7.10 Linux. Used 2 TB LUN, with 1.5 TB of physical space available. DO NOT USE. UPGRADE ASAP

1.1.0 - dashboard works no issues.

• from this point, you don't seem to need to unplug the USB connector to complete the upgrade.
• firmware prior to here deals badly with ext3.

1.1.1 - 1.2.4 works without issues.

('name' not supported by firmware)

1.3.0 - works without issues. 1.3.5 - works without issues.

General Concepts

Don't rely on a single device, ever! Before deploying a storage unit, one should perform the thought experiment of what will happen if all data on it is lost. There are always levels of risk. For personal use, one might accept the risk that if the house burns down, only have infrequent offsite backups are available and months or years of data may be lost. If someone is running their business out of their home, this risk will likely not be acceptable.

The simplest method of backing up your data is to put it in a humungous single place, and backup the whole thing. That is a valid strategy, but consider the following realistic case:

A company does incremental backups[#incrbkup] once a day, and full backup once a week. Once a month, a second full backup is kept as monthly, while the weeklies are recycled. Monthly backups are kept for a year, and each year, one backup is kept for five years. So if you write data once and keep it unchanged for five years, you will have 3 weekly backups, 11 monthlies, and 4 yearly backups of that data, or 17 copies. This strategy is not unusual or particularly excessive, many corporate policies end up with 50 or more copies of the data.

With that in mind, if you avoid backing up what you don´t need to, then you are not saving just one byte, but all the copies too. With a little thought, one can usually reduce the total storage needs by classifying data appropriately.

Different Drobo models have very different performance. Deploying a Drobo using a USB interface as primary storage is likely to disappoint. See the compatibility matrix for details.

Classify Your Data

There are different levels of value for data. Things that are downloaded from the internet, or source code that is pushed to a repository on the internet, have natural backups in most cases. The loss of data being queued for printing, might not be a terrible loss. The loss of videos recorded off the air from television, might not be terrible either.

Any kind of data which is either not worth backing up, or for which a backups already exist, does not need to be backed up locally. The other end of the spectrum is proprietary data, for which copies on the internet are not be appropriate, and which is irreplaceable if lost. In a photographic business, the photos, Tax records, accounts, etc... In a personal realm, these would include family photos, etc... lets call this sort of information precious data

That irreplaceable data is what you need to safeguard. So the classification can be done in a number of ways, but the simplest is just to only put precious data in the home directory. So far that´s normal. The unusual thing comes next: Do not put anything else there. Internet downloads, easily replicable data, etc... should go somewhere else. In general, keep the home directories of users as small and precious as possible.

As another example, in my personal use case, Linux is readily downloadable, so there are no system backups at all. Configurations are relatively straightforward, only credentials, and special configurations are backed up, by having copies of the information in an normal /home directory of a user. The restoral time for a single system is not an issue for my personal use, and by the time a restore is necessary, there will probably a new OS version to try out, so the value of system backups is quite limited.

The only thing backed up, is the personal (/home) directories of a few users.

Primary Storage

If a Drobo is used for primary storage for precious data, a second one should be obtained as a backup device. It´s as simple as that. Keeping all data on one device that cannot be backed up is asking for trouble.

Zealots will say that the second unit should be off-site. The Gen 1 / Gen 2 Drobo´s are also have limited performance, and are perhaps not well suited to a role as primary storage.

Scratch Storage

If the data there is all space that either exists elsewhere (mirrors of internet sites), can be regenerated (object files of compilation, recordings from on-air broadcasts in a media server), none of this data is particularly precious, and all of it can be recovered over time in the event of a data loss on one unit.

Again, one argument against such usage is performance. First and second generation units are a bit on the slow side for use in say. On the other hand, media serving is a streaming application with typically low instantaneous bandwidth requirements, so even first generation Drobos should be fine for that.

Backup Repository

A rational means of configuring the Drobo is as a backup repository. The drobo is destination of the backups. Primary copies are on the desktops & laptops being backed up. Viewed in that way, backup data is easily recovered in the event of a data loss: just backup the system again. Of course the history of backups is lost, but the important thing is usually being able to recover current data.

No Drobos Discovered

To find Drobo on a system, drobo-utils queries all the attached devices for indications it is made by Data Robotics. These strings change from product to product. If the (new model) Drobo is not detected, then run the command line interface with the hardware detection debugging output turned out. like so:

# drobom -v 16 status
examining:  /dev/sda
id:  (0, 0, 0, 0, 'ATA     ')
rejected: vendor is ATA      (not from DRI)
examining:  /dev/sdb
id:  (2, 0, 0, 0, 'ATA     ')
rejected: vendor is ATA      (not from DRI)
examining:  /dev/sdc
id:  (8, 0, 0, 0, 'Drobo   ')
rejected: vendor is Drobo    (not from DRI)
returning list:  []
No Drobos discovered

Here you see that the vendor string is 'Drobo' which was not a known vendor string at the time this example was run. so then try:

# drobom -s Drobo status

In other words, take the unknown vendor string and feed it as -s option to tweak detection of drobom. Your drobo will likely then be picked up.

Only One LUN Shows up?

LUN is an abbreviation of 'Logical UNit'. The origin of the term is SCSI[#SCSI]_ terminology. When RAID units became too large for support in the past, and were sub-divided to present smaller units the operating system. The default LUNSIZE on Drobos is 2 TiB (adjustable using the tools.) If more disk space (after allowing for parity/redundancy) than LUNSIZE is installed in a unit, Drobo will show a second (or even third) LUN. Each LUN shows up in Linux as a separate disk (examples if the first LUN shows up as /dev/sde, the next will be /dev/sdf, then /dev/sdg.)

If you think you should see multiple LUNS and you don't, you might have a look at some kernel settings: make sure that scsi_mod kernel module is loaded, make sure /sys/module/scsi_mod/parameters/max_luns is > 1.

Drobom view will start up one GUI per drobo, regardless of the number of LUNS. If asked to format, all LUNS for the device will be formatted.

Getting Help from DRI

DRI intends Drobospace.com for owners to talk with one another, except no non-owner can see the discussions, and early on, there was a lot of input from DRI staff, so it looked a lot like a support forum, but it really isn't. A lot of owners objected to these forums being private, so a google group was started for people to talk with one another, and the discussions to remain public:

http://groups.google.com/group/drobo-talk/topics?hl=en

There is still a great role for Drobo space, in that Tier 3 support analysts (essentially developers.) sometimes look over there. For tier 3 support, one cannot expect guaranteed response time, but one may be able to provide some input into future products or firmware features. It turns out that the Drobospace forums aren't really for support. but don't take my word for it, here is above was DRI's take (verbatim from a post on drobospace by MarkF 2008/08/29) on things:

To contact Data Robotics Inc. for support your options are:

1. phone support - technical issues: 1-866-426-4280, Mon-Fri from 8am-5pm PST, excluding Holidays.
2. phone support - presales questions: 1-866-99ROBOT
3. email support - technical issues: support@drobo.com
4. email support - presales questions: sales@drobo.com
5. web-based support request: http://www.drobo.com/Support/Request_Support.html

All technical support calls, emails, and web requests are assigned a case number and tracked. DRI has 3 tiers of customer support. Tier 1 and 2 handle the majority of cases. They are responsible for tracking phone, email, an web cases and resolving them. Some cases are escalated to Tier 3 whose personnel reside in our corporate headquarters and have access to engineering staff.

Support on Drobospace.com:

Drobospace.com is a user community and relies on the volunteer efforts of its members to help each other. Because it is run by volunteers response to problems varies. Tier 3 support personel monitor the Drobospace forums -- tiers 1 and 2 are focused directly on customers, and they are not required to read drobospace.com. By design Tier 3 personnel do not immediately respond to each posting in order to allow the community to function. Depending on the nature of the problem, tier 3 may post in the forum or contact the member directly through a private message to facilitate problem resolution.

Because Drobospace is owned and run by a third party, Capable Networks LLC, there is no linkage with DRI's database systems. Posts here are not assigned case numbers and tracked - that only happens with cases opened directly with DRI.

What LUNSIZE should I use?

2 Terabytes is the biggest you should use for now. There are lots of experiments on the google groups, summarized here: LUNSIZE fits all Also consult the compatibility matrix indicates best guesses at the current state of affairs. DRI announced new firmware 1.1.4 for Drobo PRO which is supposed to remove the 2 TiB restriction, but that isn't confirmed yet.

What Happens When I Used A Bigger LUNSIZE?

That's actually a bit nasty. Nothing happens at first, everything seems to work fine. After a while, it fails to reclaim space when files are deleted. The blue capacity lights don't show much relation to how full the file system is, as reported by the operating system. Drobo may become insatiable, always asking for more and more disk space, even though the amount of data used on the file system doesn't warrant it. In extreme cases, data may become in-accessible.

How Do I Check That a LUNSIZE Works?

DRI naturally releases new versions of firmware and may fix these issues at some point. If you are willing to test it out on your new Drobo, the procedure to do so is simple:

1.  Create a file system as per normal.
2.  Fill the physical space up.  (blue lights should light up.)
3.  Remove alot of the data.

If the problem is not there, then blue lights will function properly and go out to correspond to the deleted data after a while. If the blue lights do not go out after step 3, then do not trust your data to this file system. Re-create with a smaller LUN, and try again. 2 Terabytes is the only case of documented success so far.

Can I user ReiserFS, XFS, BTRFS, xxfs ?

Short answer: no.

For Drobo to perform storage management, it has to know what space is free, so it needs to understand the file system you are using. The list of file systems it official understands is: FAT32, NTFS, HFS+, ext3. That's it, so if you want to use reiserfs, or xfs, or GFS, or whatever... you are doing research. The vendors says those other file systems types will not work.

If my Drobo breaks, Can I Get My Data back?

No. The way the data is placed on the disks is completely proprietary. You cannot take the drives and connect them individually to a server, and read the data off that way, because it isn't a linux md or lvm format that can easily be reconstructed. You cannot give the disk pack to a data recovery company, because they do not know the data format either, and you will have to pay them to reverse engineer DRI's format, which will get expensive quickly.

You need either a backup, or another Drobo. Even among Drobos there are limits to compatibility see the Drobo.com web site for details.

My USB Drobo always comes up as a different Disk!

The order and timing of disks being connected to hot-plug busses will determine the device name (it might be /dev/sdb one time, and /dev/sdc another.) So putting /dev/sdX in the fstab to mount their disks, as is traditionally done, won't work. Instead, do:

peter@pepino:~$ ls -l /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 2009-12-15 04:54 2C88743C8874071C -> ../../sda3
lrwxrwxrwx 1 root root 10 2009-12-15 04:54 32a41d0a-b193-41f3-86fa-29bbee8cd2b3 -> ../../sda8
lrwxrwxrwx 1 root root 10 2009-12-26 12:08 3cd5d9cc-c227-4ed8-bab2-60c2d71f6e9d -> ../../sdf1
lrwxrwxrwx 1 root root 10 2009-12-15 04:54 72b0ee8c-d0e8-479d-b79c-3dbda1581f55 -> ../../sda6
lrwxrwxrwx 1 root root 10 2009-12-15 04:54 814472db-dbee-411c-8870-7ca59f32e7c1 -> ../../sda5
lrwxrwxrwx 1 root root 10 2009-12-26 12:16 8ed93296-9be2-4576-9ae4-9d9c78363fb6 -> ../../sdg1
lrwxrwxrwx 1 root root 10 2009-12-15 04:54 a4bc252e-0eb7-489c-94e7-688efd528665 -> ../../sda7
lrwxrwxrwx 1 root root 10 2009-12-15 04:54 bc1ab400-df49-457d-8700-c77dde19e450 -> ../../sda2
lrwxrwxrwx 1 root root 10 2009-12-15 04:54 C2EE700DEE6FF7D5 -> ../../sda1
peter@pepino:~$

The UUID is a name that is constant for a partition. Each time a partition is mounted, a link will be created in this directory towards the correct /dev/sdX. A UUID related /etc/fstab entry looks like:

UUID=3cd5d9cc-c227-4ed8-bab2-60c2d71f6e9d  /drobo01   ext3 defaults 0 2

How come the command to build a file system builds an ext2 file system?

because an ext3 file systems is an ext2 file system with a journal. The normal command to build an ext3 file system is mke2fs -j.

Can you have different LUNS with different file systems on them?

DRI: Multiple partitions per LUN is supported. Having any combination of file supported file systems on the different LUNS and partitions is fine as well.

Does Drobo work with LVM?

Some people do it. I would not risk it.

The Linux Volume Manager is a layer of software which is shimmed between the file system layer, and the physical disks. It provides a 'fake' (virtual) volume on which file systems are built. This gives flexibility to concatenate several physical volumes together to make a single file system, or allocate a single volume to different file systems over time, as needs dictate rather than all at the outset.

For Drobo, LVM would be especially cool in that one could initially allocate only the physical space actually available within the LUN, and thus applications which key on avoiding filling file systems would function correctly, instead of always asking to insert more storage, and not managing the storage available. When more physical space (new drives!) becomes available, one could allocate more space to the virtual volume, and then grow the file system. So Drobo would still take care of the drudgery of RAID set maintenance, relay operations, etc... but the user would have more control on how space was allocated at the OS level.

For that to work, Drobo firmware would have to understand LVM to some extent. Initial experiments showed that the firmware didn't appreciate LVM. Being able to add a Drobo unit as an pv to an LVM unit would be very cool.

Does Drobo Support Full Disk Encryption?

Drobo works by knowing how the file system is laid out and pretending to have more space than is physically present. Drobo does some sleight of hand to manage disk space and move things around optimally as hard disks fail or are added.

Full disk encryption implemented by the operating system makes the Drobo unable to understand the file system, so it doesn't know which blocks are in use, and the unit will always believe the system is completely full. Drobo will not behave well. Among the methods that will not work are any that operate on a raw disk partition, such as truecrypt, or any of the linux cryptoloop based solutions.

Instead of whole disk encryption, a method that uses an underlying file system that is well known to the Drobo (the list is short: FAT32, NTFS, HFS, EXT2) is needed. On windows, encrypting directories with standard NTFS will work fine. On Linux, a good choice would be EncFS http://www.arg0.net/encfs, which encrypts file names and data over an ext file system, or some other method which uses FUSE http://fuse.sourceforge.net. is reported to work well.

I have read everything. Help?

Best first stop is the google Group.

What is Drobo-utils' License?

General Public License - Gnu - GPL .

Quality Assurance (QA.txt)

QA.txt is a quality assurance log. The version on the trunk of the releases indicates the QA procedure to be applied to the next version during the release process. Since a branch is created for each release, the version of QA.txt acts as a quality log for that release. so one can do a git checkout, or git export to get the quality log for any release (QA.txt introduce in version 0.4.0)

Building Debian & Ubuntu Packages

Assumes you have installed the Build dependencies:

# obtain a fresh tree
% git clone ssh://user@drobo-utils.git.sourceforge.net/gitroot/drobo-utils/<version> drobo-utils-<version>
% cd drobo-utils-<version>
% rm -rf .git  # get rid of Git cruft, yielding a raw source tree.
% chmod 755 debian/rules  # I dunno why the permissions are wrong...

# this debian/ config is just for non-distro packages.
# builds for debian and Ubuntu.

% dpkg-buildpackage -rfakeroot
% cd ..
# rename it for whatever distro is appropriate...
% mv drobo_utils_0.3.3-1_i386 --> droboutils_0.3.3-1_i386_ubunutuIntrepid.deb

# rebuild the source tar because it will have the 'debian' link in it.
% cd drobo-utils-0.99.9
% rm debian
% cd ..
% tar -czvf drobo-utils-0.3.3-1.tgz drobo-utils-0.99.9

apply QA tests. as per QA.txt recording results there.

Open Task: Reverse Engineer Dashboard <-> Droboshare Protocol

Why isn't there full support in host based drobo-utils itself? Digital Robotics hasn't released details of the protocol used by the proprietary dashboard to communicate with a droboshare, so it would be a lot of work to reverse engineer that. So support of a droboshare from a linux GUI on a host system is not likely in the near future.

If someone wants to figure that out, it might be a good thing (tm) After that is figured out, the next step would be to understand how to flash the firmware remotely. That would eliminate the last function that cannot be done with open source.

Building DARFS

DARFS - Droboshare Augmented Root File System. A pile of stuff that can be run on a droboshare.

Have a look here:

http://groups.google.com/group/drobo-talk/web/building-droboshare-apps-on-debianish-os?hl=en

DARFS

The Droboshare Augmented Root File System (darfs) is a 60 MB or so download you can get from drobo-utils.sf.net. There isn't any source code, because, well, nothing from any of the packages has been modified. there are instructions on how to build DARFS in DEVELOPERS

DARFS is a standard droboshare root file system, with some packages added: openssl, openssh, berkeleydb, bzip2, a fairly complete Python 2.6.2. drobo- utils is a python app. and it works in line and API mode, natively, on the droboshare. for example, I've used it to replace the firmware. no problem at all.

People un-afraid of the command line can upgrade drobo firmware, query status, and take diagnositc dumps, from the command line on the droboshare itself, just as they would on any linux host computer. But a full GUI would be too much for the little processor and more importantly the limited memory in the droboshare, so that is not provided.

DARFS Installation

Download it from drobo-utils.sf.net: steps:

1. copy the tar file onto somewhere on your share.
2. log in via DropBear ssh as a root user on the droboshare.
3. cd /mnt/DroboShares/YourDrobo (root of drobo file system, for example)
4. tar -xzf darfs.tgz (root of drobo file system, for example)
5. the root directory of the tar is 'slash'.. it will be under YourDrobo
6. export PATH="/mnt/DroboShares/YourDrobo/slash/usr/bin:${PATH}" (which is where python and drobom are.)
7. drobom status

you're done!

Enable SFTP Support

all you need to do is:

ln -s /usr/libexec /mnt/Droboshares/YourDrobo/slash/usr/libexec

Try an sftp from another machine (as root...) and it ought to work.

(explanation: when one tries to sftp to a droboshare, it gives an error about trying to exec '/usr/libexec/sftp-server'. Openssh builds the right binary, but Dropbear doesn't know where to look for it. the libexec directory isn't there on the droboshare, so there is no harm in creating it and linking into DARFS.)

Droboshare Firmware

With DARFS, and the third party software you can get from drobospace and drobo.com, the droboshare is very open and hackable. However, there remains a one limitation: There is no open source way to upgrade or modify droboshare firmware. If you want to re-flash to a factory original state, you need the vendor dashboard.

Step -1: Stuff you need:

You need a droboshare, with a drobo on it. You need also need to download some stuff:

mkdir ~/drobo
cd ~/drobo
mkdir droboshare
cd droboshare
mkdir Downloads
cd Downloads
Drobo SDK:  http://www.drobospace.com/download/11742/Data-Robotics-SDK/
You need to get root access via Drobbear, read the SDK documentation for that.
# which ought to get you ... SDK.zip
cd ..

mkdir sdk
cd sdk
unzip ../SDK.zip

You also need (as per the SDK) a code sourcery toolchain: http://www.codesourcery.com/sgpp/lite/arm/releases/2006q1-6 with target platform: ARM Gnu/Linux

Step 0: install scratchbox2

sudo apt-get install scratchbox2... it might look like this:

trestler:/etc/apt# apt-get install scratchbox2
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libisc44
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  bochsbios debootstrap libbrlapi0.5 libicu38 libvdemgmt0 libvdeplug2 openbios-sparc
  openhackware proll qemu vde2 vgabios
Suggested packages:
  sudo samba sbrsh vde2-cryptcab kvm
The following NEW packages will be installed:
  bochsbios debootstrap libbrlapi0.5 libicu38 libvdemgmt0 libvdeplug2 openbios-sparc
  openhackware proll qemu scratchbox2 vde2 vgabios
0 upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
Need to get 17.7MB of archives.
After this operation, 49.2MB of additional disk space will be used.
Do you want to continue [Y/n]?
Get:1 http://gulus.usherbrooke.ca lenny/main libicu38 3.8.1-3 [5918kB]
Get:2 http://gulus.usherbrooke.ca lenny/main libvdemgmt0 2.2.2-3 [12.4kB]
Get:3 http://gulus.usherbrooke.ca lenny/main libvdeplug2 2.2.2-3 [11.6kB]
Get:4 http://gulus.usherbrooke.ca lenny/main openhackware 0.4.1-4 [76.4kB]
Get:5 http://gulus.usherbrooke.ca lenny/main proll 18-4 [248kB]
Get:6 http://gulus.usherbrooke.ca lenny/main libbrlapi0.5 3.10~r3724-1+b1 [62.7kB]
Get:7 http://gulus.usherbrooke.ca lenny/main vgabios 0.6b-1 [79.1kB]
Get:8 http://gulus.usherbrooke.ca lenny/main bochsbios 2.3.7-1 [155kB]
Get:9 http://gulus.usherbrooke.ca lenny/main openbios-sparc 1.0~alpha2+20080106-2 [229kB]
Get:10 http://gulus.usherbrooke.ca lenny/main qemu 0.9.1-10 [10.5MB]
Get:11 http://gulus.usherbrooke.ca lenny/main vde2 2.2.2-3 [181kB]
Get:12 http://gulus.usherbrooke.ca lenny/main debootstrap 1.0.10lenny1 [52.1kB]
Get:13 http://gulus.usherbrooke.ca lenny/main scratchbox2 1.99.0.24-2 [150kB]
Fetched 17.7MB in 34s (518kB/s)
Selecting previously deselected package libicu38.
(Reading database ... 54086 files and directories currently installed.)
Unpacking libicu38 (from .../libicu38_3.8.1-3_i386.deb) ...
Selecting previously deselected package libvdemgmt0.
Unpacking libvdemgmt0 (from .../libvdemgmt0_2.2.2-3_i386.deb) ...
Selecting previously deselected package libvdeplug2.
Unpacking libvdeplug2 (from .../libvdeplug2_2.2.2-3_i386.deb) ...
Selecting previously deselected package openhackware.
Unpacking openhackware (from .../openhackware_0.4.1-4_all.deb) ...
Selecting previously deselected package proll.
Unpacking proll (from .../archives/proll_18-4_all.deb) ...
Selecting previously deselected package libbrlapi0.5.
Unpacking libbrlapi0.5 (from .../libbrlapi0.5_3.10~r3724-1+b1_i386.deb) ...
Selecting previously deselected package vgabios.
Unpacking vgabios (from .../vgabios_0.6b-1_all.deb) ...
Selecting previously deselected package bochsbios.
Unpacking bochsbios (from .../bochsbios_2.3.7-1_all.deb) ...
Selecting previously deselected package openbios-sparc.
Unpacking openbios-sparc (from .../openbios-sparc_1.0~alpha2+20080106-2_all.deb) ...
Selecting previously deselected package qemu.
Unpacking qemu (from .../qemu_0.9.1-10_i386.deb) ...
Selecting previously deselected package vde2.
Unpacking vde2 (from .../archives/vde2_2.2.2-3_i386.deb) ...
Selecting previously deselected package debootstrap.
Unpacking debootstrap (from .../debootstrap_1.0.10lenny1_all.deb) ...
Selecting previously deselected package scratchbox2.
Unpacking scratchbox2 (from .../scratchbox2_1.99.0.24-2_i386.deb) ...
Processing triggers for man-db ...
Setting up libicu38 (3.8.1-3) ...
Setting up libvdemgmt0 (2.2.2-3) ...
Setting up libvdeplug2 (2.2.2-3) ...
Setting up openhackware (0.4.1-4) ...
Setting up proll (18-4) ...
Setting up libbrlapi0.5 (3.10~r3724-1+b1) ...
Setting up vgabios (0.6b-1) ...
Setting up bochsbios (2.3.7-1) ...
Setting up openbios-sparc (1.0~alpha2+20080106-2) ...
Setting up qemu (0.9.1-10) ...
Setting up vde2 (2.2.2-3) ...
Setting up debootstrap (1.0.10lenny1) ...
Setting up scratchbox2 (1.99.0.24-2) ...
trestler:/etc/apt#

Step 1) Get a root File system

The idea here is to get a starting point by making a copy of the root file system from a droboshare. After downloading the the SDK from drobospace.com, and enabling root shell access, just log into the droboshare and:

trestler:/etc/apt# ssh root@droboshare
The authenticity of host 'droboshare (172.25.5.13)' can't be established.
RSA key fingerprint is 90:75:3d:ca:f1:42:65:92:71:97:48:d7:6b:ff:d7:8b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'droboshare,172.25.5.13' (RSA) to the list of known hosts.
root@droboshare's password:


Welcome to Embedded Linux
           _  _
          | ||_|
          | | _ ____  _   _  _  _
          | || |  _ \| | | |\ \/ /
          | || | | | | |_| |/    \
          |_||_|_| |_|\____|\_/\_/

          A Data Robotics Product.

http://www.drobo.com/



BusyBox v1.1.2 (2007.06.18-15:03+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ $cd /
/ $  tar -cvf /mnt/Droboshare/Dro*/droboshare_root.tar bin dev fs.ls lib opt sbin src usr version boot etc home linuxrc root serial tmp var


on your Debian or Ubuntu system,

mkdir slash
cd slash
tar -xvf slash.tar

#in the SDK there is some libz stuff,  add it into the appropriate places (/usr/lib for libz, and /usr/include for a .h)

cd slash
cd tmp
tar -xvf ~/drobo/droboshare/sdk/libz.tgz
mv *.so ../usr/lib
mv *.h ../usr/include
cd ../..
tar -xjvf arm-2006q1-6-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
creates the ~/drobo/droboshare/armx directory for the toolchaimkdir slash
cd slash
tar -xvf slash.tar

#in the SDK there is some libz stuff,  add it into the appropriate places (/usr/lib for libz, and /usr/include for a .h)

cd slash
cd tmp
tar -xvf ~/drobo/droboshare/sdk/libz.tgz
mv *.so ../usr/lib
mv *.h ../usr/include

# add includes from the cross-compilation environment...
# this isn't quite right,  the includes came from somewhere else... have to look around...

cd ~/drobo/droboshare/
dirs="`find armx -type d -name include`"
#copy all the include from the sub-directories in armx into slash/usr/include...
#something like this might work:
for i in $dirs; do
    cd $i ; tar -cf - . | (cd ~/drobo/droboshare/slash/usr/include; tar -xvf - )
done

#but a lot of them seem to be repeats, the only really interesting one is:
./arm-none-linux-gnueabi/libc/usr/include

Step 2) Configure Scratchbox2

#some of these helped... not sure which one, have to try again:

sb2-init -c /usr/bin/qemu-arm gcc-armel /home/peter/drobo/droboshare/armx/bin/arm-none-linux-gnueabi-gcc
sb2-init -c "qemu-arm" -t /home/peter/drobo/droboshare/armx
sb2-init gcc /home/peter/arm-2006q3/bin/arm-linux-gcc

Step 3) Build anything...

Build procedures is basically out of the box after this point:

cd bzip2
make
make install PREFIX=/home/peter/drobo/droboshare/slash/usr


cd ../db*
cd build_unix
export CC=/home/peter/drobo/droboshare/armx/bin/arm-none-linux-gnueabi-gcc
./configure --prefix...
make
make install

cd ../ncur*
./configure --prefix=...
make
make install

cd ../openssl*
./config --prefix=...
make
make install

cd ../Pyth*
./configure --prefix=
make

Failed to find the necessary bits to build these modules:
_sqlite3 _tkinter bsddb185
gdbm readline sunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
_curses _curses_panel

running build_scripts
make install

cd ../drobo-utils/trunk
/python setup.py install


cd into usr/bin
vi drobom
#!/usr/bin/env python
:wq

cd ~/drobo/droboshare/src
tar -xzvf ../Downloads/libpcap-1.0.0.tar.gz
cd libpcap*
sb2
./configure --prefix=/home/peter/drobo/droboshare/slash/usr
make
make install
exit

cd ..
tar -xzvf ../Downloads/tcpdump-4.0.0.tar.gz
cd tcpdu*
./configure --prefix=/home/peter/drobo/droboshare/slash/usr
make
fails with:
/usr/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func':
dso_dlfcn.c:(.text+0x2d4): undefined reference to `dlsym'
dso_dlfcn.c:(.text+0x344): undefined reference to `dlerror'
/usr/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var':
dso_dlfcn.c:(.text+0x400): undefined reference to `dlsym'
dso_dlfcn.c:(.text+0x46c): undefined reference to `dlerror'
/usr/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_unload':
dso_dlfcn.c:(.text+0x4e8): undefined reference to `dlclose'
/usr/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load':
dso_dlfcn.c:(.text+0x56c): undefined reference to `dlopen'
dso_dlfcn.c:(.text+0x5d4): undefined reference to `dlclose'
dso_dlfcn.c:(.text+0x5ec): undefined reference to `dlerror'
collect2: ld returned 1 exit status
make: *** [tcpdump] Error 1

vi Makefile
/-lc
a-ldl
:wq

make
make install

so there you go, samples of building a whole bunch of packages.

copyright:

Drobo Utils Copyright (C) 2008,2009 Peter Silva (Peter.A.Silva@gmail.com) Drobo Utils comes with ABSOLUTELY NO WARRANTY; For details type see the file named COPYING in the root of the source directory tree.

[Links and Help][ Index]

Below are highlights included in each release.

TODO:

These are all Open Tasks... HELP WANTED!

• add python version testing to test suite (2.4, 2.5, 2.6)

• add LUN test procedure to DEVELOPERS.txt

• looking at firmware based LUN creation/deletion & format.

• disk pack status.

• alerts.

• fix make_tarball to exclude .git and debian, like it is supposed to.

• review getSubPageStatus, DMIP seems better now.

• review unitstatus vs. diskpack status.

• make a daemon. reasons:

  -- updated for relay out progress. -- alerting -- unified JSON interface for GUI & WUI. -- managed queueing for device (not five GUI's querying in parallel.) -- preserve option settings across reboot? (one report.) -- periodically synch. the drobo clock to the server.

0.6.2.2: 2010/02/06

• fix for Redhat/python 2.4 wanting to partition everything!

0.6.2.1: 2009/12/30

• fix for Drobo S slotinfo firmware bug (reports 8 instead of 5.)

0.6.2: 2009/12/26

• GUI Option setting, thresholds, etc...
• changed command line syntax to more consistently set <item>
• documented option setting in CLI
• more input checking to CLI.
• improved LUN info display accuracy.
• debugged DroboPRO support (debugged via google group. Thanks All!)
• added scsi to info printing options in CLI.

0.6.1: October 7th, 2009

• DroboPro identification fix by spobole,
• parted fix from Patrick Bills
• Looked at newly released DMIP. Found option2 commands for settings.
• Option query/set implemented (but cannot test for DroboPRO)
• migrated source code managers from subversion to git
• minor: consistency of default location to look for fw between lib and gui.
• fixed that inability to read lun size on old firmwares crashed GUI. GUI now works all the way back to the beginning.

0.6.0

• Major: GUI heavily re-vamped. Behaves better.
• Major: DroboPRO support added (thanks to lemonizer on the google group!)
• Major: GUI gets online documentation.
• GUI: layouts replaced fixed dimensions.
• GUI: added Rename support
• GUI: added Load firmware button
• GUI: Show Diagnostics (equiv. to diagprint.)
• GUI: Name display to main display. Easier to tell which Drobo is which.
• GUI: added mount point display to space used tool tip.
• api: added ability to detect un-documented feature bit settings.
• ddiag.c becomes drobom diagprint
• catlee fixes the packaging again.

0.5.0 2009/01/30

• replaced DroboDMP C extension by DroboIOctl python class. no need for architecture dependent packages. this also means you can just try it out straight after download, no need to install anything. much easier. fewer build dependencies as well.
• device detection completely re-written. It works better now.
• Now displays mount points where it makes sense to do so.
• status command output better/different. shows all devices and mount points for each drobo.
• full Multiple LUN support. should do what is expected.
• full multiple Drobo support. should do what is expected.
• added modular info printing with csv list of outputs.
• firmware 1.3.0, has enabled formerly broken functionality which name makes the sync command rename every drobo to 'hi there'. fixed.
• added 'name' command, to name Drobo. (functionality of Sync)
• corrected detection logic, which depended on formerly immutable name. (affects fw >= 1.3.0) now use same mechanisms as sg_scan from sg3_utils.
• documentation moved into restructured text. now shows up on the web. web site and documntation now consistent.

0.4.0 Release: 2008/12/28

• IMPORTANT: firmware 1.3.0 support added. Earlier drobo-utils

  versions will not recognize a drobo running 1.3.0 or later.

• CLI is more normal... use getopts (got rid of device as fixed place arg.)

  now allows command to be an option as well.

• Changed DEBUG from a flag requiring code modification, to a bitmap

  honored as a command-line argument (--verbose)

• misc. improvements in documentation.

• droboview now only launches for first drobo found in list, and stays foreground

  always.

• drobom list returns a list that is easier to parse (suitable for use in backticks.)

• droboview is now just a stub for drobom view. reduced overhead.

• now reports VERSION id in usage. There is a -V option too.

0.3.3 release: 2008/11/05

• lunsize display bug fixed.
• Chris's man pages & help improvements.
• more messaging fixups for when you don't invoke as root.
• fix for ubuntu Intrepid deciding all disks are Drobos. !!
• fixed all the firmware info parsing issues.
• firmware load issues should all be gone.
• Brad's fix for ddiag.c, done properly this time (my bad!)

0.3.2 release 2008/10/25

• for v1, still don't understand index.txt file.

• after testing, some more fixes, v2 downloads now work.

• fixes received from Brad Guillory for v2/tdz firmware downloading.

  they don't do any harm afaict, don't have a v2 to test with.

• added fwload directive to drobom.

• added root user check to give a bigger hint.

0.3.1 release 2008/10/01

• OK I know checking for firmware updates doesn't work

  right now, but I need to find out why. code seems correct. there is a bugfix for getting rid of the 'licensed' part.

• fixes for firmware validation:

  • header CRC on 32bit was broken on 64bit.
  • 32 vs. 64 bit kludge needed.

0.3.0 release 2008/09/04

• added ability to format Drobo

• added ability to set lun sizes

• bugfix for firmware:

  • CRC32 on 32bit intel. (use signed, instead of unsigned.)
  • fixed header CRC not validating.

• added ability to set time on Drobo.

• added simulation mode to Drobo.py, development aid.

• some work done towards lunsize setting, but incomplete.

• some work towards indicating relay out progress, not tested...

0.2.2 Released 2008/08/08

• firmware uploads work with .tdz as well

• tested with older firmwares, contains a few fixes to improve compatibility.

  works well enought upgrade old firmwares.

0.2.1 Released: 2008/08/06

• uploaded to drobospace & sourceforge.
• firmware upload works for .tdf's

0.1.1 Initial version uploaded april 2008

• to drobospace.com and sf.net
• confirmed to work with firmware 1.1.1
• shows status, disk slots filled, model, etc..
• shows fw version loaded.
• blink & standby commands work.