Arch Linux User Repository

I'm going to be disowning this package soon. I'm moving away from crashplan and have no interest in maintaining this package, and dealing with usage issues, when I wont be using it.

I'll keep it up to date during the coming months as needed, but if no one else shows up, I plan to disown it at the end of October.

@gadicc, I added some pacman hooks to handle setting/unsetting the immutable flag:

Sets immutable flag after install/upgrade:

[Trigger]
Operation = Upgrade
Operation = Install
Type = Package
Target = crashplan-pro

[Action]
Description = Set immutability of Crashplan Pro upgrade directory
When = PostTransaction
Exec = /usr/bin/bash -c "rm -rf /opt/crashplan/upgrade/*; chattr +i /opt/crashplan/upgrade"`

Unsets immutable flag before upgrade/remove:

[Trigger]
Operation = Upgrade
Operation = Remove
Type = Package
Target = crashplan-pro

[Action]
Description = Undo immutability of Crashplan Pro upgrade directory
When = PreTransaction
Exec = /usr/bin/bash -c "chattr -i /opt/crashplan/upgrade"```

Sorry for the delay! A mix of the summer holidays, and switching to an arm platform, which I am still trying to work out how to convert this package for.

Manually applied the PKGBUILD patch from achilleas.k and was able to install the upgrade. Still awaiting an updated package in the AUR, but this will get my backups caught up for now. Thanks!

Very nice patch @achilleas.k. Thank you.

Patch for latest version (10.2.0)

diff --git a/PKGBUILD b/PKGBUILD
index 75b1458..e12ae89 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -2,9 +2,9 @@
 # <billyburly [at] gmail [dot] com>
 pkgname=crashplan-pro
 _pkgname=crashplan
-pkgver=10.0.0
-_pkgtimestamp=15252000061000
-_pkgbuild=303
+pkgver=10.2.0
+_pkgtimestamp=15252000061020
+_pkgbuild=14
 pkgrel=1
 pkgdesc="An business online/offsite backup solution"
 url="http://www.crashplan.com/business"
@@ -20,9 +20,9 @@ source=(https://download.code42.com/installs/agent/cloud/${pkgver}/${_pkgbuild}/
         upgrade.sh
         crashplan-pro_upgrade.service
         crashplan-pro_upgrade.path)
-sha1sums=('713a58ae2977fa22e85a6b3f3a845b74bfe6908e'
+sha1sums=('7fa6dc6c5338501bc4f63f2915f0d5420de25197'
           'f73e2b1155744594303d81b394031159e248654c'
-          'a3a5ead8b8fd867f47782b12bc27b1fb145565ac'          
+          'a3a5ead8b8fd867f47782b12bc27b1fb145565ac'
           'c24e2ba2b2d6831246ea4af072305ddf5d1fd774'
           '0dfbf0ef3df2ad386419def132c28d63560f6e4e')
 options=(!strip)

This package is out of date so until the maintainer has time to update it here are the manual upgrade instructions. Note that there's an unusual problem with this CrashPlan release that is causing even supported distros to crash when running it. The problem is a missing libuaw.so library, but I'll show you how to fix that as well.

First of all modify the following PKGBUILD lines:

pkgver=10.0.0
_pkgtimestamp=15252000061000
_pkgbuild=303
sha1sums=('SKIP'

Now modify the following .SRCINFO lines (the "source" and "sha1sums" changes are to the first ones encountered):

pkgver = 10.0.0
source = https://download.code42.com/installs/agent/cloud/10.0.0/303/install/CrashPlanSmb_10.0.0_15252000061000_303_Linux.tgz
sha1sums = SKIP

Now you can build and install the package as normal. However, don't start the crashplan-pro service yet. First you have to extract and copy the missing libuaw.so to the installation as follows:

mkdir ~/temp; cd ~/temp
gzip -dc <your pkg dir>/crashplan-pro/CrashPlanSmb_10.0.0_15252000061000_303_Linux.tgz
cd code42-install
gzip -dc CrashPlanSmb_10.0.0.cpi | cpio -i
sudo cp ~/temp/code42-install/nlib/ubuntu20/libuaw.so /opt/crashplan/nlib/

That's it, now you can start the crashplan-pro service and everything should work correctly.

This morning, my crashplan-pro_upgrade fails every time with Failed with result 'signal'. No idea what that means, but I'm continuing to investigate.

I saw the same thing in the journal @torpe23, and discovered that 'PropogatesReloadTo' is misspelled, and should be 'PropagatesReloadTo'.

However after correcting the spelling and rebooting there is still a message in the journal that says 'crashplan-pro.service: Job paths.target/start deleted to break ordering cycle starting with crashplan-pro.service/start', though the key error is now gone.

So there may still be a startup ordering problem, though it's not immediately clear to me what it would be. On the other hand, while quickly searching for the problem it seems that sometimes the message can be a cosmetic error.

So hopefully someone with more systemd experience than I can give us a definitive answer. And if it's a problem, a solution.

Systemd is complaining during boot:

$ journalctl -b
Feb 19 18:26:32 courcelle systemd[1]: /usr/lib/systemd/system/crashplan-pro_upgrade.service:6: Unknown key name 'PropogatesReloadTo' in section 'Unit', ignoring.
Feb 19 18:26:32 courcelle systemd[1]: NetworkManager.service: Found ordering cycle on basic.target/start
Feb 19 18:26:32 courcelle systemd[1]: NetworkManager.service: Found dependency on paths.target/start
Feb 19 18:26:32 courcelle systemd[1]: NetworkManager.service: Found dependency on crashplan-pro_upgrade.path/start
Feb 19 18:26:32 courcelle systemd[1]: NetworkManager.service: Found dependency on crashplan-pro.service/start
Feb 19 18:26:32 courcelle systemd[1]: NetworkManager.service: Found dependency on network.target/start
Feb 19 18:26:32 courcelle systemd[1]: NetworkManager.service: Found dependency on NetworkManager.service/start
Feb 19 18:26:32 courcelle systemd[1]: NetworkManager.service: Job paths.target/start deleted to break ordering cycle starting with NetworkManager.service/start

Seems like there's an error in one of the key (PropogatesReloadTo instead of PropagatesReloadTo). I don't know if that's what creates the cycle or if it's something else.

Having added a dependency on SLF4J, and done a pacman -Syu everything seems to be behaving again...

Interestingly, there seems to still be an error on start up, but then the service carries on happily

@legodfrey Yes, I see the same thing in my service.log.0. Keeps on running it seems after that.

Not backing up yet though, because its doing block synch now 'cause I am back.

Forgot about the hassle to setup a writable cifs mount in LXC (thats where my docker containers live)

Hopefully you can fix the issue

[01.27.22 18:33:56.716 INFO  main         Code42CryptoProviderConfigurator] Explicitly setting jdk.tls.client.protocols to TLSv1.2.
[01.27.22 18:33:56.716 INFO  main         Code42CryptoProviderConfigurator] Explicitly setting jdk.tls.server.protocols to TLSv1.2.
[01.27.22 18:33:56.716 INFO  main         Code42CryptoProviderConfigurator] Explicitly setting https.protocols to TLSv1.2.
[01.27.22 18:33:56.727 ERROR main                                         ] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
[01.27.22 18:33:56.727 ERROR main                                         ] SLF4J: Defaulting to no-operation (NOP) logger implementation
[01.27.22 18:33:56.728 ERROR main                                         ] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
[01.27.22 18:33:57.697 INFO  main         Code42CryptoProviderConfigurator] Added Bouncy Castle FIPS provider
[01.27.22 18:33:57.862 INFO  main         Code42CryptoProviderConfigurator] Added Code42 Non-FIPS Provider.