runqemu-export-rootfs: don't change RPC ports

The mountprog & nfsprog options given are not supported in the linux kernel, and the only references I can find to them are in the nfs-utils source, which notes:

"mountprog" is supported only by the legacy mount command. The kernel mount client does not support this option.

(and similar for nfsprog).

The kernel (which is what parses nfsroot=<arg> when using nfsroot) has no understanding of nfsprog or mountprog.

The result of this is that trying to mount filesystems exported by runqemu-export-rootfs in modern kernels (at least in 4.2 and later, and probably more like 2.6.20 and later) doesn't actually work.

I'm honestly not sure how anyone was using this for nfsroot support. Maybe an initramfs with a version of nfs-utils that could handle the mountprog/nfsprog option was in use? Not sure.

---
 scripts/runqemu-export-rootfs | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

index c7992d8223..70cdcdbb13 100755
@@ -77,10 +77,6 @@ if [ ! -d "$PSEUDO_LOCALSTATEDIR" ]; then
 	exit 1	
 fi
 
-# rpc.mountd RPC port
-MOUNTD_RPCPORT=${MOUNTD_RPCPORT:=$[ 21111 + $NFS_INSTANCE ]}
-# rpc.nfsd RPC port
-NFSD_RPCPORT=${NFSD_RPCPORT:=$[ 11111 + $NFS_INSTANCE ]}
 # NFS server port number
 NFSD_PORT=${NFSD_PORT:=$[ 3049 + 2 * $NFS_INSTANCE ]}
 # mountd port number

@@ -88,7 +84,7 @@ MOUNTD_PORT=${MOUNTD_PORT:=$[ 3048 + 2 * $NFS_INSTANCE ]}
 
 ## For debugging you would additionally add
 ## --debug all
-UNFSD_OPTS="-p -N -i $NFSPID -e $EXPORTS -x $NFSD_RPCPORT -n $NFSD_PORT -y $MOUNTD_RPCPORT -m $MOUNTD_PORT"
+UNFSD_OPTS="-p -N -i $NFSPID -e $EXPORTS -n $NFSD_PORT -m $MOUNTD_PORT"
 
 # See how we were called.
 case "$1" in

@@ -130,7 +126,7 @@ case "$1" in
 	fi
 	echo " "
 	echo "On your target please remember to add the following options for NFS"
-	echo "nfsroot=IP_ADDRESS:$NFS_EXPORT_DIR,nfsvers=3,port=$NFSD_PORT,mountprog=$MOUNTD_RPCPORT,nfsprog=$NFSD_RPCPORT,udp,mountport=$MOUNTD_PORT"
+	echo "nfsroot=IP_ADDRESS:$NFS_EXPORT_DIR,nfsvers=3,port=$NFSD_PORT,udp,mountport=$MOUNTD_PORT"
 	;;
   stop)
 	if [ -f "$NFSPID" ]; then

2.13.0

To clarify, when using nfsroot with the current kernel & unfsd options, my boot stops, waits for the nfs root to appear, and then times out. When trying to mount normally (ie: via mount -t nfs of a very recent vintage in arch-linux), I get immediate "protocol family not supported" errors.

With this change, both mount methods (nfsroot with new kernel options and normally mount) work without issue.

Or is there some yocto kernel patch to enable support for it? I'm running a custom kernel.

There's a patch that we've had for years to allow alternate RPC ports to work with userspace NFS and co-exist with existing NFS servers.

This would have an impact on that functionality, so if we do need to change those ports, the existing ones should be maintained with some sort of option to change the nfsroot line.

Bruce

"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

Ah, I see (I should have checked that sooner). "NFS: allow nfs root mount to use alternate rpc ports". I can likely just pull that into my kernel and have things work fine without changes to runqemu-export-rootfs.

Yep, that makes sense.

That said: it isn't completely clear to me that a seperate rpc program number (aka RPC port) is needed to avoid conflicts between 2 nfs instances in this case:

- we don't have unfsd register with rpcbind (-p option), so the rpc
program numbers won't conflict there.
- using nfsroot implicitly adds the 'nolock' option, so there isn't a
conflict there
- I did my tests with the nfs kernel server running. There wasn't an
immdiate issue observed with mounting and accessing both a kernel provided export & a unfsd provided export (using runqemu-export-rootfs) at the same time.

Still, I'm not too familiar with all of the ins and outs of nfs. Is there somewhere I've overlooked where the program numbers could conflict?

Non-root user can't create privileged ports.

Multiple nfs-servers and/or developers on the same machine could end up with port conflicts, so we need to make sure the ports can 'change'.

Of course running this on a machine that has a traditional NFS server will also
cause a conflict. The various rpmbind and other options may reduce the
likelihood of a conflict -- but they can still occur. It's better to use unique port information on a per-use basis to avoid any potential conflicts or privileged port requirements.

--Mark

I presume you're speaking about tcp/udp ports here? (having the program numbers referred to as "RPC ports" in some contexts confuses things). Or does unfsd tell the kernel about it's rpc program numbers (called "RPC ports" in the script) somehow & restrict them too?

If it is the first, it isn't clear why that is relevant: I'm not trying to have unfsd use privileged tcp/udp ports (it's already using non-privlidged tcp/udp ports). I'm trying to drop the custom rpc program numbers (which are referred to as "RPC Ports" in the script).

RPC Ports are just the bindings into rpcbind. The tcp/udp ports are the ones
that typically conflict and why this was all done to begin with.

--Mark

Ok, then it doesn't sound like that is a conflict or a "privileged ports" issue, and it is safe to drop the custom rpc program numbers ("RPC Ports") from unfsds arguments & the kernel parameters.

As I've noted, runqemu-export-rootfs does not register with rpcbind (we pass the -p flag to unfsd).

Or is there something else system-wide which is keeping a list of rpc program numbers?

The rpcbind runs on a privileged port (usually). So either you have to 're-use' the system wide on or run your own. On many environments, with a system wide one, you will clash if someone else is offering the same services. So you are forced to run your own and/or register then with a different set of port numbers.

This is absolutely needed in a multi-user or 'locked system' configuration where the user does not have permission to run these types of things.

--Mark

unfsd does not include rpcbind, it optionally uses the system's rpcbind.

In the runqemu-export-rootfs case, unfsd does not use any rpcbind at all.

Still not seeing anything that would require runqemu-export-rootfs to use custom rpc program numbers.