Observations about NFS booting

Hi - I’ve had a number of sd cards fail recently and wanted to move to an HTPC solution that supported network booting. With osmc I have got something working, but I wanted to check up on a few things I found in case further tuning was needed for my rapsberry 3 rig. The nfs share used in the case is very large. Regular booting off an SD card is also just fine.

  1. Booting from USB
    I used the installer to setup using NFS and selected the USB stick to install to. It worked fine, but when booting from the stick it boots fine, but then I get an error saying the bootfs cannot be accessed. If I do the same setup but use an SD card with NFS as the setup, it works fine. In the forums I see some statements that USB booting isn’t supported or needs extra work. I’m happy to put the extra work in if there are any pointers? The pi boots off USB fine for other OSs.

  2. Network select during boot.
    During the SD+NFS first boot, I’m asked the usual questions about language and region, but on the network selection the pi network card isn’t shown and when I try to select it I get an error which asks me to gather the error log. I’m happy to do that, but I’m not sure how to do that.

  3. Wireless selection doesn’t show one network
    After point (2), I chose wireless but the network I want to connect to isn’t shown. I left it for while and other networks are shown fine. I’ve tracked this down to the wireless channel being used for the network I want being 13 (allowed in NZ where I live). How do I configure things to allow this chnnel to be scanned?

  4. Updates failing
    Having rebooted, the OSMC box comes up and and can see/use network drives, but the setting for network still behaves as during the first boot - not apparently allowing wired and wireless missing channel 13 scan. But the wired network is working as I can see the IP address collected from dhcp and I’ve hooked up to a mythtv backend just fine. More importantly, when I do a manual update, the download starts, but fails after a couple of files and asks me to report this to the forum. I then get a message saying no updates available and I can repeat this sequence a few times without change. If there is anything I should collect to give this report a bit more information, just let me know.

Any thoughts or advice appreciated in nailing these issues.


We’ve gone for a common denominator here: only some Pis can boot from USB exclusively; so haven’t put much in to this.

With NFS: networking is devolved to the kernel; and ConnMan cannot be used for interface configuration. You can adjust networking through cmdline.txt

I think that’s a CRDA issue. We have some plans to improve this but I need some real world testers. I can give you some pointers.

Can you go to My OSMC → Logs and post a full set of logs?



I’d have to question why you’ve had so many SD card failures. I have 3 Pi’s, all with SD cards that are probably 3+ years old, and not one single failure.

I take that back, I did have to replace the card in my original Pi 1 when the card ‘cracked’. But that was a physical failure, not mental.

What PSU are you using?

I bought 10 at the same time about 2 years ago. 3 have failed so far. I have lots of USB sticks hence my interest in booting reliably from those. The lab NAS is v reliable and hence my interest in network disks either via iscsi or NFS. I’ve been using iscsi for many years and it’s solid and fast. NFS is also solid but a bit slow.

Top rate - I tried cheaper ones before and learned my lesson -:slightly_smiling_face:

Thanks for the info. I’ll park USB booting. I’m guessing you also don’t support PXE booting.

I’ll grab the other data bits and pieces and upload…

Booting from SD with your file system on USB will put minimal load on the SD card. The card is hardly ever written to so should last ‘forever’.


That was impressively easy. They are in

You’re getting security errors trying to update.

Since you mention PXE booting, I assume you’ll be familiar with the command line, so please run the following commands and post the output:

sudo apt-get update
apt-key list

Unforunately I get the same error, but I should have looked at the log files myself (and this forum more thoroughly). From another user with a similar issue, I changed the security on the NFS share and away she went.

Specifically anyone using FREENAS as their NFS server should create a user called (say) osmc, with a group the same and set this to be the owner of the NFS dataset. This might be slightly tricky because uid 1000 will often have been already used. Then on the NFS share do a MAP ALL USERS to be this osmc user and group. Flawless after that and updates being applied.

Thanks every - the advice and pointers much appreciated and I look forward to using essentially read only boot media from this point onwards with the variable data being handled by a server desiged to cope with that.

If you already have a user with UID 1000, you can use that without changing its name to OSMC. Linux only cares about the UID, not the name tied to it. On the Pi, a ls -l will show the user as osmc, as that is what it’s mapped to. On the nas, al -l will show the user as nasuser (or whatever).

I remember a thread where the user had an NFS root and had configured the share using root_squash together with all_squash, anonuid=0, anongid=0, effectively making everything owned by root. That produced a similar error.

Just a heads-up. If you want to use the Chorus 2 web interface with NFS root, you can’t use port 80, so will need to configure it to use port 8080 or something similar.