All of lore.kernel.org
 help / color / mirror / Atom feed
From: Warren Togami <wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: initramfs <initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: Redundant nfsroot cmdline options
Date: Wed, 17 Jun 2009 15:26:10 -0400	[thread overview]
Message-ID: <4A394352.1010007@redhat.com> (raw)
In-Reply-To: <4A3898E0.8090700-omB+W0Dpw2o@public.gmane.org>

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

  parent reply	other threads:[~2009-06-17 19:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-15 19:46 Redundant nfsroot cmdline options Warren Togami
     [not found] ` <4A36A510.5010709-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-06-17  3:48   ` Dave Dillow
     [not found]     ` <20090617034849.GA22705-i1Mk8JYDVaaSihdK6806/g@public.gmane.org>
2009-06-17  4:03       ` Warren Togami
     [not found]         ` <4A386B20.9010205-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-06-17  7:18           ` Seewer Philippe
     [not found]             ` <4A3898E0.8090700-omB+W0Dpw2o@public.gmane.org>
2009-06-17 19:26               ` Warren Togami [this message]
     [not found]                 ` <4A394352.1010007-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-06-17 20:38                   ` Warren Togami
     [not found]                     ` <4A39543D.9040206-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-06-18  7:07                       ` Seewer Philippe
2009-06-18  7:23                   ` Seewer Philippe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A394352.1010007@redhat.com \
    --to=wtogami-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.