[Chris83]

Just wanted to report that I also did a fresh install of the RC3 release and everything is up and running again.
Used the RPi B+ and had no issues with network others reported earlier.
After flashing the image and cloning to USB I tried to update and hit the libc6 dependency error.
I know there is apparently a reason (which nobody dares to specify) why it is held back, but I rather do another reinstall than having sleepless nights knowing there are updates waiting in the queue ^^
So I went ahead and installed these two:
https://archive.raspbian.org/raspbian/pool/main/e/eglibc/libc6_2.13-38+rpi2+deb7u3_armhf.deb
http://ftp.de.debian.org/debian/pool/main/s/systemd/libsystemd-login0_44-11+deb7u4_armhf.deb

Afterwards I proceeded with updates via xbian-config and everything went through smoothly (but also had to do the locales reconfig) - nothing left in the update queue :-)
Also installed python, flexget and transmission.

Two things I picked up:
1. Before I started the clone I deleted existing partitions on the USB drive and created two fresh NTFS partitions it. Cloning to the first, small partition sda1 broke something in the file system of sda2. Windows repair was able to fix the partition on sda2 but a video file which I put there intentionally for testing before cloning was gone for good. Now the btrfs partition on sda1 seems to be working fine under Xbian, and the sda2 partition seems to be working fine under both Windows and Xbian. I'm thinking something on the MBR got damaged when xbian converted the NTFS partition on sda1 to btrfs? Maybe that needs some testing/analyzing by someone who knows what he is doing.

2. I spend around 4h (yes I'm an absolute beginner on Linux) trying to figuring out why I did not have write access on the Samba share located under /media/LABEL (mounted by /dev/sda2).
writing was possible on all the other default shares (except of course /var/logs, to which I also only could write with root via SSH). But not on the NTFS drive and I also had write access there via ssh - just not via Samba.
I finally figured out this was caused by the Samba options in /etc/usbmount/usbmount.conf. Did the standard entries change since the Beta2 release? I'm quite sure I never had to edit them before (but before that my USB share was on a btrfs filesystem). I think this should be changed. Rather have standard configs for Samba which encourage password protected access and have an initial, easily identifiable write protection in /etc/samba/shares.conf than hiding a Samba write protection in /etc/usbmount/usbmount.conf. I'm sure I did a lot of awful things to the security settings trying to get rid of it.