7

I have a raspberry pi model b+ that I am attempting to boot with a root on an nfs share. The pi takes an ip address from dhcp, and makes request to my nfs server for the root share. The server reports this request in logs, but the pi hangs after printing its ip configuration. The last cmdline.txt I tried contained: root=/dev/nfs rw nfsroot=192.168.2.25:/srv/rpi-root-nfs,tcp ip=dhcp vers=3

/etc/exports on the nfs server contains: /srv/rpi-root-nfs 192.168.2.0/24(rw,sync,no_root_squash,no_all_squash,insecure)

Are there any problems with this configuration?

UPDATE (06-06-2016) -- took a picture of the boot logs with loglevel set to 7. The line [ 7.318013 ] ... rootpath= is odd, as rootpath should be set, according to the kernel line.

7.318013 rootpath is not set

4
  • 1
    Perhaps static IP addresses are more practical?
    – Darth Vader
    Jun 4, 2016 at 14:50
  • 1
    I have tried using static IP addresses, the result is the same. Jun 4, 2016 at 15:12
  • Please check your steps. Looks like something is missing. Theoretically your configuration should work there is no any issues. Please see this thread for reference. I am not able to see the logs properly but you have compiled your linux kernel than make sure that linux kernel support is available over it.
    – Harshit
    Sep 28, 2016 at 10:15
  • I have the same problem. Were you able to solve it? I’ve tried to add the kernel parameter nfsrootdebug, but it didn’t have any effect.
    – hfs
    Oct 10, 2017 at 20:10

3 Answers 3

2

I had the same problem. For me the fix was to force NFS version 3, by appending v3 as option to nfsroot:

nfsroot=192.168.2.25:/srv/rpi-root-nfs,tcp,v3
3
  • I've removed the share since this question was posted and currently don't have a way to test, so I'll accept this answer if you're using the same Pi I was. Was this fix for a Pi B+? Oct 12, 2017 at 3:40
  • No, it’s for a Pi 3 B running Raspbian Stretch. I guess the kernel version is more important than the hardware.
    – hfs
    Oct 12, 2017 at 8:41
  • I had the same problem and it fixed it too. It is sad though that there is no way whatsoever to troubleshoot it other than trying random solutions on the internet... Jan 7, 2020 at 20:45
0

First off thanks for asking this question. I did not realize this could be done so it was fun trying to get it to work.

I got it to work and here is how I did it.

  1. I created a folder to export on my NAS, mounted the Raspian Stretch Lite image and it's two partitions. I then copied the system ext4 partition contents to the NAS folder and the Boot partition contents to a fat32 partition on the boot medium (in this case a USB flash drive).

  2. I edited the /etc/fstab file commenting out the root mount line so it would not try to remount /.

  3. Since I had labeled the boot fat32 partition as BOOT, I changed the /boot line to: LABEL=BOOT /boot vfat defaults 0 2

  4. To the exports file on my NAS I added: /mnt/RPi 192.168.0.199(rw,sync,no_root_squash,insecure)

  5. I edited the cmdline.txt file in the boot partition and ended up with this line: wc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/nfs rw nfsroot=192.168.0.99:/mnt/RPi,tcp ip=dhcp vers=3 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait splash

It booted without an error. Hope that helps.

0

For anyone who finds this thread in the future and desperate to understand why the linux kernel is hanging with no useful information:

NFS V2 is no longer supported on Ubuntu Server by default. Which means if your ARM kernel supports v2, v3 and v4 it won't boot because it doesn't check v3 or v4 when v2 doesn't work.

The solution is to disable nfs v2 in your ARM kernel, then it will mount from the modern AMD64 server via nfs v3.

A total stab in the dark worked out for me. I hope this helps someone else.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.