WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: nfsmount, nfs-client and mount.nfs picore9  (Read 2569 times)

Offline CentralWare

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 764
nfsmount, nfs-client and mount.nfs picore9
« on: September 03, 2018, 07:14:38 AM »
Good morning all!


I was working on a project last night which required devices (x86/x64/rpi) to either pxe-boot or flash-boot (USB, SD, etc) with nfsmount=server:/share being vital.
The outcome is all over the place.


After finding out that Pi9.0.3 nfs-utils is hard-coded vers=4.03 (my NAS, for example, is 4.0 though I've considered launching Tiny on it :) ) thus RasPi just hangs for a few minutes not knowing what to do with itself.  (I learned this lesson the hard way until forcing vers=4.0 manually which was successful.)


** Recommend altering tc-config to impose vers=3.0 for a more "universal" friendliness??

** Better yet, a change in the boot code itself such as nfsmount=SERVER:OPTS:PATH would do the trick! :)


x86/x64 machines are "just acting weird" (ie: quad-core with 12gb, dual gbe nics...) on test one launches from start to finish flawlessly.  On the next attempt it could miss the tftp handshake or not even get a dhcp response -- I have to trace hardware (switches) to see what I can find before I start digging any further there.


Thanks guys!

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: nfsmount, nfs-client and mount.nfs picore9
« Reply #1 on: September 03, 2018, 01:01:15 PM »
A patch for NFS opts would be fine. If it can detect and support the old syntax, good, otherwise it'd need a new var like nfsopts=OPTS.

edit: I see the opts are already supported? They just come after the path, nfsmount=server:/share:opt,opt
edit2: Scratch that. It'd need a new var since the third position is used for the nfsv4 or no-ping opts. Or maybe add such for vers?
« Last Edit: September 03, 2018, 01:04:25 PM by curaga »
The only barriers that can stop you are the ones you create yourself.

Offline CentralWare

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 764
Re: nfsmount, nfs-client and mount.nfs picore9
« Reply #2 on: September 06, 2018, 12:17:42 AM »
@curaga: Regarding NFS, I'll be knee-deep in tc.config here in just a few minutes; I'll see what we can accommodate.  (SEPARATE boot code for opts I'd hope to avoid; peeps already have a ton of codes to remember...  :) )

Offline CentralWare

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 764
Re: nfsmount, nfs-client and mount.nfs picore9
« Reply #3 on: September 06, 2018, 01:11:20 AM »
@curaga: It's one in the morning and I'm under the influence of cold meds, so please bare with me and double-check my thinking! :)

boot code: nfsmount=[SERVER]:[PATH]:[OPTS]

Currently OPTS is reserved for nfs4 and noping switches.
I have a beta in place which will be tested later in the day which replaces the two [IF] nfs4/noping with a case set where those two are preserved and the "default" is assumed to be arguments/options which normally would come after the -o switch for BOTH NFS-UTILS' mount.nfs as well as the raw mount from busybox.
Code: [Select]
case $1 in
     no-ping)    NOPING=1 ;;
     nfs4)       MOUNT=$MOUNT4 ;; # With a backup earlier to ensure nfs-utils is embedded
     *)          NFSOPTS="${NFSOPTS} ${1}" ;;   # <- our new list of arguments passed to -o
esac


Since there are already -o options in certain cases (such as -o nolock) and the fstab entries, a little cleanup had to be implemented to merge the two sets.
I'll build the new image later today and try 'er out on our PXE network (which relies on NFS and AoE) and if successful, submit the results here.


**edit: I'm pondering a replacement for networked mounts (NFS, AoE, etc.) which will prevent endless lags if/when something doesn't go exactly as planned.  For example, add nfsmount=1.2.3.4:/somewhere to your boot codes and reboot.  You're going to sit there a number of minutes before MOUNT finally throws in the towel.  Since we don't seem to have any control over HOW long we wait before a timeout, I'm thinking we could put net-mounts in the background, monitor them for X seconds from within tc-config and after X seconds if the mount is still pending, kill the process and move on.  (It takes a few seconds at most to connect with a share if everything is running as it should...  leaving the machine in limbo for a number of minutes is rather wasteful - and irritating! :) )
« Last Edit: September 06, 2018, 01:23:44 AM by centralware »

Offline CentralWare

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 764
Re: nfsmount, nfs-client and mount.nfs picore9
« Reply #4 on: September 06, 2018, 02:43:01 AM »
@TCL: Repository request...

tcl/x.x/x86/release/distribution_files
tcl/x.x/armv7/... 

While v10.0 is still being procured, would it not be worthwhile to do with ARM6/ARM7 the same as we do with the x86/64 friends and have copies of the actual boot files available?  I can't count how many times I've had to break apart a Pi image, rip out the first partition and copy the contents to a temp folder just to do a remastering of the init image.  With PC projects, this is all done for us already in the above folder which is truly helpful.

To accomplish this, it wouldn't be a bad idea to standardize the folder structure between x86/64 and arm6/7
ARM=./releases          86=./release
ARM=./test_releases   86=./release_candidates
Just Sayin' ! :)
« Last Edit: September 06, 2018, 02:48:12 AM by centralware »

Offline CentralWare

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 764
Re: nfsmount, nfs-client and mount.nfs picore9
« Reply #5 on: September 06, 2018, 05:33:47 AM »
Replacement proposal for NFSMOUNT functionality in tc-config:
Code: [Select]
if [ -n "$NFSMOUNT" ]; then
    NFSPTH="/mnt/nfstest"
    SERVER=$( echo $NFSMOUNT | awk -F: '{ print $1 }')
    DIR=$(    echo $NFSMOUNT | awk -F: '{ print $2 }')
    OPTS=$(   echo $NFSMOUNT | awk -F: '{ print $3 }' | tr "," " " )
    MOUNT=mount; MOUNT4=/usr/local/sbin/mount.nfs4; NOPING=0
    echo "${RED}Mounting NFS Server ${YELLOW}${SERVER}:${DIR}${NORMAL}"
    set $OPTS END
    while [ "$1" != "END" ]
    do
        case $1 in
            no-ping) NOPING=1 ;;
            nfs4)    MOUNT=$MOUNT4 ;;
            *)       MYOPTS="${MYOPTS} $1" ;;
        esac
        shift
    done
    MYOPTS=$(echo $MYOPTS) # Remove pre/trailing space(s)
    MYOPTS=${MYOPTS// /,}  # Replace SPACE with COMMA
    [ -z "$DHCP_RAN" ] && wait4Server $SERVER $NOPING
    wait $fstab_pid
    if [ -d $NFSPTH ]; then umount $NFSPTH >/dev/null 2>&1; fi
    mkdir -p $NFSPTH
    if [ -x /usr/local/etc/init.d/nfs-client ]; then
        echo "  --> nfs-utils detected"
        /usr/local/etc/init.d/nfs-client start
        OP=""; if [ ! "${MYOPTS}" == "" ]; then OP="-o $MYOPTS"; fi
        if $MOUNT "${SERVER}:${DIR}" $OP $NFSPTH 2>/dev/null; then
            FSOP=""; if [ ! "${MYOPTS}" == "" ]; then FSOP=",${MYOPTS}"; fi
            echo "${SERVER}:${DIR} $NFSPTH nfs defaults${FSOP} 0 0" >>/etc/fstab
        elif mount "${SERVER}:${DIR}" $OP $NFSPTH 2>/dev/null; then
            FSOP=""; if [ ! "${MYOPTS}" == "" ]; then FSOP=",${MYOPTS}"; fi
            echo "${SERVER}:${DIR} $NFSPTH nfs defaults${FSOP} 0 0" >>/etc/fstab
        fi
    elif
        OP="-o nolock"; if [ ! "${MYOPTS}" == "" ]; then OP="-o $MYOPTS"; fi
        echo "  --> mounting bb-mount with $OP"
        mount $OP "${SERVER}:${DIR}" $NFSPTH 2>/dev/null; then
        FSOP="nolock"; if [ ! "${MYOPTS}" == "" ]; then FSOP=",${MYOPTS}"; fi
        echo "${SERVER}:${DIR} $NFSPTH nfs defaults,${FSOP} 0 0" >>/etc/fstab
    else
        echo "${RED}Mounting ${SERVER}:${DIR} failed${NORMAL}"
    fi
fi
no-ping and nfs4 boot codes are still supported (and not forwarded to -o options)


NOTE: nfs-utils x86_64 v9.x dependency file needs to be updated to include libtirpc-dev (throws missing lib errors otherwise)

« Last Edit: September 06, 2018, 06:04:27 AM by centralware »

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: nfsmount, nfs-client and mount.nfs picore9
« Reply #6 on: September 06, 2018, 12:43:53 PM »
Added, thanks. I don't have a NFS setup, so not tested.
The only barriers that can stop you are the ones you create yourself.