Last Sunday, I updated my home UrBackup server to 2.4.9 (on Debian Buster). Since then, most of my clients (all Linux, mostly Debian) have stopped working. I’ve just updated to 2.4.10 about 30 minutes ago as I try to solve the problem, but this didn’t help.
The clients that did remain working are all still running older versions of the client - 2.3.4 and 2.1.15. All the ones listed as 2.4.8 are failed.
Also notable is that all the failed 2.4.8 clients are showing up under different names in the server… Previously, most clients were listed as their FQDN (which I prefer), but the failed ones have all been duplicated. They now show up as a short hostname instead, with a different backup set for each entry. Yes, both come up as offline.
I have got one of the clients to start working again. After updating the server to 2.4.10, I found an old 2.2.6 installer on the client I was fiddling with. Since it was a client-specific installer downloaded from my server for that client, I figured it couldn’t hurt, and installed it… This allowed the client to reconnect (using it’s old FQDN name) and start a backup. However, the client then suddenly went offline again.
It turns out the client updated itself to 2.4.8 again. I had turned off automatic updates, so this was a little surprising, however I manually restarted the client (it failed to start after the update), and it appears to be working OK again.
I guess my question now is… What do I do with the other 15 or so failed clients? Should I go through one by one downloading the custom installer for each client?
Adding to this again - the client that re-updated to 2.4.8 disappeared again shortly after my initial post.
I have now manually downloaded client update files for 2.4.9 and created the install package for my test client, which failed in even more spectacular fashion:
root@bob:~# sh UrBackup\ Client\ (bob.home)-2.4.9.sh
Verifying archive integrity… All good.
Uncompressing UrBackup Client Installer for Linux 100%
Installation of UrBackup Client 2.4.9 to /usr/local … Proceed ? [Y/n]
Uncompressing install data...
Detected Debian (derivative) system
Detected architecture i686-linux-android
Illegal instruction
Error running executable on this system (i686). Stopping installation.
What’s the go with it listing android? And why does it think 32 bit is a no-go? Has 32 bit been dropped or is this a broken platform detection script?
However, manually downloading the client update files for 2.3.4 has got me going again. Something has definitely been broken in the Linux client between 2.3.4 and 2.4.8.
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “i686-linux-gnu”.
Type “show configuration” for configuration details.
For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/.
For help, type “help”.
Type “apropos word” to search for commands related to “word”…
Reading symbols from /tmp/urbackup_installer/i686-linux-android/urbackupclientbackend…done.
run
(gdb) run
Starting program: /tmp/urbackup_installer/i686-linux-android/urbackupclientbackend --version
Program received signal SIGILL, Illegal instruction.
0x08640dbf in chacha_encrypt_bytes (x=0xf7ff6008, m=0xf7ff6048 “”, c=0xf7ff6048 “”, bytes=1024) at bionic/libc/upstream-openbsd/lib/libc/crypt/chacha_private.h:143
143 bionic/libc/upstream-openbsd/lib/libc/crypt/chacha_private.h: No such file or directory.
(gdb) bt #0 0x08640dbf in chacha_encrypt_bytes (x=0xf7ff6008, m=0xf7ff6048 “”, c=0xf7ff6048 “”, bytes=1024) at bionic/libc/upstream-openbsd/lib/libc/crypt/chacha_private.h:143 #1 _rs_rekey (dat=, datlen=) at bionic/libc/upstream-openbsd/lib/libc/crypt/arc4random.c:125 #2 0x08640a49 in _rs_random_buf (_buf=, n=4) at bionic/libc/upstream-openbsd/lib/libc/crypt/arc4random.c:161 #3 arc4random_buf (buf=0x8811ebc <__stack_chk_guard>, n=4) at bionic/libc/upstream-openbsd/lib/libc/crypt/arc4random.c:195 #4 0x08692efd in __libc_safe_arc4random_buf (buf=0x8811ebc <__stack_chk_guard>, n=4) at bionic/libc/bionic/bionic_arc4random.cpp:44 #5 0x086433ac in __libc_init_main_thread_late () at bionic/libc/bionic/__libc_init_main_thread.cpp:104 #6 0x086257f2 in __real_libc_init (raw_args=, onexit=, slingshot=, structors=0xffffdcd8, temp_tcb=0xffffdc80) at bionic/libc/bionic/libc_init_static.cpp:178
Finally got around to checking that - seems to work fine on both 32 and 64 bit containers on the AMD server.
Edit: Correction - the 32 bit one is still running the client, but it’s now showing offline in the web GUI, and seems to not be doing anything. The server is doing a nightly cleanup though, so could that stop it showing up if it’s done the “I’m a new client” thing?