blog.crox.net

Despite having read the opposite, it looks like IPv6 is disabled by default on the latest OSMC release (2015.06-1). I've tried adding a sysctl.d file to set /proc/sys/net/ipv6/conf/eth0/disable_ipv6 to 0, but this did not help. It worked only when I ran the command manually. By going through numerous forum posts I eventually found out that you need to use the connmanctl CLI tool:

root@osmc:~# connmanctl
connmanctl> services
*AO Wired                ethernet_b827ebaabbcc_cable
connmanctl> config ethernet_b827ebaabbcc_cable --ipv6 auto preferred
connmanctl> quit
root@osmc:~# 

This enables IPv6 with autoconfiguration, turns on Privacy Extensions and prefers these ephemeral addresses over the autoconfigured ones.

The same command works for wireless as well, you just need to select the appropriate interface (the service name will start with wifi_).

"help" will display basic usage info.

If for some reason you would like to disable IPv6, the command would be "config ... --ipv6 off".

While trying to restore two files with BackupPC I got the following error message:

Remote[1]: Internal hashtable error: illegal key supplied!
Remote[1]: rsync error: errors with program diagnostics (code 13) at hashtable.c(65) [Receiver=3.0.9]
Read EOF: 
Tried again: got 0 bytes
Done: 2 files, 760646 bytes
restore failed: Unable to read 4 bytes

Other restores worked flawlessly. All hosts involved were running the same version of Debian Linux, with the same version of rsync. The same two files could be restored as a zip file from the BackupPC web front-end.

After spending some time on the issue with a colleague we eventually found the explanation, albeit not the solution: one of the files was a hard link. It looks like we hit a bug similar to what is described here: http://sourceforge.net/p/backuppc/mailman/message/20762995/

> This results in one subtle bug that can't be easily fixed: if you
> switch the Xfer method from tar to rsync, old backups that have
> hardlinks stored with tar won't be correctly restored with rsync.
> The workaround is generate a tar file and extract it, or switch
> the Xfer method back to tar before you do the restore.

We did not switch Xfer method (we've always used rsync over ssh). Possibly the issue was caused by attempting to restore two hard links to the same file at once - more testing would be required to confirm this.

This works for me:

usb_modeswitch -W -c 12d1:156a -v 12d1 -p 1597

(after having unpacked /usr/share/usb_modeswitch/configPack.tar.gz to a temporary directory)

Update 2016-01-19: back in 2014 I reported this to the maintainers of various "modeswitch databases", and it seems it's made it's way into the Debian/Ubuntu version at least, according to the changelog (version 20151101-1).

(it should work with any other Debian-based Raspberry Pi distribution and all newer Fitbit devices that use BLE)

sudo -i
apt-get update
apt-get install python-pip
pip install galileo
galileo

You can then use cron or a simple shell script to periodically run galileo.

This has been bugging me for quite some time...

The solution:

$ sudo ln -s /usr/share/virtualbox /opt/VirtualBox

Found here.