I debated with myself a little as to whether to post or not to post. What the heck … could save you countless hours of fun trying to figure out how to do it yourself ...

Rationale

The thing I like about ARM devices is that they seem to run forever without crashing on virtually no electricity at all, on virtually fresh air. Backing up files into CrashPlan takes a lot of time on a slow internet connection, and I don't want my desktop PC running 24/7 for months on end drawing up to 200 watts and wearing out my hard drives and SSDs

So the answer, setup my cloud backup on a lower powered machine, like the Odroid C1 I bought recently.

This guide should be applicable to other devices like the Raspberry Pi and some of the higher spec devices talked about on this forum like NSA320. The issue with CrashPlan is that the more GBs you back up, eventually the more memory you need. CrashPlan's site recommends at least 1GB of RAM. Now that isn't entirely the minimum necessary, it will run with less, but you may run into issues if you want to back up massive archives on a machine with only 128Mb of RAM ... It might work with some tinkering, it might not, up to you to try it out !

Also ARM hardware isn't supported by CrashPlan. So anything here should be considered “experimental”, but this is a hardware hacking forum, so goes with the territory.

There are plenty of guides on how to put CrashPlan onto ARM, I did one myself on this forum a while back for my GoFlexNet. Problem is CrashPlan keep changing things and I think some of the people who write guides forget steps they take – I've done it myself. And there's variances between hardware platforms and setups. So, sometimes you'll follow a guide and it won't work. Solution – keep it simple as possible.

Basically, CrashPlan is shipped for linux to run on Intel or AMD hardware. In order to run it on ARM we need to “customise” the CrashPlan install.

I decided to go with Java 8, because I heard CrashPlan will run with it, and it's supposed to have a lot of performance enhancements. Odroid C1 is a armhf (rather than armel) processor. Basically the difference is armel does software floating point calcs and armhf has a hardware processor for them, or at least that's the way I understand it. Raspberry PI is also armhf, so the .so files I found for Raspberry PI seem to work OK on Ordoid too. If in doubt, best to compile your own. It's only JTUX that you might need to compile, and that has to be patched for ARM.

A lot of the guides go on about providing a native md5 library, fast-md5 and libmd5.so … I'm not convinced that this is necessary, obviously you're welcome to compile your own and use it, but I've omitted this step because it adds additional complexity, and by default CrashPlan has native md5 switched off. It's possible that java 8 has a better performing md5 anyway. Perhaps someone will do an in depth performance study, me, I haven't got the time !

Also of note is that I'm running CrashPlan “headless”, that is without a monitor attached or a graphical display installed on my server. I did this because I don't really need the “bulk” of installing GNOME or XFCE, and I will administer it "remotely". So there's a little bit of messing around in order to access from a laptop or desktop machine ...

Assumptions – Debian Jessie / ARM (like Odroid C1, RPi, NSA320) Device / user = root / Some of your own working brain cells !

STEP 1 – Install Oracle Java 8

The Debian wheels turn very slowly, they are also precious about including closed source stuff like Oracle Java. So, we need to “grease the wheels”. Best/easiest way to do this is add the webupd8team's Ubuntu repository to Debian and install Oracle Java 8 that way

echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" | tee /etc/apt/sources.list.d/webupd8team-java.list
# echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" | tee -a /etc/apt/sources.list.d/webupd8team-java.list
apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys EEA14886
apt-get update
apt-get install oracle-java8-installer

I #'ed out the deb-src line because I've never read any of the source code I downloaded, and would fetch it manually if I needed it … if you want it then add it back in.

And run a :

java -version
javac -version

That'll confirm it's been installed correctly !

(source - http://www.webupd8.org/2014/03/how-to-install-oracle-java-8-in-debian.html )

STEP 2 – Install libjna

You'll need the JNA, Java Native Access library as CrashPlan uses it and the Intel/AMD version won't run on your ARM device.

apt-get install libjna-java

(source - https://melgrubb.wordpress.com/2014/08/01/raspberry-pi-home-server-part-10-crashplan/ )

STEP 3 – Get CrashPlan installer and install it

CrashPlan update their versions all the time, so you may have to go to their website and dowdload it. At the time of writing this should work :

wget https://download2.code42.com/installs/linux/install/CrashPlan/CrashPlan_4.3.0_Linux.tgz
# Then unpack the file :
tar zxvf CrashPlan_4.3.0_Linux.tgz
# move into the installer directory
cd CrashPlan-install
# Install CrashPlan
./install.sh

Now you're in the CrashPlan installer. I answered defaults to all questions, which is the easiest thing to do. It will start CrashPlan automatically, which will fail, so might as well shut down CrashPlan whilst we apply the magic which makes it work

service crashplan stop
# OR
systemctl stop crashplan

STEP 4 – The MAGIC which makes it work

The essentials are JNI/JNA and JTUX, without them CrashPlan won't work on your ARM device. Plus there's tidying up the mess CrashPlan has made of trying to install the Intel/AMD stuff.

cd /usr/local/crashplan
mkdir ./bak
# backup the i586 .so files
mv *.so ./bak
mv *.lic ./bak
# backup the i586 JRE files
mv ./jre ./jre-i586-bak
# create a symbolic link for java 8 in crashplan directory
ln -s /usr/lib/jvm/java-8-oracle/jre ./jre
# create a symbolic link for JNI dispatcher
# your “arm-linux-gnueabihf” may differ depending on your ARM architecture
ln -s /usr/lib/arm-linux-gnueabihf/jni/libjnidispatch.so  ./libjnidispatch.so

For JTUX I used the Arch Linux .so file, which works fine on my platform. You may want to patch and compile as described here, especially if your architecture is armel - see http://archlinuxarm.org/forum/viewtopic.php?f=31&t=5120 , and you'll need to patch JTUX as described.

Easy way for armhf - RPi / Odroid et al :

# Get the libjtux.so file (the one I used)
wget http://dl.dropbox.com/u/6902100/archlinux/rpi-crashplan/arch_compiled/libjtux.so
# OR
wget http://www.jonrogers.co.uk/wp-content/uploads/2012/05/libjtux.so

(source - http://www.jonrogers.co.uk/2012/05/crashplan-on-the-raspberry-pi/ )


STEP 5 – Tell CrashPlan where JNA is

There's some CrashPlan config files we need to edit …

cd /usr/local/crashplan/bin
# make a backup in case you fuck it up
cp CrashPlanEngine CrashPlanEngine.bak
vi CrashPlanEngine

You need to change :

FULL_CP="$TARGETDIR/lib/com.backup42.desktop.jar:$TARGETDIR/lang"

To

FULL_CP="/usr/share/java/jna.jar:$TARGETDIR/lib/com.backup42.desktop.jar:$TARGETDIR/lang"

(source - https://melgrubb.wordpress.com/2014/08/01/raspberry-pi-home-server-part-10-crashplan/ )

STEP 6 – Make the CrashPlan server available for remote access (ie headless)

cd /usr/local/crashplan/conf
vi my.service.xml

You'll need to change this line :

<serviceHost>localhost</serviceHost>

to

<serviceHost>0.0.0.0</serviceHost>

STEP 7 – Start the CrashPlan server

service crashplan start
# OR
systemctl start crashplan

STEP 8 – Connect to the CrashPlan server from your laptop or desktop (ie "the client")

For simplicity I'm assuming a linux desktop or laptop (although the same is possible from a windows machine, just different file locations on windows). You need to download and install the CrashPlan application (AGAIN) on your laptop or desktop. Then modify this file locally :

vi /usr/local/crashplan/conf/ui.properties

Uncoment and change this line from :

#serviceHost=127.0.0.1

To

serviceHost=192.168.1.233

where 192.168.1.233 is the IP address of your ARM CrashPlan server.

NOW THEN, the above used to be enough, BUT it seems CrashPlan have added a new “feature” which took me ages to figure out and was preventing me connecting to my CrashPlan server. They've introduced a token file, which, if the client application (CrashPlanDesktop) doesn't have access to, then you've get an error in your server's service.log.0 file, complaining about the token being invalid. CrashPlan's own guide about headless server connection doesn't even mention this token, so I suspect it's a very new addition.

Fix by :

# backup your desktop or laptop's token
cp /var/lib/crashplan/.ui_info /var/lib/crashplan/.ui_info.bak
# copy your server's token to your desktop/laptop
scp root@192.168.1.233:/var/lib/crashplan/.ui_info /var/lib/crashplan/.ui_info

Then run :

/usr/local/crashplan/bin/CrashPlanDesktop

If all went well, then you should be accessing your ARM device's CrashPlan server with the client application on your desktop or laptop.

STEP 9 – A bonus to speed things up

You can certainly dig around in the config file on your CrashPlan server my.service.xml and there's a lot of settings which can be adjusted to suit your needs. Some of these settings are available in the CrashPlan client app too. This one isn't, and hopefully will save you some time …

Rationale – there's really no point in compressing files which are already compressed.

Change the /usr/local/crashplan/my.service.xml file from :

<noCompressionPatterns>
        <patternList>
          <windows/>
          <macintosh/>
          <linux/>

To :

<noCompressionPatterns>
        <patternList>
          <pattern regex="(?i).*\.(?:ecc|par|par2|zz|zpaq|zoo|zip|zipx|yz1|xp3|xar|wim|war|uha|uca|uc|uc0|uc2|ucn|ur2|ue2|tar\.gz|gz|tgz|tar\.Z|tar\.bz2|tbz2|tar\.lzma|tlz|sit|sfx|sen|sea|sda|rk|rar|qda|pit|pim|pea|paq6|paq7|paq8|partimg|pak|lzx|lzh|lha|jar|ice|hki|ha|gca|ear|dmg|dgc|cpt|cpi|cfs|cab|bh|ba|b1|arj|arc|apk|alz|afa|ace|s7z|7z|Z|z|sfark|rz|lzo|lzma|lz|gz|F|bz2|mp3|mp2|aac|m4a|mp4|m4p|wma|flac|la|ape|jpg|jpeg|gif|png|iso|exe|bin|pdf|mkv|mov|avi|mpeg|mpg|m4v|m2v|qt|flv|ogv|ogg)"/>
          <windows/>
          <macintosh/>
          <linux/>

It's also possible to switch off compression globally, but not sure I'd recommend that unless all your files are compressed …

Job done I think …

Enjoy

(PS - If anyone knows how to switch off CrashPlan automatic updates, please could you tell me ! )

Don Charisma ... because anything is possible with Charisma

My blog - http://DonCharisma.org
Our commercial site - http://DonCharisma.com



Edited 3 time(s). Last edit at 07/02/2015 05:08PM by DonCharisma.

Hi:

Thank you for your post!
I've spent hours banging my head against getting crashplan to run on my dreamplug (sheeva/pogo/guru/etc). I've figured out much of what needed to be done from other guides, but yours is the only one with the magic sauce for the 4.3 crashplan update! I had figured out all but the libjnidispatch.so link.

--Jim

I gave this tutorial a try today, but can't seem to install oracle java.

W: Failed to fetch http://ppa.launchpad.net/webupd8team/java/ubuntu/dists/trusty/InRelease  Unable to find expected entry 'main/binary-armel/Packages' in Release file (Wrong sources.list entry or malformed file)

E: Some index files failed to download. They have been ignored, or old ones used instead.

Looking for a alternative method to install java.

-grayman4hire
======================================
Pogoplug V2 and V3 Serial Connection
Tutorial - Pogoplug v4 (Series 4 and Mobile) with Linux (Debian or Arch)
OpenWRT on Pogoplug Mobile
Tutorial - Pogoplug E02/V4 with Arch Linux ARM
Hacking the Pogoplug v3/Oxnas (Pro/Classic) with Debian
OpenWRT on Pogoplug v3/Oxnas (Pro/Classic)

@Jim, you're welcome.

@grayman4hire, that repo is maintained by www.webupd8.org, I posted the source as a link, probably give them a shout. That was "the easy way" to install oracle Java, it's also possible to download and install from Oracle themselves ...

Cheers

Don

Hello,

since a couple of days, crashplan keeps telling me, that it can't find the libjtux.to anymore. I recopied the arm version of it to its destination. And file is at the exact position, where crashplan is looking for it:

[07.17.16 01:41:28.803 INFO main om.code42.utils.SystemProperties] == MEMORY ; maxMemory=989,90MB
, totalMemory=23,50MB, freeMemory=8,40MB, usedMemory=15,10MB
[07.17.16 01:41:28.889 ERROR main com.backup42.service.CPService] Error starting up, java.lang.U
nsatisfiedLinkError: /usr/local/crashplan/libjtux.so: /usr/local/crashplan/libjtux.so: Kann die Shared-Obj
ect-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
STACKTRACE:: java.lang.UnsatisfiedLinkError: /usr/local/crashplan/libjtux.so: /usr/local/crashplan/libjtux
.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden


An ls on that path shows, that the file is there. And it has the same access rights as the other files in that folder.

Any ideas what they screwed this time?

I found a solution: The latest version of crashplan includes it's own libjni. You have to delete it from the installation folder to force crashplan to use the arm version from the system.

MPW Wrote:
-------------------------------------------------------
> I found a solution: The latest version of crashpla
> n includes it's own libjni. You have to delete it
> from the installation folder to force crashplan to
> use the arm version from the system.


Sounds about right, crashplan likes to "upgrade" itself every five minutes, so therefore things like the JNI may need putting back to "how we hacked it", or similar if newer ARM code is available ... x86/x64 JNI won't run on ARM, and I don't think crashplan plan to release an ARM version of crashplan, there docs say it can be done, but mileage may vary.

Don Charisma ... because anything is possible with Charisma

My blog - http://DonCharisma.org
Our commercial site - http://DonCharisma.com

It's a great post! Thanks for sharing)) What about an little bit another way? It involves an emulator. Learn here - https://eltechs.com/crashplan-on-raspberry-pi/

Oracle also offers an embedded headless JVM (registration required to download) that needs less space and ram. The Java 8 version needs to be extracted somewhere else first (i.e. real PC) and then built according to a profile (compact1/2/3/all) which adds more and more jars. "All" creates a full JVM (nashorn needs to be added with a switch). Then you copy that to your arm machine and create symlinks for the java executable. Done. I have done this to run OpenHab on a RaspberryPi 1 and there is a softfloat version available for Kirkwood systems.

Thanks @bastel and @Marry_Pi for suggestions, hope they might help someone :)

Don Charisma ... because anything is possible with Charisma

My blog - http://DonCharisma.org
Our commercial site - http://DonCharisma.com