Redundant nfsroot cmdline options

Redundant nfsroot cmdline options

[Warren Togami]

http://sourceforge.net/apps/trac/dracut/wiki/commandline

I am concerned about the proliferation of too many redundant ways of 
configuring netboot.  We should clearly document each supported method 
on this Wiki page and figure out which methods should be cut.  The most 
obvious methods to cut are NEW inventions of dracut that are redundant 
to other methods.

modules.d/95nfs/parse-nfsroot.sh
> case "$root" in
>     nfs|dhcp|'')
>         if getarg nfsroot= > /dev/null; then
>             root=nfs:$(getarg nfsroot=)
>         fi
>         ;;
>     nfs4)
>         if getarg nfsroot= > /dev/null; then
>             root=nfs4:$(getarg nfsroot=)
>         fi
>         ;;
>     /dev/nfs|/dev/nfs4)
>         if getarg nfsroot= > /dev/null; then
>             root=${root#/dev/}:$(getarg nfsroot=)
>         else
>             root=${root#/dev/}
>         fi
>         ;;
> esac

root=/dev/nfs nfsroot=...

* Documentation/filesystems/nfsroot.txt documents this method.  This 
method as documented requires kernel options that no distribution uses, 
to have a netboot kernel that bypasses initrd to find its filesystem 
from cmdline options.
* This is the only native method supported by Debian's initramfs-tools, 
where it is emulated.
* Red Hat/Fedora kernels nor mkinitrd has never supported this method.


This old syntax should be tolerated as legacy and supported by dracut. 
We should NOT however invent multiple redundant syntaxes derived from 
this legacy.

root=nfs       nfsroot=...
root=nfs4      nfsroot=...
root=/dev/nfs4 nfsroot=...

These are all new inventions in dracut, redundant to the following 
native methods already supported.

NFSv3
root=[<server-ip>:]<root-dir>[:<nfs-options>]
root=dhcp DHCP root-path=[<server-ip>:]<root-dir>[:<nfs-options>]

NFSv4
root=nfs4:[<server-ip>:]<root-dir>[:<nfs-options>]
root=dhcp DHCP root-path=nfs4:[<server-ip>:]<root-dir>[:<nfs-options>]

Are there any cases not possible by these syntaxes?

Warren Togami
wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Redundant nfsroot cmdline options

[Dave Dillow]

On Mon, Jun 15, 2009 at 03:46:24PM -0400, Warren Togami wrote:
> I am concerned about the proliferation of too many redundant ways of  
> configuring netboot.  We should clearly document each supported method  
> on this Wiki page and figure out which methods should be cut.  The most  
> obvious methods to cut are NEW inventions of dracut that are redundant  
> to other methods.

> root=nfs       nfsroot=...
> root=nfs4      nfsroot=...
> root=/dev/nfs4 nfsroot=...
>
> These are all new inventions in dracut, redundant to the following  
> native methods already supported.

These short cuts are simple, and fall naturally out of the current command
line parsing. I don't expect validating them to be any harder than the
translation I already do into the canoncical nfs[4]:IP:/path:options
format -- you validate the canonical. Documenting them is not very
difficult, either. Maybe there is a potential of user confusion, but you
hide them away in the "Legacy support" or "Non-recommended" appendix.

I simply don't see the problem.

But, I'm tired of having this same coversation every few days and I
don't care enough to continue it now. I'm not going to lose sleep if these
options are gone, so rip them out if that's your fancy.
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Redundant nfsroot cmdline options

[Warren Togami]

On 06/16/2009 11:48 PM, Dave Dillow wrote:
> On Mon, Jun 15, 2009 at 03:46:24PM -0400, Warren Togami wrote:
>> I am concerned about the proliferation of too many redundant ways of
>> configuring netboot.  We should clearly document each supported method
>> on this Wiki page and figure out which methods should be cut.  The most
>> obvious methods to cut are NEW inventions of dracut that are redundant
>> to other methods.
>
>> root=nfs       nfsroot=...
>> root=nfs4      nfsroot=...
>> root=/dev/nfs4 nfsroot=...
>>
>> These are all new inventions in dracut, redundant to the following
>> native methods already supported.
>
> These short cuts are simple, and fall naturally out of the current command
> line parsing. I don't expect validating them to be any harder than the
> translation I already do into the canoncical nfs[4]:IP:/path:options
> format -- you validate the canonical. Documenting them is not very
> difficult, either. Maybe there is a potential of user confusion, but you
> hide them away in the "Legacy support" or "Non-recommended" appendix.
>
> I simply don't see the problem.
>
> But, I'm tired of having this same coversation every few days and I
> don't care enough to continue it now. I'm not going to lose sleep if these
> options are gone, so rip them out if that's your fancy.

I have great respect for the work and effort you've put into this, but 
it just doesn't make sense to add multiple redundant syntaxes of doing 
exactly the same thing.  I accepted it earlier because I was under the 
impression that all of the above were Legacy syntax from kernel's 
nfsroot.txt.  But now I realize it is invented for dracut.

Furthermore it makes less sense to add redundant syntaxes immediately 
for them to be classified as Legacy.

Also,

root=/dev/nfs4 nfsroot=...

How is this a shortcut for

root=nfs4:...

?

Warren Togami
wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Redundant nfsroot cmdline options

[Seewer Philippe]

Warren Togami wrote:
> On 06/16/2009 11:48 PM, Dave Dillow wrote:
>> On Mon, Jun 15, 2009 at 03:46:24PM -0400, Warren Togami wrote:
>>> I am concerned about the proliferation of too many redundant ways of
>>> configuring netboot.  We should clearly document each supported method
>>> on this Wiki page and figure out which methods should be cut.  The most
>>> obvious methods to cut are NEW inventions of dracut that are redundant
>>> to other methods.
>>
>>> root=nfs       nfsroot=...
>>> root=nfs4      nfsroot=...
>>> root=/dev/nfs4 nfsroot=...
>>>
>>> These are all new inventions in dracut, redundant to the following
>>> native methods already supported.
>>
>> These short cuts are simple, and fall naturally out of the current 
>> command
>> line parsing. I don't expect validating them to be any harder than the
>> translation I already do into the canoncical nfs[4]:IP:/path:options
>> format -- you validate the canonical. Documenting them is not very
>> difficult, either. Maybe there is a potential of user confusion, but you
>> hide them away in the "Legacy support" or "Non-recommended" appendix.
>>
>> I simply don't see the problem.
>>
>> But, I'm tired of having this same coversation every few days and I
>> don't care enough to continue it now. I'm not going to lose sleep if 
>> these
>> options are gone, so rip them out if that's your fancy.
> 
> I have great respect for the work and effort you've put into this, but 
> it just doesn't make sense to add multiple redundant syntaxes of doing 
> exactly the same thing.  I accepted it earlier because I was under the 
> impression that all of the above were Legacy syntax from kernel's 
> nfsroot.txt.  But now I realize it is invented for dracut.

Same here, only I though the syntaxes not involving /dev/ (and nfs4) 
were a redhattish invention. Which they aren't as Warren's already 
pointed out.

> 
> Furthermore it makes less sense to add redundant syntaxes immediately 
> for them to be classified as Legacy.

For parsing it doesn't actually really matter much how many 
[net]root=*nfs* variants we have. As long as nfsroot stays in for 
compatibility all is well.

> Also,
> 
> root=/dev/nfs4 nfsroot=...
> 
> How is this a shortcut for
> 
> root=nfs4:...

For one root=/dev/nfs[4] nfsroot=server:/path[:,]options is translated
to netroot=nfs[4]:server:/patch:options. This is not really a shortcut, 
but simplifies transition to a newer syntax or let's people try out nfs 
without changing much.

And then there's the option (as documented in kernel nfsroot.txt) of 
leaving nfsroot= away, forcing us to use a rather special variant of 
dhcp root-path.

If it's really that important I suggest we rip out the mentioned 
[net]root=[nfs,nfs4,/dev/nfs4]. root=/dev/nfs is required for kernel 
legacy support. If someone wants nfs4, they should use the preferred 
syntax [net]root=nfs4:server...

Regards,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Redundant nfsroot cmdline options

[Warren Togami]

> #!/bin/sh
> #
> # Preferred format:
> #       root=nfs[4]:[server:]path[:options]
> #       [root=*] netroot=nfs[4]:[server:]path[:options]

Harald and I agree that there is no reason for this second variation to 
exist in the case of NFS.  It seems the separate root= and netroot= only 
makes sense for remote block device protocols like iscsi or nbd.

> #
> # Legacy formats:
> #
> #       root=/dev/nfs nfsroot=[server:]path[,options]
> #
> #       XXX: All of the following have no reason to exist.
> #       [net]root=[[/dev/]nfs[4]] nfsroot=[server:]path[,options]
> #       [net]root=[[/dev/]nfs[4]] nfsroot=[server:]path[:options]
> #

I'm removing the three variations of the Legacy nfsroot.txt as discussed.

> # If the 'nfsroot' parameter is not given on the command line or is empty,
> # the dhcp root-path is used as [server:]path[:options] or the default

This comment doesn't seem to be true.

> # "/tftpboot/%s" will be used.

This part about /tftpboot/ and the accompanying implementation in 
95nfs/nfsroot seems baffling.

* In what cases does hostname lookup actually work here?
* Where does this precedent come from?  This seems to be a really narrow 
implementation from some specific past software with hard-coded assumptions.
* For example /tftpboot isn't used by default configurations of tftp 
servers on modern Debian, Ubuntu or Fedora anymore.  They've moved to 
FHS-compliant /var/lib/tftpboot.  But then again nothing demands that 
the sysadmin sticks with any particular path for the tftp server.
* What does tftpboot have to do with initrd?  The initrd doesn't have 
anything to do with tftp at this stage.

> #
> # If server is unspecified it will be pulled from one of the following
> # sources, in order:
> #       static ip= option on kernel command line

Huh?  How would you do that?

> #       DHCP next-server option
> #       DHCP server-id option
> #       DHCP root-path option

Do we really want this order?  It seems we want this order:

* root=
* DHCP root-path
* Everything else

> #
> # NFSv4 is only used if explicitly requested; default is NFSv2 or NFSv3
> # depending on kernel configuration
> #
> # root= takes precedence over netroot= if root=nfs[...]
> #
>

This precedence order shouldn't be necessary as netroot= shouldn't be 
necessary for NFS.

For now removing only the nfsroot.txt Legacy variations as the netroot= 
variations are too ingrained in the code.

Warren Togami
wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Redundant nfsroot cmdline options

[Warren Togami]

On 06/17/2009 03:26 PM, Warren Togami wrote:
>> # "/tftpboot/%s" will be used.
>
> This part about /tftpboot/ and the accompanying implementation in
> 95nfs/nfsroot seems baffling.
>
> * In what cases does hostname lookup actually work here?
> * Where does this precedent come from? This seems to be a really narrow
> implementation from some specific past software with hard-coded
> assumptions.
> * For example /tftpboot isn't used by default configurations of tftp
> servers on modern Debian, Ubuntu or Fedora anymore. They've moved to
> FHS-compliant /var/lib/tftpboot. But then again nothing demands that the
> sysadmin sticks with any particular path for the tftp server.
> * What does tftpboot have to do with initrd? The initrd doesn't have
> anything to do with tftp at this stage.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/nfsroot.txt

OK, I see in the Legacy documentation...

/tftpboot is only a default set if no path is provided.  You can 
apparently have any path with an optional %s which is replaced by the 
kernel.  In our case however we need to replace the %s ourselves.

> 62   <root-dir>    Name of the directory on the server to mount as root.
> 63                 If there is a "%s" token in the string, it will be
> 64                 replaced by the ASCII-representation of the client's
> 65                 IP address.

The documentation only mentions "ASCII-representation of the client's IP 
address", not hostname that 95nfs/nfsroot seems to indicate.

Where did the idea that %s is hostname come from?

Warren Togami
wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Redundant nfsroot cmdline options

[Seewer Philippe]

Warren Togami wrote:
> On 06/17/2009 03:26 PM, Warren Togami wrote:
>>> # "/tftpboot/%s" will be used.
>>
>> This part about /tftpboot/ and the accompanying implementation in
>> 95nfs/nfsroot seems baffling.
>>
>> * In what cases does hostname lookup actually work here?
>> * Where does this precedent come from? This seems to be a really narrow
>> implementation from some specific past software with hard-coded
>> assumptions.
>> * For example /tftpboot isn't used by default configurations of tftp
>> servers on modern Debian, Ubuntu or Fedora anymore. They've moved to
>> FHS-compliant /var/lib/tftpboot. But then again nothing demands that the
>> sysadmin sticks with any particular path for the tftp server.
>> * What does tftpboot have to do with initrd? The initrd doesn't have
>> anything to do with tftp at this stage.
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/nfsroot.txt 
> 
> 
> OK, I see in the Legacy documentation...
> 
> /tftpboot is only a default set if no path is provided.  You can 
> apparently have any path with an optional %s which is replaced by the 
> kernel.  In our case however we need to replace the %s ourselves.
> 
>> 62   <root-dir>    Name of the directory on the server to mount as root.
>> 63                 If there is a "%s" token in the string, it will be
>> 64                 replaced by the ASCII-representation of the client's
>> 65                 IP address.
> 
> The documentation only mentions "ASCII-representation of the client's IP 
> address", not hostname that 95nfs/nfsroot seems to indicate.
> 
> Where did the idea that %s is hostname come from?

The commit that introduced it is here:

http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut;a=commitdiff;h=abe9ccc89a96bc61bc2e9d3169341821393da6da

Regards,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Redundant nfsroot cmdline options

[Seewer Philippe]

Warren Togami wrote:
>> #!/bin/sh
>> #
>> # Preferred format:
>> #       root=nfs[4]:[server:]path[:options]
>> #       [root=*] netroot=nfs[4]:[server:]path[:options]
> 
> Harald and I agree that there is no reason for this second variation to 
> exist in the case of NFS.  It seems the separate root= and netroot= only 
> makes sense for remote block device protocols like iscsi or nbd.
> 
>> #
>> # Legacy formats:
>> #
>> #       root=/dev/nfs nfsroot=[server:]path[,options]
>> #
>> #       XXX: All of the following have no reason to exist.
>> #       [net]root=[[/dev/]nfs[4]] nfsroot=[server:]path[,options]
>> #       [net]root=[[/dev/]nfs[4]] nfsroot=[server:]path[:options]
>> #
> 
> I'm removing the three variations of the Legacy nfsroot.txt as discussed.

Fine by me.

[snip]
>> #
>> # If server is unspecified it will be pulled from one of the following
>> # sources, in order:
>> #       static ip= option on kernel command line
> 
> Huh?  How would you do that?

If $srv is in net.used-if.override it is used
>> #       DHCP next-server option
>> #       DHCP server-id option
>> #       DHCP root-path option
> 
> Do we really want this order?  It seems we want this order:
> 
> * root=
root= is superfluous. as it already takes precedence and these rules 
only apply if if server is unspeficied.

> * DHCP root-path
> * Everything else

I'm not sure about that. nfsroot.txt is a bit unclear here:

[quote]
<server-ip>   IP address of the NFS server. If RARP is used to determine
               the client address and this parameter is NOT empty only
               replies from the specified server are accepted.

               Only required for for NFS root. That is autoconfiguration
               will not be triggered if it is missing and NFS root is not
               in operation.

               Default: Determined using autoconfiguration.
               The address of the autoconfiguration server is used.
[/quote]

"address of the autoconfiguration server" translates for me as try 
next-server or server-id and if that fails use root-path.

>> #
>> # NFSv4 is only used if explicitly requested; default is NFSv2 or NFSv3
>> # depending on kernel configuration
>> #
>> # root= takes precedence over netroot= if root=nfs[...]
>> #
>>
> 
> This precedence order shouldn't be necessary as netroot= shouldn't be 
> necessary for NFS.

Yes that is true. I'd like to keep it there as it keeps the nfs cmdline 
arguments consistent with nbd and iscsi.

Regards,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html