lkml.org 
[lkml]   [2020]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BISECT BUG] NFS v4 root not working after 6d972518b821 ("NFS: Add fs_context support.")
On Thu, Jan 16, 2020 at 07:49:15PM -0500, Scott Mayhew wrote:
> On Thu, 16 Jan 2020, Krzysztof Kozlowski wrote:
>
> > Hi all,
> >
> > Bisect pointed to 6d972518b821 ("NFS: Add fs_context support.") for
> > failures of mounting NFS v4 root on my boards:
> > mount.nfs4 -o vers=4,nolock 192.168.1.10:/srv/nfs/odroidhc1 /new_root
> > [ 24.980839] NFS4: Couldn't follow remote path
> > [ 24.986201] NFS: Value for 'minorversion' out of range
> > mount.nfs4: Numerical result out of range
> >
> > https://krzk.eu/#/builders/21/builds/1692
> > Full console log:
> > https://krzk.eu/#/builders/21/builds/1692/steps/14/logs/serial0
> >
> > Enabling NFS v4.1 in defconfig seems to help. I can send patches for
> > this (for defconfigs) but probably the root cause should be fixed as
> > well.
> >
> > Environment:
> > 1. Arch ARM Linux
> > 2. exynos_defconfig
> > 3. Exynos boards (Odroid XU3, etc), ARMv7, octa-core (Cortex-A7+A15),
> > Exynos5422 SoC
> > 4. systemd, boot up with static IP set in kernel command line
> > 5. No swap
> > 6. Kernel, DTB and initramfs are downloaded with TFTP
> > 7. NFS root from NFSv4 server
> >
> > Let me know if you need more details.
>
> I haven't had much luck reproducing this. I disabled v4.1 in my .config
> and I can still boot a VM with NFS root (granted, I don't really use NFS
> root so this setup is brand new and pretty basic):
>
> [root@localhost ~]# cat /proc/cmdline
> BOOT_IMAGE=mountapi/vmlinuz initrd=mountapi/initrd.img ip=dhcp selinux=0 console=tty0 console=ttyS0,115200 root=nfs4:192.168.122.3:/export/nfsroot/fedora31
>
> [root@localhost ~]# grep nfs /proc/mounts
> 192.168.122.3:/export/nfsroot/fedora31 / nfs rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.69,local_lock=none,addr=192.168.122.3 0 0
>
> Just out of curiousity, what version of the mount.nfs program do you
> have in your initramfs? I'm wondering if it's maybe passing the mount
> options differently than mine. FWIW I'm using version 2.4.2:
>
> [smayhew@aion tmp]$ lsinitrd /var/lib/tftpboot/mountapi/initrd.img|grep mount.nfs
> -rwsr-xr-x 1 root root 208600 Feb 14 2019 usr/sbin/mount.nfs
> lrwxrwxrwx 1 root root 9 Feb 14 2019 usr/sbin/mount.nfs4 -> mount.nfs
> [smayhew@aion tmp]$ /usr/lib/dracut/skipcpio /var/lib/tftpboot/mountapi/initrd.img|zcat|cpio -id usr/sbin/mount.nfs
> 256163 blocks
> [smayhew@aion tmp]$ ./usr/sbin/mount.nfs -V
> mount.nfs: (linux nfs-utils 2.4.2)
> [smayhew@aion tmp]$
>

My binary is:
mount.nfs4: (linux nfs-utils 3.1.1)

This is pretty weird... I extracted this binary from a running system
(Arch Linux Arm) and put into the initramfs. However now my Arch Linux
is shipped with v2.4.2-1...

Best regards,
Krzysztof

\
 
 \ /
  Last update: 2020-01-17 12:53    [W:0.152 / U:0.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site