Netroot cmdline arguments

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

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

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

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

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.

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.

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

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

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.

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.

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.

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

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

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

Uhh. Sorry, forgot to enable word wrap. Apologies.

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.

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.

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.

Very good.

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.

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

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

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

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.

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

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

Again, I suggest we drop this. root=dhcp should stand on its own without further options.

Suggestion: We drop this.

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

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.

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.

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.

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

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

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