A. Introduction

This case modifies the Solaris Zones [1] architecture and describes
how zones will handle boot arguments.

This case is intended to supersede an earlier case "Zone Boot Arguments"[2]
which contains some insufficiently researched information, insufficiently
describes the interface, and was never implemented.  This case also
obsoletes the syntax of the '-s' interface specified in
"Single-User Zone Boot" [3] but does not remove it at this time.

The proposed changes are Evolving (or Stable, depending on the terminology
currently in effect).  The binding for new features is "patch."  The binding
for obsoleted interfaaces is "minor."

B. Interface Table

	   Interface                   Stability       Binding
	 ---------------------------------------------------------
	   -s for zones [old style]     Obsolete       Minor
	   -s for zones [new style]     Evolving       Patch
	   -i for zones                 Evolving       Patch
	   -m for zones                 Evolving       Patch

C. Background

An earlier case, "Single-User Zone Boot"[3] documents the "-s" boot
argument for zones:

	zoneadm -z myzone boot -s

This was primarily done in support of admin/install work ongoing at that
time.  This support has several important limitations:

	- It is limited to the -s argument.

	- It does not work for 'zoneadm reboot' or reboot(1m) inside
	  the zone.

	- It does not mimic the syntax of the most obviously related command,
	  reboot(1m), which requires a "--" (or other string to stop getopt())
	  to separate arguments to reboot from arguments to boot.  As a
          reminder, in Solaris:

		# reboot -s

	  Is not valid syntax.

	- It mixes together arguments to the 'zoneadm' command with arguments
	  ultimately interpreted by init(1m).

	- Administrators running inside the zone are not able to pass
	  options to reboot.

PSARC/2005/167, "Zone Boot Arguments" was intended to solve these problems;
however, the case is not clearly specified and promises features we are
choosing not to deliver (see Section F below).  This cases supersedes PSARC
2005/167, which will be marked as such following approval of this case.

D. New Arguments for Zone Boot

This proposal adds support for the following additional boot arguments:

	- -m <arg>, which was introduced by the SMF project[4]
	- -i </path/to/init>

This proposal anticipates the BrandZ project by adding the kernel plumbing
needed to boot an arbitrary program as 'init'.  Additionally, the argument
processing has been architected in a fashion which should allow brands to
plug in new boot argument parsers (since, e.g. -m may be invalid, or mean
something different on other OS's).

This proposal allows boot arguments to be specified for 'zoneadm boot',
'zoneadm reboot' and for reboot(1m), following a getopt delimiter (--)
or boot file argument (also see Section C.4 below)
The preferred syntax is:

	zoneadm -z myzone boot -- -s
	zoneadm -z myzone reboot -- -i /sbin/myinit
	reboot -- -m verbose

Support for specifying the '-s' option in the old way will continue
to be supported.

	zoneadm -z myzone boot -s

However, documentation for this feature will be removed and replaced with
the new style syntax.

E. Boot Argument Persistence

This proposal adds the ability to persistently specify boot arguments
for zones using the zonecfg(1m) command, as follows:

	# zonecfg -z myzone
	zonecfg:myzone> set bootargs="-m verbose"
	zonecfg:myzone> info bootargs
	bootargs: -m verbose
	zonecfg:myzone> ^D

This setting will be applied unless overridden by 'reboot', 'zoneadm boot'
or 'zoneadm reboot'.  In this respect it is similar to existing system
behavior currently supported by the eeprom(1m) tool.

It is worthwhile to note that this proposal does not alter the fact
that eeprom(1m) is not functional inside of a zone.

F. Arbitrary Boot Parameters

PSARC 2005/167 explained that:

>>
>> This will make it possible to pass arbitrary boot parameters to a
>> zone:
>>
>>       zoneadmd -z local0 boot -- mumble
>>

However, the case neglected to note that this facility is *not* available
for "regular" Solaris boot, which handles the first such argument as the
name of the object to boot, and subsequent arguments as follows:

	global# reboot -- kernel/unix mumble
	...
	(system reboots)
	...
	krtld: Unused kernel arguments: `mumble'.
	...

krtld then discards the extraneous argument (i.e. 'init' never gets to
see 'mumble' in the example).  At this time, we do not believe the utility
of this facility outweighs the confusion that it could cause; we'd rather
not be in the following situation:

	global# reboot foo bar (boot the file called foo, with bar as
				an argument to init(1m))

	myzone# reboot foo bar (boot the zone, with foo and bar as
			        arguments to init(1m))

If demand for this feature occurs in the future, this issue can be revisited
in future case materials.

In the event that the user specifies a boot file for a boot or reboot, we will
detect and silently discard it; thus the following will "just work" from
inside a zone:

	myzone# reboot kernel/unix -s

G. References

1. <a href="../../../2002/174">PSARC 2002/174 Virtualization and Namespace Isolation in Solaris</a>
2. <a href="../../../2005/167">PSARC 2005/167 Zone Boot Arguments</a>
3. <a href="../../../2004/602">PSARC 2004/602 Single-User Zone Boot</a>
4. <a href="../../../2002/547">PSARC 2002/547 Greenline</a>