@Karen
You can grab any howto google will show you. XBian is pack of extra programs on top of Raspbian which is Debian which is linux. There are no custom mods / special roots as with RaspBMC or OpenELEC so the NFS root is straight forward.
You take image or your current setup. Copy all files with rsync to NFS exported directory (on server side "no_root_squash" parameter is needed. on the other hand, export can't be "insecure" - as uid=0 needs to be effectively transmitted over the mount. for client side mounting "nolock" is normally needed for NFS below ver 4). In general:
1) prepare export on NAS
2) boot XBian, mount this export and copy files
a) rsync -avx --delete --progress / /mnt/export/from/NAS/
b) rsync -avx --delete --progress /home/ /mnt/export/from/NAS/home/
c) rsync -avx --delete --progress /lib/modules/ /mnt/export/from/NAS/lib/modules/
3) XBian can without mods boot from NFS directly from loaded kernel. The modifications in cmdline.txt are:
a) root=/dev/nfs
b) remove "rootfsopts=.*" and add "nfsroot=IP:/export/dir,mountoption1,mountoption2,…" - with Beta2 omit the nolock "nolock" there - it is needed but kernel will use it when NFS root is specified and somehow with 3.10.x kernel it takes "nolock" as wrong mount option specified (no idea if bug or specs changed, but ok). usually the mountoptions are specifying if it UDP or TCP mount and wsize/rsize for buffer size specs.
c) change rootfstype=btrfs to rootfstype=nfs
4) remove /home and /lib/modules from /etc/fstab
5) turn snapshot on APT operations off as this would make all APT operations to fail
reboot.
if server part would be standard NFSd implementation as with linux, it will boot. I bet 10usd. with NAS systems there are sometimes issues - not supporting no_root_squash, not supporting secure link etc. or supporting them, but with different syntax (probably those with OpenBSD core).
if you face issues, gain any howto forum for general linux will do, there is no difference.
there are some XBian specifics related to it's functions which will fail, generate failed upstart events etc (restore-home service, auto snapshots, APT snapshots). they are tight to btrfs filesystem functions / properties which will not be available but this will not affect XBian's main function as media player. As I had zero reports of using NFS, there was no priority to fix them. But probably will do it for Beta3 together with cloning functionality similar to the one already present but for NFS (current xbiancopy won't work as this is using internal btrfs functions to allow atomic freeze and transfer of rw mounted filesystem). Also during updates (specially xbian-update) you will get some minor errors reported - but they won't fail updating,
There was a guy already trying this with Beta2, but he failed - most likely due to NAS issues. I don't use NFS root either anymore because the development but when he was asking about it, I checked it as well and it worked. the discussion starts somewhere here
http://forum.xbian.org/thread-1312-post-15733.html#pid15733
If you would like to use ONE export for more RPIs, this is in general supported and reason why NFS exists, but you have to consider few points:
1) as there will be no server side locking available with NFS2/3, mounted rootfs must not be accessed with RW privileges (as with logging as root from CLIENTS)
2) for doing updates probably easiest strategy would be to define RPI which will be used for this by logging as root. Leaving the others to just use the rootfs for reading
3) you would need to create extra xbian like user for each RPI to avoid conflicts with .db files present (sqlite3 is not providing sharing feature) - second option is to share xbian home dir, but move libraries to central MySQL.
4) one day if we deploy 100 RPIs to our homes, we will do it as it should be with rootfs on NFS really mounted RO, and local /var, maybe /usr (to allow local programs installation) etc. but makes no sense for two thin clients. ;-)
report back if you managed it.
