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.
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.
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.
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?
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.
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.
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.
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.