I’m really trying to make this work because I have several thinclients running squeezelite around the hous and I had always had an idea of booting them from network Lubutu 16 running them now. The clients only have 1gb disk in them and now boots thru usb and have internal disk for swapfile. I have one little question about this since my boot folder are empty do I need to mount boot prtititon on my PI before I run Rsync?
I better answer myself since I found waths causing my problem, on boot everything lokked good except rootpath= nothing, made some googeling and found out that adding ,tcp,v3 to the nfs section would work and it did. My saturday couldn’t start in a better way.
I also tried to follow @gersilex 's guide, but without success.
Everything went fine (created the NFS share, mounted it, rsynced the image etc.) but the Pi (3) won’t boot.
Like @mackemot, I also found some articles mentioning the tcp and v3 options, but they didn’t help in my case.
The problem is there is absolutely no debug info whatsoever provided, so I have no idea what to change. Also, the nfsrootdebug option does absolutely nothing.
The only thing I did differently compared to the guide, is I used the OpenHABian image instead or Raspbian Lite. But it’s supposed to be based on the latter so I didn’t think this could be the problem. I might try with Raspbian at some point though.
I finally managed to get it to boot by changing v3 to v4 in the options! I thought that v4 was the default and you sometimes had to explicitly set it to v3 in case v4 didn’t work. But I hadn’t imagined I would have to explicitly tell it to use version 4!
In any case, I still don’t have a usable system though, because file ownership/permissions seem to be all mangled up. I can’t even run sudo because the user doesn’t have access to the sudoers file. I did the whole process again, this time using Raspbian instead of openHABian, but with the same result.
I could try to fix permissions manually by mounting the nfs partition to another machine, but I’d like to understand why I end up with a broken system in the first place. I’m afraid that trying to troubleshoot ownerships and permissions manually will not lead to a system that’s 100% OK.
If you used rsync to copy the files, be sure to use the option --numeric-ids to have rsync know, that you probably won’t have the same names of groups and users, but the same numbers (0 for root, 1000 for the pi user, and so on).
I’ve copy-pasted the command from your guide, which already includes --numeric-ids. So that’s not the cause. In any case I tried it again more carefully, did not work.
This must be somehow related to permissions, but I don’t know exactly how. I’ve seen other users say they had to chmod 755 the root folder (/) in the Raspberry, but this didn’t work for me. It was already 755 to begin with.
Maybe it’s because I’m using openmediavault on the NAS and it has a complicated way of handling permissions. The directory that contains the root partition is exported in /export/rootfs-openhabpi and that directory’s permissions are drwxr-xr-x and owned by root:root. I believe this is correct.
However, the files are physically located in the following directory:
/srv/dev-disk-by-label-300NAS25/nfs/rootfs/openhabpi
This has the same permissions as above but its parent directory is owned by root:users and has drwx–S— permissions as does the one above it. Could this be the problem? But I don’t understand how the Pi could “see” anything above its own root directory.
A couple of weird things I’ve noticed, in case they bring any ideas to someone:
a) I disabled root password on the Pi and logged in as root. But when trying to run “sudo bash” as root, I got the same error. So even the root user gets the “sudo: unable to stat /etc/sudoers: Permission denied” error!
b) When logged in as “pi”, I can open and read the /etc/sudoers file, even though its ownership is set to root:root and its permissions to r–r-----. How is this possible? “pi” is not in the root group as far as I can see.
OK, after countless hours, I finally managed to solve this.
The culprit was indeed openmediavault, which as I said uses a complicated permissions scheme which is based on ACL. So, even though filesystem permissions seemed actually correct when “ls”-ing, ACL had its own opinion.
Although I tried adding the no_acl option to the nfs export, this didn’t work. As neither did nfsrootdebug, as neither did the system boot without explicitly specifying v4. In general it seems that anything related to what I was trying to do was working against me by not working.
Unfortunately, it’s not possible to disable ACL in openmediavault, so I had to remove it manually from the container folder using “setfacl -bR .” in the terminal and then “rsync”-ing the root partition again. I hope openmediavault doesn’t decide to re-apply ACLs at some point, since as I said it can’t be disabled.
Thanks very much for your help @gersilex, not just in debugging but also in writing this very useful guide in the first place.
1 Like
This was an interesting journey. Thanks for reporting back in such great detail. I’m sure that people will find this useful!