OpenELEC NFS Booting How-To
#31
Well I've got it booting with the following cmdline.txt

boot=NFS=192.168.1.64:/NFS/OpenElec/System disk=NFS=192.168.1.64:/NFS/OpenElec/Storage ssh quiet ip=dhcp textmode

However, even though my router shows it's registered on 192.168.1.68, I don't have any SSH/WinSCP access to it. I note it gives two warnings on booting about Unprotected Private Key File because the permissions 0644 are too open and therefore the keyfile will be ignored. Obviously this is because Windows doesn't have Linux-style permissions but that shouldn't really matter otherwise no one else would have got this working.
Reply
#32
Hmm, perhaps not. If I remove textmode from the commandline, I get

Error in mount_flash: mount_common: could not mount 192.168.1.64:/NFS/OpenElec/System

my export is

e:\NFS -public -maproot:0:0 -mapall:0:0 -alldirs -name:NFS

(2013-02-19, 06:25)ttabbal Wrote: 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>

Thanks for the tip, that got it working for me Smile

I'm using a Thompson 585v7 router, so it's obviously not a router-specific problem.
Reply
#33
My export looks like this:

E:\openelec -public -alldirs -name:openelec

and my cmdline.txt:

ip=dhcp netboot=nfs boot=NFS=192.168.1.50:/openelec/System/rpi1 disk=NFS=192.168.1.50:/openelec/Storage/rpi1 nomodeset ssh debugging
Reply
#34
I read somewhere that netboot=nfs doesn't do anything on the RPi. The original guide also definitely specified -maproot:0:0 -mapall:0:0 for the export but if yours is working without it, maybe that's wrong.

Anyway for me, as for ttabbal, the trick was to manually set the IP address.
Reply
#35
(2013-02-27, 20:02)doveman2 Wrote: I read somewhere that netboot=nfs doesn't do anything on the RPi.

You're right, it doesn't. I included it erroneously in an earlier version of the first post but removed it once I realised it served no purpose.
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
#36
I've got 3 pis and would like to be sure they all update at approximately the same time. Is there a way to share 1 update directory and just issue sequential reboots?
Reply
#37
(2013-02-28, 06:12)jabbera Wrote: I've got 3 pis and would like to be sure they all update at approximately the same time. Is there a way to share 1 update directory and just issue sequential reboots?

No, you can't share the .update folder as it is located within the /storage folder, each of which will specific to your 3 Pis. Plus, and assuming you where sharing a single /storage folder between all your Pis, the first Pi to apply the update will delete the update files so that it doesn't enter an "update loop", preventing the remaining Pis from updating.

I suppose you could set each of the Pis to "manual" update, extract the target SYSTEM+KERNEL+MD5 files from a the new package and copy them into the .update folder for each Pi, and they Pi's will update when they next reboot.

Or, have one of the Pi's set to auto-download ("auto" update mode) so that it downloads the new update, and run a script on your NAS server that watches for new files in the .update folder of this Pi and, when they appear, copies them to the .update folder of the other two Pis (these would both be set to "manual" update).
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
#38
(2012-12-26, 18:07)MilhouseVH Wrote: 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

3) Create an autostart.sh script that will replace the system default syslogd with a syslogd using our new config:
Code:
#!/bin/sh

# Restart default syslogd with modified syslog.conf to avoid excessive logging, eg. ntp
PID_SYSLOG=$(ps -o pid,args | grep "syslogd$" | grep -v grep | awk '{ print $1 }')
[ -n "${PID_SYSLOG}" ] && ( kill ${PID_SYSLOG} && syslogd -f /storage/.config/syslog.conf & )

4) chmod +x ./autostart.sh

Now, ntp updates will be discarded, giving the NAS the opportunity to spin-down its disks when RPi clients are idle.

First of all, thanks for this. Really nice How-To. It's been a few month, so I'm not sure whether this is still supposed to work, but I found that I had to replace grep "syslogd$" with a plain grep syslogd to make it work. That's running OpenELEC 3.0.6. I can confirm that I no longer have any ntp logging now.

I do have a different issue, though. I've set up PVR (Edit: In case it's relevant, I'm using NextPVR, streaming from a Windows TV server) as I use my Pi to stream Live TV, and I seem to have another log file to worry about, i.e.:

/storage/.xbmc/temp/xbmc.log

It seems to be full of the following entries, a new one being added about every 5 minutes:

07:26:23 T:2947015776 NOTICE: Thread CFileCache start, auto delete: false
07:26:24 T:2824844384 ERROR: CPVRManager - UpdateItem - no channel tag provided

Live TV seems to be working fine, despite any errors that may be logged, so does anyone have any idea how I can keep my Pi from logging this, as it still prevents my NFS drives from spinning down?

Any help with this would be much appreciated!
Reply
#39
Actually, since I wrote this you can now just create /storage/.config/syslog.conf and OE 3.0.6 will use that by default, no need to kill the syslogd process and restart it.

As for your PVR logging issue, I don't think syslog is being used by XBMC so it's unlikely you can stop logging to xbmc.log entirely. I would suggest a separate thread which may attract more eyeballs, although your best bet might be to use a small USB memory stick formatted with ext2, mount that in autostart.sh and symbolically link /storage/.xbmc/temp to a dirtectory on the memory stick so that all logs (and OE automatic updates) are written to the USB memory stick, not 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
#40
(2013-07-29, 01:17)MilhouseVH Wrote: Actually, since I wrote this you can now just create /storage/.config/syslog.conf and OE 3.0.6 will use that by default, no need to kill the syslogd process and restart it.

Ahh, good to know. Thanks! I'll change that accordingly.

(2013-07-29, 01:17)MilhouseVH Wrote: As for your PVR logging issue, I don't think syslog is being used by XBMC so it's unlikely you can stop logging to xbmc.log entirely. I would suggest a separate thread which may attract more eyeballs, although your best bet might be to use a small USB memory stick formatted with ext2, mount that in autostart.sh and symbolically link /storage/.xbmc/temp to a dirtectory on the memory stick so that all logs (and OE automatic updates) are written to the USB memory stick, not NFS.

I was hoping to avoid the use of a USB stick, but if I can't figure this out, it may be a necessary workaround. Certainly better than having my NAS drives always up.

Thanks!
Reply
#41
I wonder how the performance would be if i boot one pi from another pi.

My setup is actually one hp microserver for storage and tv-cards, a rbp for mysql and some tinkering and 3 rbps as htpcs (for testing purposes) respectively 3 atv2s (in production).

I would like to boot the 3 rbps from the rbp mysql server (the microserver is switched off most of the time due to power consumption).

I think it will work my only concern is the performance.
Reply
#42
For booting (ie. boot=nfs) I don't see a problem, other than it perhaps being a little slow to boot if two or more Pis boot at once, but since we're only talking about booting, which is presumably a rare event, it's not something to worry about.

However for storage (ie. disk=nfs), you'll be sharing 10MB bandwidth between all your active Pis, which could be a bottleneck, so I wouldn't recommend mounting /storage for multiple Pis over such a limited bandwidth connection (basically, too much potential contention). That's not to say it won't work, just that there may be times when there are delays due to contention, then again it may also work out fine.

If your concern is performance, I'd boot all the Pis from SD card, with storage on local USB (max performance, minimum risk of corruption).

Though if the Microserver is not always on, what will you be watching on the Pis? Will you be waking the Microserver with WOL?
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
#43
when booting from nfs, I can not get it to connect to the internet! I can ssh to the pi and access all nfs drive shares but not internet. Any ideas?

thanks
joe
Reply
#44
Sounds like a gateway routing problem, check how you assigned IP address details to your Pi and make sure your default gateway is your ISP router.
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
#45
Thanks, this howto helped me a lot. Smile
Reply

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