Netroot cmdline arguments

Netroot cmdline arguments

[Seewer Philippe]

Hello all

I've been trying to put some more validating in the cmdline parser scripts so we can abort early and tell the user what's wrong with the commandline. We've had a similar discussion concerning netroot cmdline arguments before, but at least for me some things are unclear.

I've tried here to put together the doc from http://apps.sourceforge.net/trac/dracut/wiki/commandline and what I've found inside the scripts themselves. If all those who who know and have used netroot stuff could help to clean this up, that would be great.

Thanks all,
Philippe



DHCP
----

Format:
	root=dhcp

Use dhcp root-path option. root-path should contain a text as described below

==> Question: Should root-path only follow the proposed Style type:server:... or should we allow any option format, possibly allow combining with dhcp next_server/server-id?

NFS
---

Preferred format:
	root=nfs[4]:[server:]path[:options]

Legacy formats:
	root=/dev/nfs[4] nfsroot=[server:]path[,options]

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

Other formats:
	root=nfs[4]
	Plain "root=nfs" interprets DHCP root-path option as
	[ip:]path[:options] 

==> Question: I've never used/seen root=nfs before. If server-ip is missing in root-path should dhcp next-server/server-id be used?

NBD
---

Preferred format:
	root=nbd:srv:port[:fstype[:rootflags[:nbdopts]]]

nbdopts is a comma seperated list of options to give to nbd-client

Legacy formats:
	nbdroot=srv,port

==> Question: What should root= contain here? Is having no or an empty root= ok?

Other formats:
	nbdroot=srv:port[:fstype[:rootflags[:nbdopts]]]

==> Same here: empty root ok?
	root=dhcp nbdroot=srv:port[:fstype[:rootflags[:nbdopts]]]

==> Question: Does this make sense? Isn't Having a specified server conflicting with dhcp?

	root=nbd nbdroot=srv:port[:fstype[:rootflags[:nbdopts]]]

==> Question: What aboud a /dev/nbd or even more exact /dev/nbd0?


ISCSI
-----

Preferred format:
	root=iscsi:[<servername>]:[<protocol>]:[<port>]:[<LUN>]:<targetname>

protocol defaults to "6", LUN defaults to "0". 

If the "servername" field is provided by BOOTP or DHCP, then that field is used in conjunction with other associated fields to contact the boot server in the Boot stage (Section 7). However, if the "servername" field is not provided, then the "targetname" field is then used in the Discovery Service stage in conjunction with other associated fields.

See: http://tools.ietf.org/html/rfc4173

==> Question 1: The RFC says that DHCP root-path may be used. OK for root=dhcp but what if we provide root=iscsi:... on the cmdline and leave the servername blank? Try to use root-path anyway? Or maybe even use next-server/server-id?

==> Question 2: The RFC specifically says hostnames or ipv6 addresses are allowed for servername. Do we have to support this?

Other/Legacy formats:
	iscsiroot=[<servername>]:[<protocol>]:[<port>]:[<LUN>]:<targetname>

==> Question: Same as with nbd. empty or no root=?

	root=dhcp iscsiroot=[<servername>]:[<protocol>]:[<port>]:[<LUN>]:<targetname>

==> Question: What is the use of root=dhcp and having more specifics?

	root=iscsi iscsiroot=[<servername>]:[<protocol>]:[<port>]:[<LUN>]:<targetname>

==> Question: What aboud a /dev/iscsi or even more exact /dev/iscsi/...lun...?

	root=??? iscsi_initiator= iscsi_target_name= iscsi_target_ip= iscsi_target_port= iscsi_target_group= iscsi_username= iscsi_password= iscsi_in_username= iscsi_in_password=
	root=??? iscsi_firmware

==> Question: Are these really necessary/used?



--
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: Netroot cmdline arguments

[David Dillow]

[ please set your mail client to wrap lines at 72 chars or so ]

On Tue, 2009-06-09 at 17:35 +0200, Seewer Philippe wrote:
> Hello all
> 
> I've been trying to put some more validating in the cmdline parser
> scripts so we can abort early and tell the user what's wrong with the
> commandline. We've had a similar discussion concerning netroot cmdline
> arguments before, but at least for me some things are unclear.

While I applaud the idea of letting the user know there is a problem,
I'm not sure that doing all of this in the cmdline hook is the best
place -- given that we also need to validate info coming in from DHCP as
well. Also, duplicating the parsing code from the netroot handlers
doesn't seem to be a win in my mind.

Certainly, there are a class of errors that we should catch early on,
but perhaps effort may be better spent in reporting the errors in the
netroot handlers?

My opinions on your questions follow, though I should note that having
implemented much of the legacy option parsing, I'm not completely
adverse to simplifying our support. I like that we can support so many
formats, but having written test cases for them I can see the appeal of
sparse support. It would make documentation easier, anyway. It's easy to
say "no, we don't do that."

> DHCP
> ----
> 
> Format:
> 	root=dhcp
> 
> Use dhcp root-path option. root-path should contain a text as described below
> 
> ==> Question: Should root-path only follow the proposed Style
> type:server:... or should we allow any option format, possibly allow
> combining with dhcp next_server/server-id?

I think we should allow the legacy options to work. We have the code to
do it.

> NFS
> ---
> 
> Preferred format:
> 	root=nfs[4]:[server:]path[:options]
> 
> Legacy formats:
> 	root=/dev/nfs[4] nfsroot=[server:]path[,options]
> 
> If server is unspecified it will be pulled from one of the following
> sources, in order:
> 	static ip= option on kernel command line
> 	DHCP next-server option
> 	DHCP server-id option
> 
> Other formats:
> 	root=nfs[4]
> 	Plain "root=nfs" interprets DHCP root-path option as
> 	[ip:]path[:options] 
> 
> ==> Question: I've never used/seen root=nfs before. If server-ip is
> missing in root-path should dhcp next-server/server-id be used?

root=nfs is something I did early on as a shortcut for root=/dev/nfs
which is supported by the kernel's nfsroot code. Similarly,
root={/dev/,}nfs4 is an invention to handle newer NFS versions.

If server-ip is missing, then it should be filled in via the server
argument from the appropriate ip= line, or via dhcpd
next-server/server-id.

> NBD
> ---
> 
> Preferred format:
> 	root=nbd:srv:port[:fstype[:rootflags[:nbdopts]]]
> 
> nbdopts is a comma seperated list of options to give to nbd-client
> 
> Legacy formats:
> 	nbdroot=srv,port
> 
> ==> Question: What should root= contain here? Is having no or an empty
> root= ok?

Legacy would be root=/dev/ndb[0-9]+ but Warren has suggested we drop
that. With my netroot= patches -- coming soon to a list near you! ;) --
the NBD handler will default to /dev/nbd0, or will be able to specify
root=LABEL=/ or root=/dev/lvm-volume/lv-name etc to use the same
features we get when root is on a local disk.

> Other formats:
> 	nbdroot=srv:port[:fstype[:rootflags[:nbdopts]]]
> 
> ==> Same here: empty root ok?
> 	root=dhcp nbdroot=srv:port[:fstype[:rootflags[:nbdopts]]]
> 
> ==> Question: Does this make sense? Isn't Having a specified server
> conflicting with dhcp?

Maybe, or you can see it as get your IP info from dhcp. I can see that
this is a bit of a conflict.

> 	root=nbd nbdroot=srv:port[:fstype[:rootflags[:nbdopts]]]
> 
> ==> Question: What aboud a /dev/nbd or even more exact /dev/nbd0?

As above -- root=/dev/nbd0 is a dropped syntax for the moment, to be
resurrected in a new form by netroot= 

> 
> 
> ISCSI
> -----
> 
> Preferred format:
> 	root=iscsi:[<servername>]:[<protocol>]:[<port>]:[<LUN>]:<targetname>

> See: http://tools.ietf.org/html/rfc4173
> 
> ==> Question 1: The RFC says that DHCP root-path may be used. OK for
> root=dhcp but what if we provide root=iscsi:... on the cmdline and
> leave the servername blank? Try to use root-path anyway? Or maybe even
> use next-server/server-id?

Here, I would stick to the RFC as there are fewer legacy issues. I would
expect netroot=iscsi:... to behave as though the iscsi:... came from the
DHCP server and ignore the DHCP root-path option (or at least for the
fields specified on the command line.)

This is similar to how the kernel's ip= and nfsroot= pull their defaults
from the DHCP response, but allow it to be overridden by the command
line options.

If servername is blank, per the RFC we use <targetname> with the
Discovery Service to find our server.

> ==> Question 2: The RFC specifically says hostnames or ipv6 addresses
> are allowed for servername. Do we have to support this?

I think we should, yes. IPv6 support is something we're going to want in
general, but it will present some challenges to our parsing schemes.

Perhaps we would put some limits on using IPv6 in the legacy options (no
ip= static config for IPv6, require the full nfs:IP:server[:,]opts
format, etc.)

Supporting hostnames via DNS is almost free. Other schemes such as LDAP
and NIS would be more problematic I think. Though perhaps there is a
good way to pull that in. I haven't thought much about it.

> Other/Legacy formats:
> 	iscsiroot=[<servername>]:[<protocol>]:[<port>]:[<LUN>]:<targetname>
> 
> ==> Question: Same as with nbd. empty or no root=?

With no root, I think we need the root to the LUN option given, which
defaults to the first LUN on that host if not given.

> 	root=dhcp iscsiroot=[<servername>]:[<protocol>]:[<port>]:[<LUN>]:<targetname>
> 
> ==> Question: What is the use of root=dhcp and having more specifics?

This has the same conceptual conflict as you note for nbdroot= w/
root=dhcp.

> 	root=iscsi iscsiroot=[<servername>]:[<protocol>]:[<port>]:[<LUN>]:<targetname>
> 
> ==> Question: What aboud a /dev/iscsi or even more exact /dev/iscsi/...lun...?

I don't think we need to invent a new format here. We've got enough
legacy issues to keep us busy. :)

> 	root=??? iscsi_initiator= iscsi_target_name= iscsi_target_ip=
> iscsi_target_port= iscsi_target_group= iscsi_username= iscsi_password=
> iscsi_in_username= iscsi_in_password=
> 	root=??? iscsi_firmware
> 
> ==> Question: Are these really necessary/used?

I think the first one is unlikely to be all that useful, given the
limits on the command line (though maybe it is just my version of
PXELINUX that is the limit.) Also, there are security issues with having
that information on the command line (not to mention in cleartext on the
wire.

I would like to see some way to support reading iSCSI Boot Firmware
Table (iBFT) from the BIOS to find our root, so we need a way to tell
dracut to do so. I don't know if that is root=iscsi:firmware or
root=blah iscsi=firmware or what.

--
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: Netroot cmdline arguments

[Seewer Philippe]

David Dillow wrote:
> [ please set your mail client to wrap lines at 72 chars or so ]
Uhh. Sorry, forgot to enable word wrap. Apologies.

> On Tue, 2009-06-09 at 17:35 +0200, Seewer Philippe wrote:
>> Hello all
>>
>> I've been trying to put some more validating in the cmdline parser
>> scripts so we can abort early and tell the user what's wrong with the
>> commandline. We've had a similar discussion concerning netroot cmdline
>> arguments before, but at least for me some things are unclear.
> 
> While I applaud the idea of letting the user know there is a problem,
> I'm not sure that doing all of this in the cmdline hook is the best
> place -- given that we also need to validate info coming in from DHCP as
> well. Also, duplicating the parsing code from the netroot handlers
> doesn't seem to be a win in my mind.

I agree there. Duplicating parsing code isn't good. I'm trying to come 
up with a solution that is able to parse the cmdline as well as dhcp 
root-path.

> Certainly, there are a class of errors that we should catch early on,
> but perhaps effort may be better spent in reporting the errors in the
> netroot handlers?

See above. And personally I prefer to spew as many errors as soon as 
possible. First, this makes it easier for later modules, since they can 
assume that "all is well". Second, there's a lot of argument 
combinations that can lead to a "generic" error without any details. Say 
root=dhcp with static ip lines for each interface.

> My opinions on your questions follow, though I should note that having
> implemented much of the legacy option parsing, I'm not completely
> adverse to simplifying our support. I like that we can support so many
> formats, but having written test cases for them I can see the appeal of
> sparse support. It would make documentation easier, anyway. It's easy to
> say "no, we don't do that."

Thanks for answering all the stuff!

As for simplifying the options, I partially agree. Handling so many 
different combinations is a pain. But supporting the older legacy 
formats is a boon for transition. So I still think if its possible to do 
so without having too many ugly hacks we should keep them.

> 
>> DHCP
>> ----
>>
>> Format:
>> 	root=dhcp
>>
>> Use dhcp root-path option. root-path should contain a text as described below
>>
>> ==> Question: Should root-path only follow the proposed Style
>> type:server:... or should we allow any option format, possibly allow
>> combining with dhcp next_server/server-id?
> 
> I think we should allow the legacy options to work. We have the code to
> do it.

Very good.

> 
>> NFS
>> ---
>>
>> Preferred format:
>> 	root=nfs[4]:[server:]path[:options]
>>
>> Legacy formats:
>> 	root=/dev/nfs[4] nfsroot=[server:]path[,options]
>>
>> If server is unspecified it will be pulled from one of the following
>> sources, in order:
>> 	static ip= option on kernel command line
>> 	DHCP next-server option
>> 	DHCP server-id option
>>
>> Other formats:
>> 	root=nfs[4]
>> 	Plain "root=nfs" interprets DHCP root-path option as
>> 	[ip:]path[:options] 
>>
>> ==> Question: I've never used/seen root=nfs before. If server-ip is
>> missing in root-path should dhcp next-server/server-id be used?
> 
> root=nfs is something I did early on as a shortcut for root=/dev/nfs
> which is supported by the kernel's nfsroot code. Similarly,
> root={/dev/,}nfs4 is an invention to handle newer NFS versions.
> 
> If server-ip is missing, then it should be filled in via the server
> argument from the appropriate ip= line, or via dhcpd
> next-server/server-id.

Hmmm... so you say root=nfs is just a short version of root=/dev/nfs? In 
that case the documentation isn't up to date, since (see above) root=nfs 
says specifically that it uses dhcp root-path.

If this is really a dracut specific "invention" I suggest we drop this.

> 
>> NBD
>> ---
>>
>> Preferred format:
>> 	root=nbd:srv:port[:fstype[:rootflags[:nbdopts]]]
>>
>> nbdopts is a comma seperated list of options to give to nbd-client
>>
>> Legacy formats:
>> 	nbdroot=srv,port
>>
>> ==> Question: What should root= contain here? Is having no or an empty
>> root= ok?
> 
> Legacy would be root=/dev/ndb[0-9]+ but Warren has suggested we drop
> that. With my netroot= patches -- coming soon to a list near you! ;) --
> the NBD handler will default to /dev/nbd0, or will be able to specify
> root=LABEL=/ or root=/dev/lvm-volume/lv-name etc to use the same
> features we get when root is on a local disk.

Hmmm... OK. The point here is that, if say nbdroot= (or iscsiroot=, 
nfsroot=) is available, we should just ignore root= completely?

> 
>> Other formats:
>> 	nbdroot=srv:port[:fstype[:rootflags[:nbdopts]]]
>>
>> ==> Same here: empty root ok?
>> 	root=dhcp nbdroot=srv:port[:fstype[:rootflags[:nbdopts]]]
>>
>> ==> Question: Does this make sense? Isn't Having a specified server
>> conflicting with dhcp?
> 
> Maybe, or you can see it as get your IP info from dhcp. I can see that
> this is a bit of a conflict.

Suggestion: We drop this. root=dhcp should stand on its own without 
combinations.

> 
>> 	root=nbd nbdroot=srv:port[:fstype[:rootflags[:nbdopts]]]
>>
>> ==> Question: What aboud a /dev/nbd or even more exact /dev/nbd0?
> 
> As above -- root=/dev/nbd0 is a dropped syntax for the moment, to be
> resurrected in a new form by netroot= 
> 
>>
>> ISCSI
>> -----
>>
>> Preferred format:
>> 	root=iscsi:[<servername>]:[<protocol>]:[<port>]:[<LUN>]:<targetname>
> 
>> See: http://tools.ietf.org/html/rfc4173
>>
>> ==> Question 1: The RFC says that DHCP root-path may be used. OK for
>> root=dhcp but what if we provide root=iscsi:... on the cmdline and
>> leave the servername blank? Try to use root-path anyway? Or maybe even
>> use next-server/server-id?
> 
> Here, I would stick to the RFC as there are fewer legacy issues. I would
> expect netroot=iscsi:... to behave as though the iscsi:... came from the
> DHCP server and ignore the DHCP root-path option (or at least for the
> fields specified on the command line.)
> 
> This is similar to how the kernel's ip= and nfsroot= pull their defaults
> from the DHCP response, but allow it to be overridden by the command
> line options.
> 
> If servername is blank, per the RFC we use <targetname> with the
> Discovery Service to find our server.

OK, thanks for clearing this up. Makes it a whole lot simpler.

> 
>> ==> Question 2: The RFC specifically says hostnames or ipv6 addresses
>> are allowed for servername. Do we have to support this?
> 
> I think we should, yes. IPv6 support is something we're going to want in
> general, but it will present some challenges to our parsing schemes.
> 
> Perhaps we would put some limits on using IPv6 in the legacy options (no
> ip= static config for IPv6, require the full nfs:IP:server[:,]opts
> format, etc.)

Indeed it does. And to think further, there are two ipv6 autoconf 
possibilities: stateless (router adviced) or stateful (dhcp6).

Legacy options should be ok, since they only contain "addresses". I'd 
suggest to add a ip6= option for full ipv6 support later on.

> Supporting hostnames via DNS is almost free. Other schemes such as LDAP
> and NIS would be more problematic I think. Though perhaps there is a
> good way to pull that in. I haven't thought much about it.

NIS/NIS+ is almost dead, and LDAP requires quite a lot of configuration. 
I'd say we ignore this.

As for DNS: If we use DHCP, you're correct. It's almost free. But we 
don't have any ip= options for static configuration to set the DNS 
Server...

>> Other/Legacy formats:
>> 	iscsiroot=[<servername>]:[<protocol>]:[<port>]:[<LUN>]:<targetname>
>>
>> ==> Question: Same as with nbd. empty or no root=?
> 
> With no root, I think we need the root to the LUN option given, which
> defaults to the first LUN on that host if not given.

Again, it's just a question of wheter we can ignore root= or not.

> 
>> 	root=dhcp iscsiroot=[<servername>]:[<protocol>]:[<port>]:[<LUN>]:<targetname>
>>
>> ==> Question: What is the use of root=dhcp and having more specifics?
> 
> This has the same conceptual conflict as you note for nbdroot= w/
> root=dhcp.

Again, I suggest we drop this. root=dhcp should stand on its own without 
further options.
> 
>> 	root=iscsi iscsiroot=[<servername>]:[<protocol>]:[<port>]:[<LUN>]:<targetname>
>>
>> ==> Question: What aboud a /dev/iscsi or even more exact /dev/iscsi/...lun...?
> 
> I don't think we need to invent a new format here. We've got enough
> legacy issues to keep us busy. :)
> 
>> 	root=??? iscsi_initiator= iscsi_target_name= iscsi_target_ip=
>> iscsi_target_port= iscsi_target_group= iscsi_username= iscsi_password=
>> iscsi_in_username= iscsi_in_password=
>> 	root=??? iscsi_firmware
>>
>> ==> Question: Are these really necessary/used?
> 
> I think the first one is unlikely to be all that useful, given the
> limits on the command line (though maybe it is just my version of
> PXELINUX that is the limit.) Also, there are security issues with having
> that information on the command line (not to mention in cleartext on the
> wire.

Suggestion: We drop this.

> I would like to see some way to support reading iSCSI Boot Firmware
> Table (iBFT) from the BIOS to find our root, so we need a way to tell
> dracut to do so. I don't know if that is root=iscsi:firmware or
> root=blah iscsi=firmware or what.

I'm happy with either. since both would result in netroot=iscsi:firmware.

Thanks again,
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: Netroot cmdline arguments

[David Dillow]

On Wed, 2009-06-10 at 09:41 +0200, Seewer Philippe wrote:
> David Dillow wrote:
> > On Tue, 2009-06-09 at 17:35 +0200, Seewer Philippe wrote:

> >> NFS
> >> ---
> >>
> >> Preferred format:
> >> 	root=nfs[4]:[server:]path[:options]
> >>
> >> Legacy formats:
> >> 	root=/dev/nfs[4] nfsroot=[server:]path[,options]
> >>
> >> If server is unspecified it will be pulled from one of the following
> >> sources, in order:
> >> 	static ip= option on kernel command line
> >> 	DHCP next-server option
> >> 	DHCP server-id option
> >>
> >> Other formats:
> >> 	root=nfs[4]
> >> 	Plain "root=nfs" interprets DHCP root-path option as
> >> 	[ip:]path[:options] 
> >>
> >> ==> Question: I've never used/seen root=nfs before. If server-ip is
> >> missing in root-path should dhcp next-server/server-id be used?
> > 
> > root=nfs is something I did early on as a shortcut for root=/dev/nfs
> > which is supported by the kernel's nfsroot code. Similarly,
> > root={/dev/,}nfs4 is an invention to handle newer NFS versions.
> > 
> > If server-ip is missing, then it should be filled in via the server
> > argument from the appropriate ip= line, or via dhcpd
> > next-server/server-id.
> 
> Hmmm... so you say root=nfs is just a short version of root=/dev/nfs? In 
> that case the documentation isn't up to date, since (see above) root=nfs 
> says specifically that it uses dhcp root-path.

root=nfs works exactly as root=/dev/nfs works exactly as nfsroot=... it
will use DHCP root-path, and override it with the parts it can get from
the command line.

> If this is really a dracut specific "invention" I suggest we drop this.

I'd prefer to keep root=nfs as a shorthand if we keep root=/dev/nfs.
Same for root=nfs4 and root=nfs4.

But this is probably about as hard as I will argue to keep them; they
fall out easily from the legacy support.

> >> NBD
> >> ---
> >>
> >> Preferred format:
> >> 	root=nbd:srv:port[:fstype[:rootflags[:nbdopts]]]
> >>
> >> nbdopts is a comma seperated list of options to give to nbd-client
> >>
> >> Legacy formats:
> >> 	nbdroot=srv,port
> >>
> >> ==> Question: What should root= contain here? Is having no or an empty
> >> root= ok?
> > 
> > Legacy would be root=/dev/ndb[0-9]+ but Warren has suggested we drop
> > that. With my netroot= patches -- coming soon to a list near you! ;) --
> > the NBD handler will default to /dev/nbd0, or will be able to specify
> > root=LABEL=/ or root=/dev/lvm-volume/lv-name etc to use the same
> > features we get when root is on a local disk.
> 
> Hmmm... OK. The point here is that, if say nbdroot= (or iscsiroot=, 
> nfsroot=) is available, we should just ignore root= completely?

Perhaps at current, but not in the very near future -- I'm adding
support for doing proper root on LVM/LUKS when using NBD, so that will
need a root=, but it will default to root=/dev/nbd0 if it is not
present.
 
> >> ==> Question 2: The RFC specifically says hostnames or ipv6 addresses
> >> are allowed for servername. Do we have to support this?
> > 
> > I think we should, yes. IPv6 support is something we're going to want in
> > general, but it will present some challenges to our parsing schemes.
> > 
> > Perhaps we would put some limits on using IPv6 in the legacy options (no
> > ip= static config for IPv6, require the full nfs:IP:server[:,]opts
> > format, etc.)
> 
> Indeed it does. And to think further, there are two ipv6 autoconf 
> possibilities: stateless (router adviced) or stateful (dhcp6).
> 
> Legacy options should be ok, since they only contain "addresses". I'd 
> suggest to add a ip6= option for full ipv6 support later on.

Parsing nfsroot=fe80::2e0:29ff:fe34:de52:/diskless:hard,nointr is going
to be fun. :)

> As for DNS: If we use DHCP, you're correct. It's almost free. But we 
> don't have any ip= options for static configuration to set the DNS 
> Server...

Use DHCP if you want DNS support? Or do host specific and we can
use /etc/resolv.conf.

DHCP can also point us to the right LDAP server etc, but I'm not sure
that's worth the effort. Which I guess is to say I don't care enough to
implement but I wouldn't stop someone else if they did it in a clean
manner and it didn't bloat my initrd if I didn't use it.

Thanks for working on the user experience; I think that will be good for
dracut.

Dave


--
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: Netroot cmdline arguments

[Seewer Philippe]

With input from the current discussion and ignorance of upcoming
netroot patches the current documentation would/should look like
the following:

DHCP
----

Format:
	root=dhcp

Get IP from dhcp, use dhcp root-path option to specify root location.
Contents according to formats below.

Please note: Specifying root=dhcp will ignore further netroot options

NFS
---

Preferred format:
	root=nfs[4]:[server:]path[:options]

Legacy formats:
	root=[[/dev/]nfs[4]] nfsroot=[server:]path[,options]
	root=[[/dev/]nfs[4]] nfsroot=[server:]path[:options]

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
"/tftpboot/%s" will be used.

If server is unspecified it will be pulled from one of the following
sources, in order:
	static ip= option on kernel command line
	DHCP next-server option
	DHCP server-id option
	DHCP root-path option

NFSv4 is only used if explicitly requested; default is NFSv2 or NFSv3
depending on kernel configuration

iSCSI
-----

Preferred format:
	root=iscsi:[<servername>]:[<protocol>]:[<port>]:[<LUN>]:<targetname>

Legacy formats:
	root=[iscsi] iscsiroot=[<servername>]:[<protocol>]:[<port>]:[<LUN>]:<targetname>
 	root=[iscsi] iscsi_firmware

NBD
---
Preferred format:
	root=nbd:srv:port[:fstype[:rootflags[:nbdopts]]]

Legacy formats:
	root=[nbd] nbdroot=srv,port
	root=[nbd] nbdroot=srv:port[:fstype[:rootflags[:nbdopts]]]

nbdopts is a comma seperated list of options to give to nbd-client

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