linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* nfsroot protocol version
@ 2015-04-01  9:55 Mason
  2015-04-21  8:37 ` Mason
  0 siblings, 1 reply; 6+ messages in thread
From: Mason @ 2015-04-01  9:55 UTC (permalink / raw)
  To: linux-nfs; +Cc: Trond Myklebust, Anna Schumaker

Hello everyone,

My embedded system is supposed to mount the rootfs via NFS.
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt

So I set these options in my kernel .config

CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_ROOT_NFS=y
CONFIG_NFS_V4=y

But it didn't work, the system would panic after a long time out
(around 95 seconds)

[   98.567037] VFS: Unable to mount root fs via NFS, trying floppy.
[   98.573238] Freeing unused kernel memory: 144K (c0332000 - c0356000)
[   98.579698] Kernel panic - not syncing: No working init found.
	Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.

I then enabled NFSv2 and NFSv3, and then it worked.

When I was debugging the problem, I ran across NFS_DEF_OPTIONS
in fs/nfs/nfsroot.c

#define NFS_DEF_OPTIONS		"vers=2,udp,rsize=4096,wsize=4096"

IIUC, we are explicitly requesting NFSv2?

Would that explain why it fails when NFSv2 support is not compiled in?

Would it make sense to use version 3?
(So NFSv2 is not needed just to load the rootfs.)

Regards.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: nfsroot protocol version
  2015-04-01  9:55 nfsroot protocol version Mason
@ 2015-04-21  8:37 ` Mason
  2015-04-21 14:07   ` Chuck Lever
  0 siblings, 1 reply; 6+ messages in thread
From: Mason @ 2015-04-21  8:37 UTC (permalink / raw)
  To: linux-nfs; +Cc: Trond Myklebust, Anna Schumaker, Chuck Lever

Hello,

On 01/04/2015 11:55, Mason wrote:

> My embedded system is supposed to mount the rootfs via NFS.
> https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
>
> So I set these options in my kernel .config
>
> CONFIG_IP_PNP=y
> CONFIG_IP_PNP_DHCP=y
> CONFIG_ROOT_NFS=y
> CONFIG_NFS_V4=y
>
> But it didn't work, the system would panic after a long time out
> (around 95 seconds)
>
> [   98.567037] VFS: Unable to mount root fs via NFS, trying floppy.
> [   98.573238] Freeing unused kernel memory: 144K (c0332000 - c0356000)
> [   98.579698] Kernel panic - not syncing: No working init found.
>      Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
>
> I then enabled NFSv2 and NFSv3, and then it worked.
>
> When I was debugging the problem, I ran across NFS_DEF_OPTIONS
> in fs/nfs/nfsroot.c
>
> #define NFS_DEF_OPTIONS        "vers=2,udp,rsize=4096,wsize=4096"
>
> IIUC, we are explicitly requesting NFSv2?
>
> Would that explain why it fails when NFSv2 support is not compiled in?
>
> Would it make sense to use version 3?
> (So NFSv2 is not needed just to load the rootfs.)

I saw commit 4251c94833aa (NFS: Revert NFSROOT default mount options)
which states:

     Last fall we removed the ad hoc mount option parser in
     fs/nfs/nfsroot.c in favor of using the main parser in fs/nfs/super.c
     (see commit 56463e50 "NFS: Use super.c for NFSROOT mount option
     parsing").  That commit changed the default NFSROOT mount options to
     be the same as those employed by user space mounts.
     
     As it turns out, these new default mount options are not tolerated by
     many embedded systems.  So far these problems have been due to
     specific behavior of certain embedded NICs.  The NFS community does
     not have such hardware on hand for running tests.
     
     Commit 53d47375 recently introduced a clean way to specify default
     mount options for NFSROOT, so we can now easily restore the
     traditional defaults for NFSROOT:
     
        vers=2,udp,rsize=4096,wsize=4096
     
     This should revert the new default NFSROOT mount options introduced
     with commit 56463e50.

I guess this explains why vers=3 is not the default?

I'm now wondering how to override the mount options on the boot command
line. Looking more closely at commit 53d473758053 (NFS: NFSROOT should
default to "proto=udp") nothing jumps out at me.

My current boot command line is
"root=/dev/nfs ip=:::::eth0:dhcp rdinit=/none console=ttyS0,115200 mem=512M earlyprintk"

Looking at the documentation
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
I don't see where the protocol version is specified.

Where am I supposed to add the vers=3 option?

Regards.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: nfsroot protocol version
  2015-04-21  8:37 ` Mason
@ 2015-04-21 14:07   ` Chuck Lever
  2015-04-21 14:45     ` Mason
  0 siblings, 1 reply; 6+ messages in thread
From: Chuck Lever @ 2015-04-21 14:07 UTC (permalink / raw)
  To: Mason; +Cc: Linux NFS Mailing List, Trond Myklebust, Anna Schumaker


On Apr 21, 2015, at 4:37 AM, Mason <slash.tmp@free.fr> wrote:

> Hello,
> 
> On 01/04/2015 11:55, Mason wrote:
> 
>> My embedded system is supposed to mount the rootfs via NFS.
>> https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
>> 
>> So I set these options in my kernel .config
>> 
>> CONFIG_IP_PNP=y
>> CONFIG_IP_PNP_DHCP=y
>> CONFIG_ROOT_NFS=y
>> CONFIG_NFS_V4=y
>> 
>> But it didn't work, the system would panic after a long time out
>> (around 95 seconds)
>> 
>> [   98.567037] VFS: Unable to mount root fs via NFS, trying floppy.
>> [   98.573238] Freeing unused kernel memory: 144K (c0332000 - c0356000)
>> [   98.579698] Kernel panic - not syncing: No working init found.
>>     Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
>> 
>> I then enabled NFSv2 and NFSv3, and then it worked.
>> 
>> When I was debugging the problem, I ran across NFS_DEF_OPTIONS
>> in fs/nfs/nfsroot.c
>> 
>> #define NFS_DEF_OPTIONS        "vers=2,udp,rsize=4096,wsize=4096"
>> 
>> IIUC, we are explicitly requesting NFSv2?
>> 
>> Would that explain why it fails when NFSv2 support is not compiled in?
>> 
>> Would it make sense to use version 3?
>> (So NFSv2 is not needed just to load the rootfs.)
> 
> I saw commit 4251c94833aa (NFS: Revert NFSROOT default mount options)
> which states:
> 
>    Last fall we removed the ad hoc mount option parser in
>    fs/nfs/nfsroot.c in favor of using the main parser in fs/nfs/super.c
>    (see commit 56463e50 "NFS: Use super.c for NFSROOT mount option
>    parsing").  That commit changed the default NFSROOT mount options to
>    be the same as those employed by user space mounts.
>        As it turns out, these new default mount options are not tolerated by
>    many embedded systems.  So far these problems have been due to
>    specific behavior of certain embedded NICs.  The NFS community does
>    not have such hardware on hand for running tests.
>        Commit 53d47375 recently introduced a clean way to specify default
>    mount options for NFSROOT, so we can now easily restore the
>    traditional defaults for NFSROOT:
>           vers=2,udp,rsize=4096,wsize=4096
>        This should revert the new default NFSROOT mount options introduced
>    with commit 56463e50.
> 
> I guess this explains why vers=3 is not the default?
> 
> I'm now wondering how to override the mount options on the boot command
> line. Looking more closely at commit 53d473758053 (NFS: NFSROOT should
> default to "proto=udp") nothing jumps out at me.
> 
> My current boot command line is
> "root=/dev/nfs ip=:::::eth0:dhcp rdinit=/none console=ttyS0,115200 mem=512M earlyprintk"
> 
> Looking at the documentation
> https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
> I don't see where the protocol version is specified.
> 
> Where am I supposed to add the vers=3 option?

Let’s try that again.

Specifying “vers=3” in the nfs-options section of the nfsroot= boot
parameter should work.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: nfsroot protocol version
  2015-04-21 14:07   ` Chuck Lever
@ 2015-04-21 14:45     ` Mason
  2015-04-21 15:16       ` Chuck Lever
  0 siblings, 1 reply; 6+ messages in thread
From: Mason @ 2015-04-21 14:45 UTC (permalink / raw)
  To: Chuck Lever; +Cc: Linux NFS Mailing List, Trond Myklebust, Anna Schumaker

Hello Chuck,

On 21/04/2015 16:07, Chuck Lever wrote:

> On Apr 21, 2015, at 4:37 AM, Mason wrote:
>
>> Hello,
>>
>> On 01/04/2015 11:55, Mason wrote:
>>
>>> My embedded system is supposed to mount the rootfs via NFS.
>>> https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
>>>
>>> So I set these options in my kernel .config
>>>
>>> CONFIG_IP_PNP=y
>>> CONFIG_IP_PNP_DHCP=y
>>> CONFIG_ROOT_NFS=y
>>> CONFIG_NFS_V4=y
>>>
>>> But it didn't work, the system would panic after a long time out
>>> (around 95 seconds)
>>>
>>> [   98.567037] VFS: Unable to mount root fs via NFS, trying floppy.
>>> [   98.573238] Freeing unused kernel memory: 144K (c0332000 - c0356000)
>>> [   98.579698] Kernel panic - not syncing: No working init found.
>>>      Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
>>>
>>> I then enabled NFSv2 and NFSv3, and then it worked.
>>>
>>> When I was debugging the problem, I ran across NFS_DEF_OPTIONS
>>> in fs/nfs/nfsroot.c
>>>
>>> #define NFS_DEF_OPTIONS        "vers=2,udp,rsize=4096,wsize=4096"
>>>
>>> IIUC, we are explicitly requesting NFSv2?
>>>
>>> Would that explain why it fails when NFSv2 support is not compiled in?
>>>
>>> Would it make sense to use version 3?
>>> (So NFSv2 is not needed just to load the rootfs.)
>>
>> I saw commit 4251c94833aa (NFS: Revert NFSROOT default mount options)
>> which states:
>>
>>     Last fall we removed the ad hoc mount option parser in
>>     fs/nfs/nfsroot.c in favor of using the main parser in fs/nfs/super.c
>>     (see commit 56463e50 "NFS: Use super.c for NFSROOT mount option
>>     parsing").  That commit changed the default NFSROOT mount options to
>>     be the same as those employed by user space mounts.
>>         As it turns out, these new default mount options are not tolerated by
>>     many embedded systems.  So far these problems have been due to
>>     specific behavior of certain embedded NICs.  The NFS community does
>>     not have such hardware on hand for running tests.
>>         Commit 53d47375 recently introduced a clean way to specify default
>>     mount options for NFSROOT, so we can now easily restore the
>>     traditional defaults for NFSROOT:
>>            vers=2,udp,rsize=4096,wsize=4096
>>         This should revert the new default NFSROOT mount options introduced
>>     with commit 56463e50.
>>
>> I guess this explains why vers=3 is not the default?
>>
>> I'm now wondering how to override the mount options on the boot command
>> line. Looking more closely at commit 53d473758053 (NFS: NFSROOT should
>> default to "proto=udp") nothing jumps out at me.
>>
>> My current boot command line is
>> "root=/dev/nfs ip=:::::eth0:dhcp rdinit=/none console=ttyS0,115200 mem=512M earlyprintk"
>>
>> Looking at the documentation
>> https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
>> I don't see where the protocol version is specified.
>>
>> Where am I supposed to add the vers=3 option?
>
> Let's try that again.
>
> Specifying “vers=3” in the nfs-options section of the nfsroot= boot
> parameter should work.

Hmmm, I don't have nfsroot= in my boot command line.
nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]

In U-Boot, DHCP sets a root-path environment variable to
"172.27.64.1:/export/roots/6_2_0_8756"

Is root-path an alias for nfsroot?

I tried
root-path = "172.27.64.1:/export/roots/6_2_0_8756,vers=3"
root-path = "172.27.64.1:/export/roots/6_2_0_8756,v3"
(second form suggested in the link below)
but neither worked :-(

This page mentions root-path
http://developer.toradex.com/software-resources/arm-family/linux/linux-booting
option root-path "192.168.10.1:/srv/nfs/rootfs,wsize=1024,rsize=1024,v3";

Regards.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: nfsroot protocol version
  2015-04-21 14:45     ` Mason
@ 2015-04-21 15:16       ` Chuck Lever
  2015-04-22  8:57         ` Mason
  0 siblings, 1 reply; 6+ messages in thread
From: Chuck Lever @ 2015-04-21 15:16 UTC (permalink / raw)
  To: Mason; +Cc: Linux NFS Mailing List, Trond Myklebust, Anna Schumaker


On Apr 21, 2015, at 10:45 AM, Mason <slash.tmp@free.fr> wrote:

> Hello Chuck,
> 
> On 21/04/2015 16:07, Chuck Lever wrote:
> 
>> On Apr 21, 2015, at 4:37 AM, Mason wrote:
>> 
>>> Hello,
>>> 
>>> On 01/04/2015 11:55, Mason wrote:
>>> 
>>>> My embedded system is supposed to mount the rootfs via NFS.
>>>> https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
>>>> 
>>>> So I set these options in my kernel .config
>>>> 
>>>> CONFIG_IP_PNP=y
>>>> CONFIG_IP_PNP_DHCP=y
>>>> CONFIG_ROOT_NFS=y
>>>> CONFIG_NFS_V4=y
>>>> 
>>>> But it didn't work, the system would panic after a long time out
>>>> (around 95 seconds)
>>>> 
>>>> [   98.567037] VFS: Unable to mount root fs via NFS, trying floppy.
>>>> [   98.573238] Freeing unused kernel memory: 144K (c0332000 - c0356000)
>>>> [   98.579698] Kernel panic - not syncing: No working init found.
>>>>     Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
>>>> 
>>>> I then enabled NFSv2 and NFSv3, and then it worked.
>>>> 
>>>> When I was debugging the problem, I ran across NFS_DEF_OPTIONS
>>>> in fs/nfs/nfsroot.c
>>>> 
>>>> #define NFS_DEF_OPTIONS        "vers=2,udp,rsize=4096,wsize=4096"
>>>> 
>>>> IIUC, we are explicitly requesting NFSv2?
>>>> 
>>>> Would that explain why it fails when NFSv2 support is not compiled in?
>>>> 
>>>> Would it make sense to use version 3?
>>>> (So NFSv2 is not needed just to load the rootfs.)
>>> 
>>> I saw commit 4251c94833aa (NFS: Revert NFSROOT default mount options)
>>> which states:
>>> 
>>>    Last fall we removed the ad hoc mount option parser in
>>>    fs/nfs/nfsroot.c in favor of using the main parser in fs/nfs/super.c
>>>    (see commit 56463e50 "NFS: Use super.c for NFSROOT mount option
>>>    parsing").  That commit changed the default NFSROOT mount options to
>>>    be the same as those employed by user space mounts.
>>>        As it turns out, these new default mount options are not tolerated by
>>>    many embedded systems.  So far these problems have been due to
>>>    specific behavior of certain embedded NICs.  The NFS community does
>>>    not have such hardware on hand for running tests.
>>>        Commit 53d47375 recently introduced a clean way to specify default
>>>    mount options for NFSROOT, so we can now easily restore the
>>>    traditional defaults for NFSROOT:
>>>           vers=2,udp,rsize=4096,wsize=4096
>>>        This should revert the new default NFSROOT mount options introduced
>>>    with commit 56463e50.
>>> 
>>> I guess this explains why vers=3 is not the default?
>>> 
>>> I'm now wondering how to override the mount options on the boot command
>>> line. Looking more closely at commit 53d473758053 (NFS: NFSROOT should
>>> default to "proto=udp") nothing jumps out at me.
>>> 
>>> My current boot command line is
>>> "root=/dev/nfs ip=:::::eth0:dhcp rdinit=/none console=ttyS0,115200 mem=512M earlyprintk"
>>> 
>>> Looking at the documentation
>>> https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
>>> I don't see where the protocol version is specified.
>>> 
>>> Where am I supposed to add the vers=3 option?
>> 
>> Let's try that again.
>> 
>> Specifying “vers=3” in the nfs-options section of the nfsroot= boot
>> parameter should work.
> 
> Hmmm, I don't have nfsroot= in my boot command line.
> nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]

nfsroot= is the way that NFSROOT mount options are specified. Without
that kernel boot parameter, NFSROOT won’t work.

> In U-Boot, DHCP sets a root-path environment variable to
> "172.27.64.1:/export/roots/6_2_0_8756"
> 
> Is root-path an alias for nfsroot?

RFC 2132 Section 3.19 defines Root Path as option 17, which provides
a DHCP client with the location of it’s root disk.

root-path is the API on your DHCP server that lets you specify the
contents of option 17. DHCP clients use the contents of option 17
to construct a kernel boot command line.

> I tried
> root-path = "172.27.64.1:/export/roots/6_2_0_8756,vers=3"
> root-path = "172.27.64.1:/export/roots/6_2_0_8756,v3"
> (second form suggested in the link below)
> but neither worked :-(
> 
> This page mentions root-path
> http://developer.toradex.com/software-resources/arm-family/linux/linux-booting
> option root-path "192.168.10.1:/srv/nfs/rootfs,wsize=1024,rsize=1024,v3”;

You might have better luck with this:

 http://wiki.emacinc.com/wiki/Booting_with_an_NFS_Root_Filesystem

It explains how to specify client kernel boot commandline parameters
on your DHCP server that will make NFSROOT work.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: nfsroot protocol version
  2015-04-21 15:16       ` Chuck Lever
@ 2015-04-22  8:57         ` Mason
  0 siblings, 0 replies; 6+ messages in thread
From: Mason @ 2015-04-22  8:57 UTC (permalink / raw)
  To: Chuck Lever; +Cc: Linux NFS Mailing List

On 21/04/2015 17:16, Chuck Lever wrote:

> You might have better luck with this:
>
>   http://wiki.emacinc.com/wiki/Booting_with_an_NFS_Root_Filesystem
>
> It explains how to specify client kernel boot commandline parameters
> on your DHCP server that will make NFSROOT work.

Hello Chuck,

Thanks to you, it now works.

At first, I had mistakenly assumed U-boot was somehow passing the
root-path variable to Linux, but, in fact, Linux gets it from the
DHCP server (just like U-boot does).

Thus, if I set my boot command line to:
ip=dhcp root=/dev/nfs rdinit=/none console=ttyS0,115200 mem=640M

and if I change my DHCP server configuration to:
option root-path "172.27.64.1:/export/roots/6_2_0_8756,v3";

then everything works as expected, and my kernel no longer needs
to supportNFSv2.

Regards.


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2015-04-22 10:41 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-04-01  9:55 nfsroot protocol version Mason
2015-04-21  8:37 ` Mason
2015-04-21 14:07   ` Chuck Lever
2015-04-21 14:45     ` Mason
2015-04-21 15:16       ` Chuck Lever
2015-04-22  8:57         ` Mason

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).