Redundant nfsroot cmdline options

DISCUSSION Warren Togami 3 participants 8 messages Jun 15, 2009 – Jun 18, 2009 6 messages not in the archive

Share & tools

Warren Togami

author

2009-06-15 19:46 UTC #0 lore raw

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

Quoted 18 lines

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
        ;;

Quoted 1 line

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
[email protected]
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

Dave Dillow

2009-06-17 03:48 UTC #2 lore raw

Quoted 6 lines · Warren Togami

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.

Quoted 6 lines

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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 20090617034849.GA22705-i1Mk8JYDVaaSihdK6806/[email protected]

Warren Togami

author

2009-06-17 04:03 UTC #4 lore raw

Quoted 21 lines · Dave Dillow

Quoted 6 lines · Warren Togami
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.
Quoted 6 lines
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.

Quoted 5 lines

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:...

A message that is not in the archive (sent off-list or not yet received): [email protected]

Seewer Philippe

2009-06-17 07:18 UTC #6 lore raw

Quoted 22 lines · Warren Togami

Quoted 21 lines · Dave Dillow
Quoted 6 lines · Warren Togami
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.
Quoted 6 lines
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.

Quoted 7 lines

Quoted 5 lines
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.

Quoted 2 lines

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.

Quoted 7 lines

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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

Warren Togami

author

2009-06-17 19:26 UTC #8 lore raw

Quoted 5 lines

#!/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.

Quoted 9 lines

#
# 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.

Quoted 2 lines

# 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.

Quoted 1 line

# "/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.

Quoted 4 lines

#
# 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?

Quoted 3 lines

#       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

Quoted 7 lines

#
# 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.

A message that is not in the archive (sent off-list or not yet received): [email protected]

Warren Togami

author

2009-06-17 20:38 UTC #10 lore raw

Quoted 5 lines · Warren Togami

Quoted 1 line
# "/tftpboot/%s" will be used.
This part about /tftpboot/ and the accompanying implementation in 95nfs/nfsroot seems baffling.

Quoted 10 lines

* 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.

Quoted 4 lines

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?

A message that is not in the archive (sent off-list or not yet received): [email protected]

Seewer Philippe

2009-06-18 07:07 UTC #12 lore raw

Quoted 24 lines · Warren Togami

Quoted 5 lines · Warren Togami
Quoted 1 line
# "/tftpboot/%s" will be used.
This part about /tftpboot/ and the accompanying implementation in 95nfs/nfsroot seems baffling.
Quoted 10 lines
* 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.

Quoted 8 lines

Quoted 4 lines
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

Seewer Philippe

2009-06-18 07:23 UTC #13 lore raw

In reply to a message not in the archive

Quoted 18 lines · Warren Togami

Quoted 5 lines
#!/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.
Quoted 9 lines
#
# 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]
#

Quoted 1 line

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

Fine by me.

[snip]

Quoted 6 lines

Quoted 4 lines
#
# 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

Quoted 7 lines

Quoted 3 lines
#       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.

Quoted 2 lines

* 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.

Quoted 9 lines

Quoted 7 lines
#
# 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.