Philipp: Created page with "To avoid messing around on the internal flash partition, it's a good idea to work on a network drive when playing around. NFS is the de-facto protocol for this. I experienced some problems with the default NFS options (timeouts, lockups, etc), and some experimentation shows this works quite ok: mkdir /tmp/root mount -t nfs :/tmp/revica/root /tmp/root -o rsize=1024,wsize=1024,soft,nolock Your mileage might vary. You can backup your reciva root to nfs wi..."

2025-06-08T11:46:45Z

Created page with "To avoid messing around on the internal flash partition, it's a good idea to work on a network drive when playing around. NFS is the de-facto protocol for this. I experienced some problems with the default NFS options (timeouts, lockups, etc), and some experimentation shows this works quite ok: mkdir /tmp/root mount -t nfs <server ip>:/tmp/revica/root /tmp/root -o rsize=1024,wsize=1024,soft,nolock Your mileage might vary. You can backup your reciva root to nfs wi..."

New page

To avoid messing around on the internal flash partition, it's a good idea to work on a network drive when playing around. NFS is the de-facto protocol for this.

I experienced some problems with the default NFS options (timeouts, lockups, etc), and some experimentation shows
this works quite ok:

mkdir /tmp/root
mount -t nfs <server ip>:/tmp/revica/root /tmp/root -o rsize=1024,wsize=1024,soft,nolock

Your mileage might vary.

You can backup your reciva root to nfs with a spell like:

tar -cvf /tmp/root/root.tar /bin /boot /dev /etc /lib /linuxrc /opt /root /sbin /usr /var

we don't use wildcards for tar, because we don't want to recurse across mount points and start tarring up nfs, and busybox tar can't avoid that - so we have to specify all the root folders we want to backup.

My NFS server is an NSLU2 micro-NAS running debian.

Mounting nfs - Revision history