How do we want to handle configuring network boot devices?

How do we want to handle configuring network boot devices?

[David Dillow]

Warren, Andreas, and I were discussing possible mechanisms for
configuring NFS, NBD, iSCSI, etc going forward, and it was suggested
that we try to document the current ways it is done, and how we may want
to go forward.

Assumptions:
* I've missed some ways of doing this; feel free to point us in the
	right direction.
* IP autoconfig follows the kernel command line described in the same
	document as Kernel nfsroot, with possible compatible extensions.
	This "ip=dhcp" and friends.

Existing standards/implementations:
iSCSI
* root selection via DHCP is documented by RFC4173
	format is iscsi:[SERVER]:[PROTO]:[PORT]:[LUN]:TARGET
	minimum config is "iscsi:::::TARGET"
* RH mkinitrd pulls iSCSI info from host system config
* There appears to be some support for "iSCSI Boot Firmware Attributes"
which may be useful, or not.
	http://en.wikipedia.org/wiki/ISCSI_Boot_Firmware_Table
	ftp://ftp.software.ibm.com/systems/support/system_x_pdf/ibm_iscsi_boot_firmware_table_v1.02.pdf

NBD
* RH mkinitrd uses the DHCP root-path option
	format is nbd:SERVER:PORT:FSTYPE[:MOUNTOPTS]
	you can specify the filsystem type to mount and
	the options to use in the DHCP option
* There does not appear to be a way to configure NBD in RH's mkinitrd
	without using DHCP
* I haven't found other initramfs's using NBD, but I've not searched
	very hard.

NFS
* Kernel command line, as documented in Documentation/filesystems/nfsroot.txt
	root=/dev/nfs
	nfsroot=[ip:]path[,options]
		Replaces %s in path with text IP address
		If option missing, path defaults to "/tftpboot/%s"
		If IP is missing, uses server address from ip= line
* DHCP root-path option, with varying forms
	Using next-server or server-id opt and root-path as pure path:
		${next_server-${server_id}}:${root_path}
	Using root-path as full info:
		server:path
	Current dracut uses DHCP root-path option:
		nfs://server/path
	My udev nfsroot patchset uses DHCP root-path option with command line override:
		[ip:]path[:options]

URI scheme proposed at http://apps.sourceforge.net/trac/dracut/wiki/commandline
	root=nfs://server:port/path 
	root=nbd://server:port/path 
	root=iscsi://server:port/target 


Open issues:
* How to handle authentication data for iSCSI and NFS, if at all.
* How to handle unionfs/aufs mounts?
* How to handle dm-snapshot, eg for LiveCD overlays.
* FCoE/AoE/DBRD/SRP -- I didn't search for examples on these.
* Lustre/network filesystem du jour support -- I think these are
possible, just need to be careful parsing things out. Not
terribly important right now.
* Using the dracut URI scheme above as a strawman, shouldn't
"root=nfs://...." imply "ip=dhcp" if none is given?
* What about multiple devices?
* How many legacy ways of doing this should we support?
* How do we separate options to the network block transport vs the
filesystem mount?
* How do we allow use of these features both via the cmdline and via
DHCP?


My commentary:
* I'd like to support the legacy way of specifying this info as much as
is reasonably possible. People are set in their ways, and it'd be nice
if dracut could just work for them.
* If we don't succeed in DHCPing/mounting the root on the first attempt,
we should loop trying, with a chance for the user to break out each time
-- think overloaded server bringing up a cluster.
* A modified URI scheme like the dracut suggestion may work; use opaque
URI's like the RFC4173 iSCSI root-path, or RH mkinitrd's nbd root-path.
We could source a specific handler for the URI type listed, making it
simpler to add new types in the future.
* While adding vendor-specific DHCP options is not a really good idea in
general, I see cases we may want to support that simply will not fit in
the 255 chars available to us in root-path, or which would make parsing
that be unnecessarily complex.
* When testing things, it is really nice to be able to override the DHCP
config via the kernel command line when possible. It's much cleaner to
edit a single PXE boot file (or add it via the serial console) when
working alongside a production environment -- less to remember to revert
(and restart!)


Ok, put on your asbestos underwear and wade on in. A consensus would be
really helpful as we have quite a few people working in the network boot
area and it would be great if we had a defined way forward for config.

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: How do we want to handle configuring network boot devices?

[Julien Cristau]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

On Sat, May 23, 2009 at 21:00:16 -0400, David Dillow wrote:

> Warren, Andreas, and I were discussing possible mechanisms for
> configuring NFS, NBD, iSCSI, etc going forward, and it was suggested
> that we try to document the current ways it is done, and how we may want
> to go forward.
> 
For what it's worth, the attached initramfs scripts are included in the
nbd-client and open-iscsi Debian packages.

Cheers,
Julien

[-- Attachment #2: nbd-client.initrd --]
[-- Type: text/plain, Size: 1557 bytes --]

#!/bin/sh

# We don't have any prerequisites
case $1 in
prereqs)
	exit 0
	;;
esac

. /scripts/functions

log_begin_msg "Setting up nbd-client"
for x in $(cat /proc/cmdline); do
	# We don't need to redo what all of what /init already did...
	case $x in
		nbdroot=*,*,*)
			nbdroot="${x#nbdroot=}"
			nbdsrv=$(echo "$nbdroot" | sed -e "s/,.*$//")
			nbdport=$(echo "$nbdroot" | sed -e "s/,([^,]*),.*$/\1/")
			nbdbasedev=$(echo "$nbdroot" | sed -e "s/^.*,//")
			nbdrootdev=/dev/$nbdbasedev
			;;
		nbdroot=*,*)
			nbdroot="${x#nbdroot=}"
			nbdsrv=$(echo "$nbdroot" | sed -e "s/,[^,]*$//")
			nbdport=$(echo "$nbdroot" | sed -e "s/^[^,]*,//")
			;;
		ip=*)
			IPOPTS="${x#ip=}"
			;;
		root=/dev/nbd*)
			nbdrootdev="${x#root=}"
			nbdbasedev="${x#root=/dev/}"
			;;
	esac
done

nbdrootdev=${nbdrootdev%p*}
nbdbasedev=${nbdbasedev%p*}

if [ -z "$nbdport" -o -z "$nbdrootdev" ]
then
	log_failure_msg "Insufficient information to set up nbd, quitting (nbdsrv=$nbdsrv nbdport=$nbdport nbdroot=$nbdroot root=$nbdrootdev)"
	exit 0
fi

DEVICE=eth0

configure_networking

if [ -z "$nbdsrv" ]
then
	nbdsrv=${ROOTSERVER}
fi

if [ -z "$nbdsrv" ]
then
	log_failure_msg "Insufficient information to set up nbd, quitting (nbdsrv=$nbdsrv nbdport=$nbdport nbdroot=$nbdroot root=$nbdrootdev)"
	exit 0
fi

/sbin/nbd-client $nbdsrv $nbdport $nbdrootdev -persist
# This should be removed once the cfq scheduler no longer deadlocks nbd
# devices
if grep '\[cfq\]' /sys/block/$nbdbasedev/queue/scheduler >/dev/null
then
	echo deadline > /sys/block/$nbdbasedev/queue/scheduler
fi

[-- Attachment #3: initramfs.local-top --]
[-- Type: text/plain, Size: 1871 bytes --]

#!/bin/sh

PREREQ=""

prereqs()
{
	echo "$PREREQ"
}

case $1 in
# get pre-requisites
prereqs)
	prereqs
	exit 0
	;;
esac

do_iscsi_login ()
{
	# Bring in the main config
	. /conf/initramfs.conf
	for conf in conf/conf.d/*; do
		[ -f ${conf} ] && . ${conf}
	done
	. /scripts/functions

	configure_networking

	modprobe iscsi_tcp
	modprobe crc32c

	if [ -z $ISCSI_INITIATOR ]; then
		. /etc/initiatorname.iscsi
		ISCSI_INITIATOR=$InitiatorName
	fi

	if [ -z $ISCSI_TARGET_PORT ]; then
		ISCSI_TARGET_PORT=3260
	fi

	if [ -z $ISCSI_TARGET_GROUP ]; then
		ISCSI_TARGET_GROUP=1
	fi

	iscsistart -i $ISCSI_INITIATOR -t $ISCSI_TARGET_NAME	\
		   -g $ISCSI_TARGET_GROUP -a $ISCSI_TARGET_IP	\
		   -p $ISCSI_TARGET_PORT $ISCSI_USERNAME	\
		   $ISCSI_PASSWORD $ISCSI_IN_USERNAME $ISCSI_IN_PASSWORD
}

parse_iscsi_ops ()
{
	. /etc/iscsi.initramfs

	for x in $(cat /proc/cmdline); do
		case ${x} in
        	iscsi_initiator=*)
                	ISCSI_INITIATOR="${x#iscsi_initiator=}"
                	;;
        	iscsi_target_name=*)
                	ISCSI_TARGET_NAME="${x#iscsi_target_name=}"
                	;;
        	iscsi_target_ip=*)
                	ISCSI_TARGET_IP="${x#iscsi_target_ip=}"
                	;;
        	iscsi_target_port=*)
                	ISCSI_TARGET_PORT="${x#iscsi_target_port=}"
                	;;
		iscsi_target_group=*)
			ISCSI_TARGET_GROUP="${x#iscsi_target_group=}"
			;;
		iscsi_username=*)
			ISCSI_USERNAME="-u ${x#iscsi_username=}"
			;;
		iscsi_password=*)
			ISCSI_PASSWORD="-w ${x#iscsi_password=}"
			;;
		iscsi_in_username=*)
			ISCSI_IN_USERNAME="-U ${x#iscsi_in_username=}"
			;;
		iscsi_in_password=*)
			ISCSI_IN_PASSWORD="-W ${x#iscsi_in_password=}"
			;;
		esac
	done
}

if [ ! -x /sbin/iscsistart ]; then
	exit 0
fi

parse_iscsi_ops

if [ -z $ISCSI_TARGET_NAME ] || [ -z $ISCSI_TARGET_IP ]; then
	exit 0
fi

do_iscsi_login

exit 0

Re: How do we want to handle configuring network boot devices?

[Warren Togami]

On 05/23/2009 09:00 PM, David Dillow wrote:
> * I haven't found other initramfs's using NBD, but I've not searched
> 	very hard.

Debian/Ubuntu's initramfs-tools allows you to hard-code a NBD server and 
port during initrd generation.

>
> NFS
> * Kernel command line, as documented in Documentation/filesystems/nfsroot.txt
> 	root=/dev/nfs
> 	nfsroot=[ip:]path[,options]
> 		Replaces %s in path with text IP address
> 		If option missing, path defaults to "/tftpboot/%s"
> 		If IP is missing, uses server address from ip= line

This is an abomination.  I haven't anyone ever use this.  In-kernel dhcp 
client?  How do you control which interface to use?  Seems like a lot of 
room for error.  Also it seems this relies on having no initrd, 
bypassing other things you may want to do before mounting rootfs like 
load policy?

Options:
1) Re-implement it entirely in dracut without relying on the kernel 
implementation.  But will it work?  The kernel seeing root=/dev/nfs will 
try to do its own thing anyway?
2) Drop this entirely.  If somebody chooses to use this method of nfs 
boot dracut isn't involved.

> * DHCP root-path option, with varying forms
> 	Using next-server or server-id opt and root-path as pure path:
> 		${next_server-${server_id}}:${root_path}

This particular method is ambiguous, why next-server or server-id?

I think we should seriously consider that we shouldn't be concerned with 
every possible legacy method of setting up nfsroot.  Each generation of 
software has the opportunity to configure itself in the way that it 
needs.  What scenarios are there where this isn't true?

I mean, if you use old software, don't use dracut.

> Debian style syntax. With the base device being an optional number to indicate
> the nbd device to use.
>
> 	root=/dev/nbd[0-9]* nbdroot=server.ip.add.ress,port[,nbd basedevice]

This is from Andreas' suggested patch for nbd root, where this is the 
third supported method of booting nbd.  I think we should DROP this. 
The reason for this is it used to be necessary to define a specific nbd 
device number because old versions of nbd-client did not have a method 
to detect if a nbd device is already connected and in-use.  Modern 
versions do not have this problem.  Code using it simply iterates 
looking for the first unused nbd device.

The ability to specify a nbd mount point with cmdline should be using 
the new syntax.  We should drop this old syntax because it is redundant, 
and more error prone.

> 	Using root-path as full info:
> 		server:path
> 	Current dracut uses DHCP root-path option:
> 		nfs://server/path

Where did this syntax come from?  Is there precedent?  If not, I don't 
think Dracut should be inventing something new only because it visually 
looks better.

> 	My udev nfsroot patchset uses DHCP root-path option with command line override:
> 		[ip:]path[:options]

What are possible options for nfs?

>
> URI scheme proposed at http://apps.sourceforge.net/trac/dracut/wiki/commandline
> 	root=nfs://server:port/path
> 	root=nbd://server:port/path
> 	root=iscsi://server:port/target

(Same note as above, I don't think Dracut should be inventing new syntax 
only because it looks better, especially when it is functionally less 
expressive than the existing RFC's and implementations.)

> Open issues:
> * How to handle authentication data for iSCSI and NFS, if at all.

Does this always involve certificates or keys?  If so, we might have no 
option but to make it embedded in the initrd during generation.

> * How to handle unionfs/aufs mounts?

Debian/Ubuntu and possibly others will demand this, as this is their 
solution to read-only root netboot.  How to sanely define this in the 
initrd while still maintaining a generalized initrd?  Perhaps not possible.

> * How to handle dm-snapshot, eg for LiveCD overlays.

Same problem as above.

> * FCoE/AoE/DBRD/SRP -- I didn't search for examples on these.
> * Lustre/network filesystem du jour support -- I think these are
> possible, just need to be careful parsing things out. Not
> terribly important right now.

Define a sane standard for our existing protocols first, then it might 
become more clear what we should do for others?

> * Using the dracut URI scheme above as a strawman, shouldn't
> "root=nfs://...." imply "ip=dhcp" if none is given?

ip=dhcp should be implied if you specify root=dhcp or any other option 
that needs dhcp to go online, while not otherwise specified static.

> * What about multiple devices?

AFAIK nothing out there supports booting from the second interface.  Am 
I wrong?

> * How many legacy ways of doing this should we support?

I am suggesting *NONE* for the above reasons.

> * How do we separate options to the network block transport vs the
> filesystem mount?

What network block transport options are you talking about?

> * How do we allow use of these features both via the cmdline and via
> DHCP?

root=(what would come from root-path?)

If that clashes with in-kernel stuff, we could define our own:

root-path=(what would come from root-path)

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: How do we want to handle configuring network boot devices?

[David Dillow]

On Wed, 2009-05-27 at 17:54 -0400, Warren Togami wrote:
> On 05/23/2009 09:00 PM, David Dillow wrote:
> > * I haven't found other initramfs's using NBD, but I've not searched
> > 	very hard.
> 
> Debian/Ubuntu's initramfs-tools allows you to hard-code a NBD server and 
> port during initrd generation.

Yes, Julien was kind enough to post the scripts that handle this for
Debian.

> > NFS
> > * Kernel command line, as documented in Documentation/filesystems/nfsroot.txt
> > 	root=/dev/nfs
> > 	nfsroot=[ip:]path[,options]
> > 		Replaces %s in path with text IP address
> > 		If option missing, path defaults to "/tftpboot/%s"
> > 		If IP is missing, uses server address from ip= line
> 
> This is an abomination.  I haven't anyone ever use this. In-kernel dhcp 
> client?  How do you control which interface to use? 

ip= lines are also parsed by the kernel and can be used for this.

> Seems like a lot of 
> room for error.  Also it seems this relies on having no initrd, 
> bypassing other things you may want to do before mounting rootfs like 
> load policy?
> 
> Options:
> 1) Re-implement it entirely in dracut without relying on the kernel 
> implementation.  But will it work?  The kernel seeing root=/dev/nfs will 
> try to do its own thing anyway?
> 2) Drop this entirely.  If somebody chooses to use this method of nfs 
> boot dracut isn't involved.

Well, yes, Warren. If the kernel has CONFIG_ROOT_NFS set and sees these
options, I expect the initrd will not be used. But I don't think any
distro that dracut would support has this set. Certainly it has caused
no problems in my writing and testing the nfsroot code I did last month.

> > * DHCP root-path option, with varying forms
> > 	Using next-server or server-id opt and root-path as pure path:
> > 		${next_server-${server_id}}:${root_path}
> 
> This particular method is ambiguous, why next-server or server-id?

If next-server is set, use it. If not, use server-id. This method has
been long used and is unambiguous. 

> I think we should seriously consider that we shouldn't be concerned with 
> every possible legacy method of setting up nfsroot.  Each generation of 
> software has the opportunity to configure itself in the way that it 
> needs.  What scenarios are there where this isn't true?
> 
> I mean, if you use old software, don't use dracut.

This isn't about using old software, it is about allowing old
configuration methods to work so that dracut can be a drop in
replacement. I'm not saying these are all good ways to do it, or that we
necessarily need to support all of them, but if they are easy to map to
our solution once we choose it, then it makes sense to do so.

It's nice when software is usable without having to read all of the
documentation -- in many ways, this allows a dracut-enabled distro to be
dropped into place in an existing DHCP environment, which may have
thousands of nodes using the existing syntax.

Is it a requirement to support legacy methods? Probably not, but again,
I think we should consider the pain involved in doing it. If it is low,
then perhaps it makes sense.

If other people chime in and agree with you about dropping legacy
methods, then I'll happily shut up about it and not worry about
compatibility. While easy, it is code to written.

> > 	Using root-path as full info:
> > 		server:path
> > 	Current dracut uses DHCP root-path option:
> > 		nfs://server/path
> 
> Where did this syntax come from?  Is there precedent?  If not, I don't 
> think Dracut should be inventing something new only because it visually 
> looks better.

I thought that came from you. Harold maybe?

> > 	My udev nfsroot patchset uses DHCP root-path option with command line override:
> > 		[ip:]path[:options]
> 
> What are possible options for nfs?

man 5 nfs, or look through fs/nfs/nfsroot.c in the kernel source. There
are several, and many get used often to meet the needs of the
environment.

> > * Using the dracut URI scheme above as a strawman, shouldn't
> > "root=nfs://...." imply "ip=dhcp" if none is given?
> 
> ip=dhcp should be implied if you specify root=dhcp or any other option 
> that needs dhcp to go online, while not otherwise specified static.

Agreed, unless ip= lines are supplied in which case they should
override.

> > * What about multiple devices?
> 
> AFAIK nothing out there supports booting from the second interface.  Am 
> I wrong?

gedi-tools.sf.net will boot from whatever interface and remap it to
eth0. You yourself were complaining about issues with wireless. I have
several machines in which the interface they should boot of off is not
eth0, and it is not possible to swap the order of the cards.

Besides, it is already implemented, sans bugs from my forward port.

> > * How do we separate options to the network block transport vs the
> > filesystem mount?
> 
> What network block transport options are you talking about?

I'm holding open the possibility that there are some. iSCSI may have
some, but I am not that familiar with it. NBD does not; I don't know
about DBRD. SRP does have options that would need to be handled, but
that could be dealt with later.

Mainly, I think this is just another nail in the coffin of the URI
type:// syntax.



--
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: How do we want to handle configuring network boot devices?

[David Dillow]

On Wed, 2009-05-27 at 20:23 -0400, David Dillow wrote:
> On Wed, 2009-05-27 at 17:54 -0400, Warren Togami wrote:
> > This is an abomination.  I haven't anyone ever use this. In-kernel dhcp 
> > client?  How do you control which interface to use? 
>
> ip= lines are also parsed by the kernel and can be used for this.

I should also note that this only takes effect if CONFIG_IP_PNP is set,
which is again not the case for most distros.


--
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: How do we want to handle configuring network boot devices?

[Warren Togami]

On 05/27/2009 08:23 PM, David Dillow wrote:
>> Options:
>> 1) Re-implement it entirely in dracut without relying on the kernel
>> implementation.  But will it work?  The kernel seeing root=/dev/nfs will
>> try to do its own thing anyway?
>> 2) Drop this entirely.  If somebody chooses to use this method of nfs
>> boot dracut isn't involved.
>
> Well, yes, Warren. If the kernel has CONFIG_ROOT_NFS set and sees these
> options, I expect the initrd will not be used. But I don't think any
> distro that dracut would support has this set. Certainly it has caused
> no problems in my writing and testing the nfsroot code I did last month.

OK, I personally am not interested in this behavior.  I will leave it up 
to others if dracut should support it.

>
>>> * DHCP root-path option, with varying forms
>>> 	Using next-server or server-id opt and root-path as pure path:
>>> 		${next_server-${server_id}}:${root_path}
>> This particular method is ambiguous, why next-server or server-id?
>
> If next-server is set, use it. If not, use server-id. This method has
> been long used and is unambiguous.

Ditto.

>
>> I think we should seriously consider that we shouldn't be concerned with
>> every possible legacy method of setting up nfsroot.  Each generation of
>> software has the opportunity to configure itself in the way that it
>> needs.  What scenarios are there where this isn't true?
>>
>> I mean, if you use old software, don't use dracut.
>
> This isn't about using old software, it is about allowing old
> configuration methods to work so that dracut can be a drop in
> replacement. I'm not saying these are all good ways to do it, or that we
> necessarily need to support all of them, but if they are easy to map to
> our solution once we choose it, then it makes sense to do so.
>
> It's nice when software is usable without having to read all of the
> documentation -- in many ways, this allows a dracut-enabled distro to be
> dropped into place in an existing DHCP environment, which may have
> thousands of nodes using the existing syntax.

The dracut documentation should reduce confusion by describing one 
official syntax.  I'll leave it up to others to decide if dracut should 
support legacy/deprecated syntaxes.  I guess I don't care too much to 
fight it.

>
>>> * What about multiple devices?
>> AFAIK nothing out there supports booting from the second interface.  Am
>> I wrong?
>
> gedi-tools.sf.net will boot from whatever interface and remap it to
> eth0. You yourself were complaining about issues with wireless. I have
> several machines in which the interface they should boot of off is not
> eth0, and it is not possible to swap the order of the cards.
>
> Besides, it is already implemented, sans bugs from my forward port.

OK, another case where I don't care about it, as long as other people 
make the code work.

Might I ask though, if no ip= line is supplied, assume dhcp and use only 
whatever it thinks is eth0.

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: How do we want to handle configuring network boot devices?

[Warren Togami]

On 05/27/2009 05:54 PM, Warren Togami wrote:
>> root=/dev/nbd[0-9]* nbdroot=server.ip.add.ress,port[,nbd basedevice]
>
> This is from Andreas' suggested patch for nbd root, where this is the
> third supported method of booting nbd. I think we should DROP this. The
> reason for this is it used to be necessary to define a specific nbd
> device number because old versions of nbd-client did not have a method
> to detect if a nbd device is already connected and in-use. Modern
> versions do not have this problem. Code using it simply iterates looking
> for the first unused nbd device.
>
> The ability to specify a nbd mount point with cmdline should be using
> the new syntax. We should drop this old syntax because it is redundant,
> and more error prone.
>

While I don't care so much if the other legacy methods go into dracut, I 
might suggest strongly against including this one.  In addition to the 
other reasons:

* It was never used with DHCP root-path in the past.
* It relied on other hard-coded things that you don't see to specify the 
filesystem type and aufs/unionfs layering on top.  Note that it doesn't 
include filesystem type and mount options.

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: How do we want to handle configuring network boot devices?

[Victor Lowther]

On Wed, 2009-05-27 at 22:52 -0400, Warren Togami wrote:
> On 05/27/2009 08:23 PM, David Dillow wrote:
> >> Options:
> >> 1) Re-implement it entirely in dracut without relying on the kernel
> >> implementation.  But will it work?  The kernel seeing root=/dev/nfs will
> >> try to do its own thing anyway?
> >> 2) Drop this entirely.  If somebody chooses to use this method of nfs
> >> boot dracut isn't involved.
> >
> > Well, yes, Warren. If the kernel has CONFIG_ROOT_NFS set and sees these
> > options, I expect the initrd will not be used. But I don't think any
> > distro that dracut would support has this set. Certainly it has caused
> > no problems in my writing and testing the nfsroot code I did last month.

If an initrd/initramfs is used, the kernel will not check any root=
arguments, nfs or otherwise (IIRC).

> OK, I personally am not interested in this behavior.  I will leave it up 
> to others if dracut should support it.
> 
> >
> >>> * DHCP root-path option, with varying forms
> >>> 	Using next-server or server-id opt and root-path as pure path:
> >>> 		${next_server-${server_id}}:${root_path}
> >> This particular method is ambiguous, why next-server or server-id?
> >
> > If next-server is set, use it. If not, use server-id. This method has
> > been long used and is unambiguous.
> 
> Ditto.
> 
> >
> >> I think we should seriously consider that we shouldn't be concerned with
> >> every possible legacy method of setting up nfsroot.  Each generation of
> >> software has the opportunity to configure itself in the way that it
> >> needs.  What scenarios are there where this isn't true?
> >>
> >> I mean, if you use old software, don't use dracut.
> >
> > This isn't about using old software, it is about allowing old
> > configuration methods to work so that dracut can be a drop in
> > replacement. I'm not saying these are all good ways to do it, or that we
> > necessarily need to support all of them, but if they are easy to map to
> > our solution once we choose it, then it makes sense to do so.
> >
> > It's nice when software is usable without having to read all of the
> > documentation -- in many ways, this allows a dracut-enabled distro to be
> > dropped into place in an existing DHCP environment, which may have
> > thousands of nodes using the existing syntax.
> 
> The dracut documentation should reduce confusion by describing one 
> official syntax.  I'll leave it up to others to decide if dracut should 
> support legacy/deprecated syntaxes.  I guess I don't care too much to 
> fight it.

We should support legacy syntax where it makes sense, at least.

However, I would rather see a working release kicked out the door for
people to play with than start prematurely arguing over arcane details
most of the world does not care about in the name of elegance.

> >
> >>> * What about multiple devices?
> >> AFAIK nothing out there supports booting from the second interface.  Am
> >> I wrong?
> >
> > gedi-tools.sf.net will boot from whatever interface and remap it to
> > eth0. You yourself were complaining about issues with wireless. I have
> > several machines in which the interface they should boot of off is not
> > eth0, and it is not possible to swap the order of the cards.
> >
> > Besides, it is already implemented, sans bugs from my forward port.
> 
> OK, another case where I don't care about it, as long as other people 
> make the code work.
> 
> Might I ask though, if no ip= line is supplied, assume dhcp and use only 
> whatever it thinks is eth0.

Only if doing something else that requires the network to work.
Bringing up the network interface in the initramfs when booting from a
local block device is decidedly suboptimal. :)

> 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
-- 
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019

--
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: How do we want to handle configuring network boot devices?

[Harald Hoyer]

Ok, I updated
https://apps.sourceforge.net/trac/dracut/wiki/commandline
for the boot mechanism we should support in our first version. I removed the URI 
style root, because I misread the iscsi root path syntax the first time (no "//" 
involved).

Please correct/extend the list.

For e.g. password/user authentication, we have to inject conf files in the cpio 
archive, because /proc/cmdline is readable by everyone or use the dhcp root_path 
or other dhcp options.
--
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: How do we want to handle configuring network boot devices?

[Warren Togami]

On 05/28/2009 11:42 AM, Harald Hoyer wrote:
> Ok, I updated
> https://apps.sourceforge.net/trac/dracut/wiki/commandline
> for the boot mechanism we should support in our first version. I removed
> the URI style root, because I misread the iscsi root path syntax the
> first time (no "//" involved).
>
> Please correct/extend the list.
>
> For e.g. password/user authentication, we have to inject conf files in
> the cpio archive, because /proc/cmdline is readable by everyone or use
> the dhcp root_path or other dhcp options.

I suspect none dhcp root-path is unsuitable too, because it is blatantly 
transmitted in clear text.  This is also an issue for including it in a 
config file for PXE boot because the initrd must be transmitted 
unencrypted over the wire.

The only "secure" way of handling secrets in the initrd is if the initrd 
is on a local disk within a client.  It is plausible that some users 
would opt to boot from local disks, and mount root filesystem over the 
network for benefits of easy central management.

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: How do we want to handle configuring network boot devices?

[Seewer Philippe]

Harald Hoyer wrote:
> Ok, I updated
> https://apps.sourceforge.net/trac/dracut/wiki/commandline
> for the boot mechanism we should support in our first version. I removed 
> the URI style root, because I misread the iscsi root path syntax the 
> first time (no "//" involved).
> 
> Please correct/extend the list.

suggestions:

root=dhcp
<     get IP from dhcp server, root-path option from dhcp specifies root location 
---
>     get IP from dhcp server, root-path option from dhcp specifies root location, implies ip=dhcp 

NFS
< root=[<server-ip>:]<root-dir>[,<nfs-options>]
< root=??? nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]
---
> root=nfs:[<server-ip>:]<root-dir>[,<nfs-options>]
> root=/dev/nfs nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]

or 

< root=[<server-ip>:]<root-dir>[,<nfs-options>]
< root=??? nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]
---
> root=nfs:[<server-ip>:]<root-dir>[,<nfs-options>]
> root=[ignored] nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]

[ignored] applies to nbd, etc as well. 



> For e.g. password/user authentication, we have to inject conf files in 
> the cpio archive, because /proc/cmdline is readable by everyone or use 
> the dhcp root_path or other dhcp options.

I really suggest to ignore authenticated networks and -mounts for now. dracut v2 can handle that...

--
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: How do we want to handle configuring network boot devices?

[Seewer Philippe]

David Dillow wrote:
[snip]
> Open issues:
> * How to handle authentication data for iSCSI and NFS, if at all.

NFS4 only needs authentication data if kerberized. I suggest to postpone 
this for (a lot) later. The same applies for Wireless or stuff like 802.1x.

> * How to handle unionfs/aufs mounts?
> * How to handle dm-snapshot, eg for LiveCD overlays.

Do we really have to support these two? I suggest this is something 
distributors can add with their own mount/pre-pivot modules

> * FCoE/AoE/DBRD/SRP -- I didn't search for examples on these.
> * Lustre/network filesystem du jour support -- I think these are
> possible, just need to be careful parsing things out. Not
> terribly important right now.

If we can generalize the parsing these shouldn't be a problem at all. 
Same goes with other weird cases like booting from CIFS.

> * Using the dracut URI scheme above as a strawman, shouldn't
> "root=nfs://...." imply "ip=dhcp" if none is given?

It would be user friendly, agreed. But for the sake of forceing people 
to think at least a bit I suggest to imply ip=dhcp only if root=dhcp.

> * What about multiple devices?

Must be supported.

I've previously outlined problematic cases here:
http://article.gmane.org/gmane.linux.kernel.initramfs/393

A first set of patches supporting different boot-cases is here:
http://article.gmane.org/gmane.linux.kernel.initramfs/411
http://article.gmane.org/gmane.linux.kernel.initramfs/409
http://article.gmane.org/gmane.linux.kernel.initramfs/410

The gist of it is that netif configuration needs to be synchronized so 
only one netif can be up at any one time. I'll rebase these patches on 
your work next friday.

> * How many legacy ways of doing this should we support?

As many as possible. Will make transision easier. The current 
commandline document is pretty complete I think.

Again I think this is just a matter of parsing options.

> * How do we separate options to the network block transport vs the
> filesystem mount?

To be honest, I don't quite get what you mean here.

> * How do we allow use of these features both via the cmdline and via
> DHCP?

I'd say either the cmdline is specific or it says dhcp.

> My commentary:
> * I'd like to support the legacy way of specifying this info as much as
> is reasonably possible. People are set in their ways, and it'd be nice
> if dracut could just work for them.
> * If we don't succeed in DHCPing/mounting the root on the first attempt,
> we should loop trying, with a chance for the user to break out each time
> -- think overloaded server bringing up a cluster.

I agree. Problem is if we want to loop and support multiple devices we 
can't do everything with udev since udev doesn't block operations on 
non-related devices.

Question: Anyone have a problem if network boot mount is not handled 
from udev? As much as I'd like I can't think of a sensible way to to this.

> * A modified URI scheme like the dracut suggestion may work; use opaque
> URI's like the RFC4173 iSCSI root-path, or RH mkinitrd's nbd root-path.
> We could source a specific handler for the URI type listed, making it
> simpler to add new types in the future.

That's a good idea. With keeping in line with mounting outside udev we 
could do:

loop until mounted {
   wait for network
   source all registered option handlers, setting mount-variables
   source mount-script
}
fs-specific stuff like moving rpcbind data etc can go in pre-pivot.

This is already feasible with the current mount-loop, since the mount 
script has number 99. And that way each fs-type just has to provide a 
parser-module. I guess we can provide some helper functions to wrap 
getarg and parse dhcp-options.


> * While adding vendor-specific DHCP options is not a really good idea in
> general, I see cases we may want to support that simply will not fit in
> the 255 chars available to us in root-path, or which would make parsing
> that be unnecessarily complex.

Again, simply a matter of parsing options.

> * When testing things, it is really nice to be able to override the DHCP
> config via the kernel command line when possible. It's much cleaner to
> edit a single PXE boot file (or add it via the serial console) when
> working alongside a production environment -- less to remember to revert
> (and restart!)

As suggested: use dhcp root options only if explicitely requested by the 
commandline.

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