experiments with gentoo on the Drobo-FS

Since upgrading to Lion I’ve lost the ability to manage my Drobo via Drobo Dashboard and mtdaap (iTunes Sharing) has stopped working. The Drobo no longer shows up in Time Machine either, even though file sharing and ssh seems to work fine. I blame DRI’s proprietary software.

So… having a fairly decent knowlege of embedded systems I figured I could just set up a gentoo chroot and install some software that actually works. It was easier than I thought and here’s how to do it directly on the Drobo over ssh:

[php]# We’re installing as ‘gentoo’ in the DroboApps share
export DROBOAPPS="/mnt/DroboFS/Shares/DroboApps"
mkdir “$DROBOAPPS/gentoo”

Grab and extract stage 3 tarball

wget “http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/releases/arm/autobuilds/current-stage3-armv5tel/stage3-armv5tel-20111028.tar.bz2
tar -xjf “stage3-armv5tel-20111028.tar.bz2” -C “$DROBOAPPS/gentoo”

Setup new environment

cp /etc/resolv.conf “$DROBOAPPS/gentoo/etc/resolv.conf”
“$DROBOAPPS/gentoo/bin/chroot” “$DROBOAPPS/gentoo” emerge --sync

Enter environment whenever you want with

“$DROBOAPPS/gentoo/bin/chroot” “$DROBOAPPS/gentoo” bash[/php]

You’ll notice you now have a familiar GNU userland with a fully functional install of perl and python AND a working C compiler!

Is it wise to put that on DroboApps? After all, that area is periodically processed by the Drobo for new apps. I’d want to put it somewhere else - perhaps its own share.

But thanks - I think I have a new project when I get back. :slight_smile: I haven’t used Gentoo in many years, but this is a great idea to get lots of software on the DroboFS without dealing with the vagaries of its own Linux layer.

Sorry for the answer on my “backup” forum account - my main account got autobanned again… :confused:

Actually this is due to the fact that the 1.1.x firmwares use an old version of netatalk. You can get the latest version here: http://www.droboports.com/app-repository/netatalk-2-2-1

It’s a bit of a dangerous DroboApp (see the page for the gotchas), but it has been working fine for my Lion-based Mac Mini. On the announcement thread someone posted some pretty good performance figures (almost 30 MB/s): http://www.drobospace.com/forums/showthread.php?tid=3614&pid=23468#pid23468

mtdaap is a different story. The official app is dead, and no longer supported. I tried to find a stable, properly maintained fork but I haven’t found anything that matches that criteria. There are a bunch of patches floating around, but no centralized repository. Because of that I haven’t yet tried to package it into an app. If anyone knows of a good fork of mtdaap, I’d love to hear about it.

About the chroot: I remember someone here on the forums was trying to get a Debian chroot environment. I’m not sure how far they went, but I assume that it can’t be harder than what you did. In fact, as soon as I have some time I’ll try to get a Debian chroot going.

One question though: how bad is the memory overhead?

I installed your version of netatalk and now I’m backing up my Macbook for the first time in about 2 months. Thanks for that! I think it’s worth noting that if you don’t remove the old .AppleDB directories before rebooting your Drobo you can end up locking yourself out of ssh and afp. I had to manually mount my Drobo over smb and remove the old directories, and reboot again to get access. That might put newbies off :wink:

As far as mt-daapd goes, some of the Debian devs have forked it and made some big improvements: http://www.jblache.org/projects/daapd/

FYI: Some things in the chroot are /really/ slow. Portage seems to take 5 mins to initialise. It is written in python though, and I seems to remember it being slow on my desktop too so maybe it’s not actually that bad.

That is an interesting side-effect. I have not done anything like that and still everything worked out of the box (except the shares being ‘empty’). It is quite puzzling that netatalk would somehow affect the startup of the SSH daemon. Which one are you using? Dropbear or OpenSSH?

In any case, I’ll place a disclaimer on the DroboPorts page.

Yeah, I saw that one. But the git repo lists the last commit being in September, whereas the issue with iTunes 10.5 started somewhere in October. In fact, I found some people reporting that the current version of forked-daapd as being broken as well 1.

Someone in the Apple forums made a patch 2, but as far as I can tell it has not yet been introduced in that repository. I’d rather wait until the proposed patch is merged in the repo, to have at least some measure of quality control.

This is most likely caused by low amount of free RAM. What is really sad is that the FS actually has 512MB onboard, but for some reason only 180MB of it is available to the Linux OS.