[Milhouse]

Update 18-Oct-2013: Recent Gotham builds of OpenELEC no longer support auto-update when the boot device is remote (NFS, SMB etc.).

Given this change to auto-updating, plus the fact it didn't really work anyway (dumping the new kernel in the wrong place), and the limited benefit you actually get when booting OpenELEC via NFS - the only benefit I can think of right now is the geeky satisfaction that it works at all - I can no longer recommend using NFS for booting[ (ie. boot=NFS etc.).

However, I still believe NFS for /storage (disk=NFS etc.) is a good solution. So just follow the guide below, but leave boot=/dev/mmcblk0p1 and copy SYSTEM to your SD card FAT partition (alongside bootcode.bin, kernel.img etc. and not to your NAS), configure disk= to use NFS and all should be good.

---

I've been playing around with NFS booting, and discovered it's actually very easy to setup with a FreeNAS server (8.3.0-RELEASE).

Performance is good. Even booting from NFS is only marginally slower than from the SD card (about 35 seconds with class 10 SD card, 40 seconds over NFS with an ancient pre-Class system microSD card).

So, to set it all up....

On your NAS, create the NFS share with "All Directories" ticked, "Maproot User == root" and "Maproot Group == wheel". Once created, you should have an entry in /etc/exports similar to the following:

Code:

/mnt/share/OpenELEC  -alldirs -maproot=root:wheel

Note that the above is for a FreeNAS system which is based on FreeBSD - the /etc/exports file for Debian-based systems will have a different syntax.

Then, within the share on the NAS, create a "System" and "Storage" folder.

Within the System folder, copy in the OpenELEC SYSTEM file. That's all that needs to be in there. However, if you have multiple clients it might make sense to create individual client folders within the System folder so that each client can auto-update at their own pace (clients running older firmware may break if they pick up a newer SYSTEM file). So with multiple clients, create rpi#1, rpi#2 folders and within each of those folders copy in the SYSTEM file.

Within the Storage folder, if you have multiple Pi's you should create further sub-dirs for each client, eg. rpi#1, rpi#2 etc. Leave the folder empty so that it will be initialised by the R-Pi - later on you can create a backup and duplicate it for new clients (eg. restore a busted client back to "known good state" etc.).

On the Pi SD card, create a single FAT partition with the following files from the OpenELEC package:

Code:

bootcode.bin
cmdline.txt
config.txt
fixup.dat
kernel.img
start.elf

Note that you no longer require the SYSTEM file on the SD card, meaning the SD card can be as small as 8MB (though 16MB would be a more sensible minimum). Performance of the SD card is also now largely irrelevant, as it's only required during boot (and when updating the system software - a rare occurrence under normal circumstances).

Setup config.txt to your own requirements (overclocked, gpu mem, overscan etc. etc.).

Edit cmdline.txt, and specify the following to actually enable NFS booting (make sure it's all on one line):

Code:

ip=dhcp boot=NFS=192.168.0.200:/mnt/share/OpenELEC/System/rpi#1 disk=NFS=192.168.0.200:/mnt/share/OpenELEC/Storage/rpi#1 ssh

where 192.168.0.200 is my FreeNAS server - change to match that of your own server, also the NFS mount point.

Then boot your Pi, as that's all there is to it.

Unfortunately (as of OpenELEC Beta 6), auto-update is not currently working correctly with NFS boot (issue #1653) but other than that, NFS booting is a pretty good solution as it makes the system a lot more resilient to SD card corruption (since there are now no SD card writes, except when updating system software - disable auto-updates to prevent ALL SD card writes), boot performance is still very good, you can use any old SD card (even the smallest, slowest you have lying around - no need for uber-fast or large capacities etc.), and it simplifies backups and new client setup (just duplicate the Storage folder of an existing client).

Conceivably, a simple cron job running on the FreeNAS server could be used to rsync the Thumbnails and Textures15.db from a "master" client to "slave" clients and keep all of them in sync. I'm using MySQL for the library, so that takes care of centralising meta-data, but otherwise you might be able to sync the other MyMusic/MyVideo databases from the master to slaves, as that might also work. Maybe. Definitely not tested, etc. etc.

One other wrinkle with NFS booting on OpenELEC, is that connmand (the network connection manager) on the Pi will write to syslog (/var/log/messages) every 17 minutes as it updates the time (ntp). Since the logs are now located on the NAS, this log activity prevents the NAS from spinning down its disks. So, to silence ntp and allow the NAS to spin down its disks you can add the following to each Pi:

1) On the Pi in the .config folder, run the command "cp /etc/syslog.conf ." to create a copy of syslog.conf that we can modify

2) Edit ./syslog.conf so it looks like the following - basically, we're adding an entry for the daemon.info facility (used by ntp) so that log entries are written to /dev/null (ie. discarded), and we're also ignoring auth.debug messages (SOA DNS etc.) for good measure:

Code:

# all daemon.info and auth.debug to be discarded - ntp, SOA etc.
daemon.info;auth.debug      /dev/null

# all messages of kern and user facilities
kern,user.*      /var/log/messages

# all messages of kern facility with priorities lower than err (warn, notice ...)
kern.!err            /var/log/critical

# all messages with auth and authpriv facilities, except auth.debug which is ignored
auth,authpriv.*;auth.!=debug      /var/log/auth

Now, ntp updates will be discarded, giving the NAS a better chance of spinning down its disks when RPi clients are idle.