OpenELEC NFS Booting How-To
#16
(2013-01-09, 23:30)mylle Wrote: 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?

I've not actually got a 16MB SD card, but in theory it should work (as in: that's all the storage space required) however a memory card with such a capacity would be pretty old - are you sure the 16MB card you have is actually an SD card, and not MMC? MMC as a standard was superseded by SD, and consequently MMC may not work so well with Pis which are designed for SD cards.

According to Wikipedia, the earliest SD cards had 32MB capacity, though its possible some 16MB cards were also released. I guess the easiest way to tell would be to count the number of pins on the card - 8, 9, or 11 for SD, 7 or 13 for MMC.
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
#17
Ah. It might be just that. I have not checked. I just read your guide and remembered that i had an old 16mb card in my desk drawer Smile It works fine in the SD card slot on my laptop. I will have to check when i get back home. Thanks for your help!

/Jacob
Reply
#18
Thanks for the HOWTO. Just a note for others that might run into an issue. I had trouble with DHCP. It wouldn't manage to get an address and the boot would, of course, fail. Using the info from NFS root howto I set up an ip= setting for my network and it boots up great now.

I had an existing setup I wanted to preserve, but that was easy. Backup /storage/.xbmc and /storage/.config and copy them to the new nfs root after OpenELEC boots for the first time and sets up the directories.

DHCP server is built into my Linksys E4200 router, and works fine in every other instance. Even the stock run-from-SD OpenELEC. No idea why it doesn't work with the ip=dhcp for NFS booting.

Code:
ip=10.1.0.33:10.1.0.2:10.1.0.1:255.255.255.0:BedPi:eth0:off

From the NFS root doc:

Code:
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
Reply
#19
What is the benefit of running from an nfs share? Are there performance improvements?
Reply
#20
There's some performance boost, at least in comparison to using a class 4 SD card.

My initial reason for looking at it is that I'm somewhat scared about the life expectancy of an SD card: the first hit on Google suggests 100,000 write cycles (to each individual page of storage). Which is obviously fine for relatively static data with large files, but I'm more nervous when it comes to things like swap files and databases which could change thousands in the space of just a few minutes.

However, the reason I've done it is for file system stability: I've got my Pi powered from my television's USB port, so it powers up with the TV, and, more significantly, crashes instantly when I turn the TV off, potentially aborting in the middle of a write to the file system. Off loading that to a NAS drive removes the problem, as the file server stays up: it might still abort mid-way through writing a file, but at least the directories are properly maintained.
Reply
#21
(2013-02-20, 16:24)bilbonvidia Wrote: What is the benefit of running from an nfs share? Are there performance improvements?

As wimble points out you may experience improved performance compared with a slow SD card, and you reduce the chance of SD card corruption by moving to NFS, particularly as SD corruption becomes more likely when overclocking. In fact, moving from SD to NFS/SMB/USB is often the only way some people can overclock their Pis.

Making backups, restoring those backups, and synchronising content across multiple clients (eg. single master, multiple slaves) is also much easier to accomplish when using NFS.
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
#22
Sounds interesting as every attempt I have made to overclock has failed, but then again it failed when I installed to a usb will I stand more of a chance with nfs?
Reply
#23
No, if you had no luck with USB you'll have no more luck with NFS. Unusual though not to achieve any kind of overclock with USB.
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
#24
Anyone know what I need in the exports for HaneWin NFS?

I've tried

e:\NFS rw,async,no_root_squash,no_all_squash,no_subtree_check

but that gives a "line ignored, invalid client" error. Above that I've got two other lines which seem OK

e:\Media -readonly -public -name:Media

-maproot:0:0 -mapall:0:0
Reply
#25
(2013-02-27, 00:09)doveman2 Wrote: Anyone know what I need in the exports for HaneWin NFS?

I've tried

e:\NFS rw,async,no_root_squash,no_all_squash,no_subtree_check

but that gives a "line ignored, invalid client" error. Above that I've got two other lines which seem OK

e:\Media -readonly -public -name:Media

-maproot:0:0 -mapall:0:0

This post any good to you?
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
#26
Thanks but that doesn't really give me equivalent options for most of the switches. It seems I probably don't need to specify rw as that's the default unless -readonly is used.

That post links to the one I referred to orginally for the NFSBoot setup and maybe I misunderstood that, as under HaneWin it says

"make sure you select "async write","no count of sub-dirs", "allow unix style soft links", "emulate hard links" in the nfs server options." which I've done, so that probably covers the async and no_subtree_check switches. I'm not sure about the no_root_squash and no_all_squash switches though.

So maybe I just need

e:\NFS -public -name:NFS

and then I can use

boot=NFS=192.168.1.64:/NFS/OpenElec/System

in cmdline.txt

EDIT: Hmm, tried that and now I get an error "ignored, expected drive" about the -maproot:0:0 -mapall:0:0 line

EDIT2: Ah, I see those are meant to be switches for the NFS share. Putting them on the end of the E:\NFS line and it seems to be OK now (haven't tested booting from it yet but no errors at least).
Reply
#27
the switch "-alldirs" was important to me.
Reply
#28
Interesting, thanks. I'll add that to avoid any problems then.
Reply
#29
If you do not add that switch you can ONLY mount the mountpoint that you have specified in the export file and not folders inside it. I have 4 RPI's running of NFS and i have to mount

/mountpoint/rpi1
/mountpoint/rpi2
/mountpoint/rpi3
/mountpoint/rpi4

It was failing at first because it would only mount /mountpoint/ and not the folders after that!
Reply
#30
Gotcha. I have several folders under E:\NFS that I'll be using as well so I'll need that switch. Thanks for the tip.
Reply

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