OpenELEC NFS Booting How-To
#1
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.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#2
Nice HOWTO.
Reply
#3
(2012-12-26, 18:12)gimli Wrote: Nice HOWTO.

Thanks, I hope it will be useful to other people - I was quite surprised how easy it was to setup, I suppose mainly because of the way OpenELEC works, and only investigated it as another alternative to SD card corruption (mounting the rootfs on USB being the other alternative) but think I might stick with NFS longer term now. So far the auto-update issue is the only real downer, hopefully it can be addressed before release.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#4
Yup. Definitely useful. I've got one Pi booting Raspbian from my NFS server, and was trying to follow the OpenElec instructions ( http://wiki.openelec.tv/index.php?title=...Boot_-_NFS ) which require setting up a tftp server (and possibly nfs-kernel-server, which is a bit tricky when you're booting from a commercial NAS. Although I'm also insufficiently knowledgeable to know whether it's different from normal NFS, or just a specialised subsection.)

And then, luckily, I found your instructions, which are much, much simpler (and are analagous to the Raspbian configuration). You've turned much head-scratching and confusion into a five minute job.

To be honest, I'd move the "rpi#n" element one step up the path, so you've got "../rpi#1/System" and "../rpi#1/Storage" immediately next to each other, rather than grouping all the Systems together, and the Storages together. But to each, their own Smile
Reply
#5
(2012-12-29, 04:17)wimble Wrote: Yup. Definitely useful. I've got one Pi booting Raspbian from my NFS server, and was trying to follow the OpenElec instructions ( http://wiki.openelec.tv/index.php?title=...Boot_-_NFS ) which require setting up a tftp server (and possibly nfs-kernel-server, which is a bit tricky when you're booting from a commercial NAS. Although I'm also insufficiently knowledgeable to know whether it's different from normal NFS, or just a specialised subsection.)

And then, luckily, I found your instructions, which are much, much simpler (and are analagous to the Raspbian configuration). You've turned much head-scratching and confusion into a five minute job.

Glad I've been of help!

The OpenELEC wiki instructions apply to a regular PC, and are liable to confuse anyone coming at the problem with a Raspberry Pi. The Pi is so much easier to get going than a PC - none of this PXE/tftp booting nonsense! Smile

I briefly looked at the Raspbian NFS boot instructions but rapidly lost interest when it started mentioning loopback devices etc., but realise it's probably overcomplicating matters and a straight copy of the ext4 partition to a folder on the NAS should be sufficient. Though to be honest I'm quite happy with my Raspbian headless server running from it's fast 32GB SD card, particularly as it's perfectly stable and suffers no SD corruption despite being overclocked to the max. Plus, the whopping £20 I laid out on the SD card is a sunk cost! Smile

OpenELEC on the other hand is far more amenable to booting from NFS (as it loads entirely into RAM etc.) and also because, lets be honest, it's pretty keen on munching SD cards at every opportunity so avoiding writes to the SD card when at all possible seems like the best option. If necessary I'll even disable auto-updates (hopefully auto-update will support NFS booting for RC1 - I've offered a patch to the OE developers).

While testing OpenELEC Beta 6 I've had several system hangs that I know with absolute certainty would have required a full re-format of the ext4 SD partition, but when booting from NFS the system has come back up without a hitch.

I've also got into a situation where I had a decent Movie library set up, then spent several hours scraping a music library (scraping Music is a very slow process) only to find it impossible to replace specific artwork due to dumb caching rules etc. (just try replacing a cover.jpg thumb with a newer, better, version and watch XBMC ignore the new content - frustrating!) The solution, however, was easy - just restore the known-good backup I took prior to initiating the Music scan, and kick off another Music scan, this time with the new artwork in place on the NAS.

(2012-12-29, 04:17)wimble Wrote: To be honest, I'd move the "rpi#n" element one step up the path, so you've got "../rpi#1/System" and "../rpi#1/Storage" immediately next to each other, rather than grouping all the Systems together, and the Storages together. But to each, their own Smile

Yeah, that could work, it's certainly a change I might consider myself! Smile
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#6
Does anybody have problems with audio passthrough and video resolution when booting from NFS? I can't change from 720p and audio is not working over HDMI. I'm using OpenELEC.
Reply
#7
Working fine for me (Beta 6).
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#8
I'll wait for the next beta/RC and test again. I think I'm currently using one nightly build that is working good for me from SD, but not over NFS. Also the latest nightly is not working.
Reply
#9
EDIT

Nevermind. Should learn to read first. great tutorial
Reply
#10
I have 4 rpi's and was kinda waiting for this fix to be implemented before trying out the solution

https://github.com/OpenELEC/OpenELEC.tv/issues/1653

Any news on when this will be merged?

regards
Jacob
Reply
#11
No feedback as of yet. It's a bit late in the day for such a patch but since without it an update (auto or manual) will break a working system I'm hopeful it will be included before release.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#12
I updated mine by hand, with no problems.

Download the new tar file, and untar it. From within the resulting directory copy target/SYSTEM over the system/SYSTEM file on your NFS server, and copy the target/KERNEL file to the storage directory.

Then SSH into the Pi. You'll now be seeing the content of the storage directory, so the KERNEL file should be visible. Move this to /var/media/System/kernel.img, overwriting the existing file (this directory is the boot partition).

And then reboot.

Actually, thinking about it, it's probably better to do all the work on the KERNEL file first, as that's only read in the boot process, where as the SYSTEM is the the entire filesystem of the running XBMC process, so it rebooting as soon as possible after rewriting it minimises any possible instabilities. However, I did the the SYSTEM file first, because I was doing all the NFS server work, and hadn't thought it through.

The patch will be easier, but this wasn't particularly hard, compared with getting the NFS set up working in the first place Smile
Reply
#13
You're forgetting about the Raspberry Pi firmware - bootcode.bin fixup.dat, start.elf. You'll find these in /usr/share/bootloader of the new SYSTEM file. So, once you've booted into the new SYSTEM, you should cp those three files to /var/media/SYSTEM and reboot again.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#14
(2013-01-09, 02:39)MilhouseVH Wrote: You're forgetting about the Raspberry Pi firmware - bootcode.bin fixup.dat, start.elf. You'll find these in /usr/share/bootloader of the new SYSTEM file. So, once you've booted into the new SYSTEM, you should cp those three files to /var/media/SYSTEM and reboot again.

Ah, fair point. Of course, that's only necessary if you actually need to update the firmware! I'd actually done this separately, by plugging in a Raspbian SD card, and running rpi-update. But that does demonstrate the usefulness of your OpenELEC patch Smile
Reply
#15
Just tried it out. Works great with 2 of my 8gb cards but icannot get it to work with a 16mb card. Its just not booting or doing anything at all. Any idea as to what could be wrong?
Reply

Logout Mark Read Team Forum Stats Members Help
OpenELEC NFS Booting How-To1