Bas, RealLarry, are you working on the nfs_mount.sh
script collaboratively?
Is there some git
repository somewhere, e.g. on GitHub?
Bas, RealLarry, are you working on the nfs_mount.sh
script collaboratively?
Is there some git
repository somewhere, e.g. on GitHub?
Unfortunately not. But this doesn't mean we can't
I did this script for my own use and those who are also wanting this. Dunno how many we are...
No problem to work together. Winding down at work again for a bit so I'll probably start having time for this by the end of this week. I'd be happy to not reinvent anything!
You're welcome. Feel free to edit or change whatever you want or intend to "build a better world"
The script is based on cifs-mount but changed and extended for NFS and WOL (eg for a NAS).
I think that’s the very best approach; trying to adapt the already existing and “approved” or “established” cifs_mount.sh
script and keeping everything as close as possible to the format, style, et cetera. I’m rather confident that the script could the be upstreamed and made available to everyone by default, and being referenced in the official docs/wiki, too.
Not knowing if something is already in place, I added a repo to my personal Github account with some initial plumbing and the script as you posted it here recently @RealLarry. My idea for collaboration is to report issues in this Github repo first, then pick them up and address them and to keep things transparent by working through PR's. Once upstream receives NFS kernel support, I hope to eliminate this separate repo and have the script adopted into the upstream project.
Thanks for this initiative. I could have done it myself to my Github but 'am too busy these days which would lead to missing/incomplete communication = baaad!
No problem. I know what being busy is like.. My work comes in waves and I'm on a down turn right now so I have time. It'll probably pick up again in a month or so, but I hope to upstream this or hand it over before that.
My other project for MiSTer, generating HDD images with individual PC games, turns out far bigger than I anticipated too. At least this shell script is a lot smaller in scope.
Funny, same to me but vice versa...lazy (and sick) the last weeks/months and now I'm being overwhelmed with "...please do this and that", together with my display projects, family, cats ... you know what I mean It's spring time and Germany is awakening! cough
My other project for MiSTer, generating HDD images with individual PC games, turns out far bigger than I anticipated too. At least this shell script is a lot smaller in scope.
Oh, very interesting. Please tell me more about this via PM. Maybe I can help with some hints 'n clues etc.
The script looks like it's technically mostly OK now for my part. I still have docs to write and testing to do. It should function under the following conditions:
...so consider this a call for testing the 'main' branch. It works from my laptop now, which is not a MiSTer but I can't reach mine right now.
Thank you very much, Bas. I hope to receive my USB hub board and SDRAM module in the next days, and as soon as my MiSTer FPGA setup is equipped with keyboard and wi-fi (thanks to the USB hub board), I’ll give the script a try. I’m not sure whether I’m using NFS v4 to be honest; maybe I need to do some more research on NFS.
My /etc/exports
file has the following content:
Code: Select all
# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
/mnt 10.0.0.0/24(ro,insecure,sync,no_subtree_check)
This is a v3 exports. It may work. I'm not 100% sure on how Linux handles the nfs4 filesystem type from the client side as it may fall back to NFSv3. That's part of the testing I need to do. If things break I'm going to amend the script to also support v3. I'm used to FreeBSD myself so have to look into these details.
Another intriguing aspect is that you're exporting a read-only mount. That won't go over well with hard disk images and floppies that expect to be writable.
Please report any findings you have on Github.
Thank you for your answer. Will report issues on GitHub as soon as my MiSTer FPGA setup is complete.
NFS3 should also work. Assuming that one has setup NFS3 shares the only thing to consider on client is the format.
Quick example:
Server is 10.0.0.1 and has an export of
/path/to/my/games 10.0.0.0/24(ro,insecure,sync,no_subtree_check)
(NFS4 needs some more preparation, see this good article from ArchLinux)
NFS3 client has to do
mount -t nfs 10.0.0.1:/path/to/my/games /mnt/games [-o options]
NFS4 client has to do
mount -t nfs4 10.0.0.1:/games /mnt/games [-o options]
...and NFS3 has to be done in my script, maybe as an option in the header. But we're in the 21th century. Let's use NFS4
Would it be relatively simple to get/use the NFS-enabled custom kernel which was mentioned here in the backlog some times, and/or would we rather wait until NFS support was enabled by Sorgelig in the official/upstream kernel? Also, how would I upgrade my MiSTer FPGA system to the new official/upstream kernel; is there some script we should use, e.g. updater.sh
, run some command via TTY, or replace some files via SSH/FTP/etc.?
It is simple. Either use a ssh, scp or ftp connection to transfer my Kernel after extracting to MiSTer to path /media/fat/linux/ overwriting zImage_dtb there. Just to be safe make a backup of the original file before overwriting.
And yes, if you are unsure about my Kernel or you don't trust him, just wait for Sorgelig to finish a new version - that's totally okay to me.
I built my one upon his original sources and the only things I've changed are the NFS options.
Also, how would I upgrade my MiSTer FPGA system to the new official/upstream kernel; is there some script we should use, e.g.
updater.sh
, run some command via TTY, or replace some files via SSH/FTP/etc.?
I can't remember if updater.sh is doing this job also (but should) but update_all.sh is doing this task definitely.
So I took the plunge, changed my kernel and did some live testing on my MiSTer today. Of course: bugs! But they're gone now. Script does the following:
Currently watching my 5-year-old playing Super Mario 3 for NES, coming from my NFS server.. it's alive!
That’s good news! :)
I added a new line to my /etc/exports
file, and added the fsid=0
attribute(?) to my already existing line; I think that this should now be valid NFS v4? I still haven’t found any definitive answer on how to distinguish NFS v3 and NFS v4 export definitions, and this might be the first time ever that the Arch Linux wiki (which was also linked previously) does leave some questions unanswered on my side. :D
Code: Select all
/mnt 10.0.0.0/24(ro,insecure,sync,no_subtree_check,fsid=0)
/mnt/MiSTer_FPGA 10.0.0.0/24(rw,insecure,sync,no_subtree_check)
There’s one rom file located at /mnt/MiSTer_FPGA/games/GBA/some_rom.gba
; I suppose this GBA folder will have priority over the /media/fat/games/GBA/
folder on the SD card, as it is the case with e.g. external USB flash drives. What, though, if I also have such a USB flash drive connected with a /media/usb0/games/GBA/
folder; should I better remove that USB flash drive for testing purposes?
EDIT: After downloading an replacing the kernel, and adding the nfs_mount.sh
script, NFS support works for me, even the auto-mount feature after boot or reboot works; but as anticipated above, when loading the GBA core, the files from my USB flash drive are shown and not the file which is served via NFS.
There's some documenting to do. The way the NFS mount and the local SD card are combined is not immediately obvious.
It mounts your export on /tmp/nfs_mount and overlays any subdirs that it finds there and present in /media/fat into /media/fat. So if you have a "games" subdir on the server, it'll overlay that onto your /media/fat/games. If you don't have that, it won't touch /media/fat/games.
The script does NOT make any changes on your SD card's data area.
I will write this down more clearly in the docs.
… and folders in /media/usb0/games/*
will overlay /media/fat/games/*
, i.e. has a higher priority than both SD card and NFS.
When removing the external USB flash drive, then the files served via NFS are correctly shown!
I think to have read that the analogue and/or digital I/O board adds a second SD card slot, which—I suppose—would work similar to an external USB flash drive or hard drive; maybe that’s all of the storage/overlay scenarios then. (Until someone wants to use CIFS and NFS at the same time maybe, haha.)
CIFS and NFS work at the same time, I found out by accident this morning. The second SD doesn't seem to mount into the Linux side of things, but I could be wrong. My IO board has the slot so I'll check just to be sure.
The if/then/else/unless/sacrifice-goat tree in these scripts shouldn't become too convoluted before I find a way to do proper unit testing!