Mark A. Carlson wrote:
> Darren J Moffat wrote:
>> ... suggest it be put in "waiting need spec" and that the project
>> team work with the installer and boot teams (in particular I strongly
>> suggest taking advice from Jan for the boot issues).
> Done.
>
> -- mark
Adding materials about investigations made by the project team so far to
solve the bootpath issue, and reflect the purpose of this case.
The project team has been trying different approaches to solve the
'bootpath' issue,
1. Store the bootpath in firmware (OBP).
Details:
This approach needs to create a dedicated option value in OBP space to
store the bootpath,
and then let Solaris kernel read it during booting.
ISSUES:
Negative opinion is received from firmware team for the bootpath of an
iSCSI disk is a Solaris
specific property (not per IEEE 1275), and firmware shouldn't maintain
OS-dependent
properties.
2. Store the bootpath in boot_archive as the existing mechanism to
support UFS booting in x86.
Details:
set the bootpath in file boot/solaris/bootenv.rc with an entry to
contain the bootpath, e.g.,
"setprop bootpath
'/iscsi/ssd at
0000iqn.1986-03.com.sun:02:43644186-e5bb-41f2-8b8e-f34be1afaebc0001,0:a'",
and add this file into the Solaris sparc boot archive.
The Solaris kernel reads the property from archive during boot, and then
mount rootfs on the
bootpath. This is the existing method to support UFS boot in Solaris x86.
For ZFS boot in Solaris x86, the zfs loader reads the bootpath from
rpool and implicitly
passes it to Solaris kernel.
ISSUES:
Storing paths such as this breaks systems as soon as a minor
configuration change impacts the
path. This is a major issue on x86 that has kept OS images from being as
portable. If adopted
it will broaden this back impact to Solaris sparc booting from iSCSI
disk. This part has been
widely pointed with previous emails in this thread.
3. Dynamically build the bootpath before mounting the root disk in
Solaris kernel.
Details:
Solaris build the bootpath with properties from firmware and then tries
to mount the rootfs on it.
ISSUES:
The generated bootpath is not guaranteed to be same as the one used to
contain the rootfs. A typical
iscsi boot path is in the form of,
"/iscsi/ssd at
0000iqn.1986-03.com.sun:2510.600a0b800049c94d00000000493c920b0001,0:a"
with following components,
1. iscsi - the iscsi driver name
2. ssd - the disk driver name/alias
3. 0000 - the initiator ISID
4. iqn.1986-03.com.sun:02:43644186-e5bb-41f2-8b8e-f34be1afaebc
- the target name
5. 0001 - the TargetPortalGroupTag
6. 0 - lun number
7. :a - slice
Here component 2 and 5 can be different with different targets/settings.
For component 5,
It is the TargetPortalGroupTag which can be set in target side. However
a possible solution for
this part could be limiting the TPGT value to a specific number for
booting in delivery documentation,
that will make the problem much simpler.
For component 2,
iSCSI disk can be attached to either 'ssd' and 'sd' (disk), mainly but
not totally decided by the MPxIO support of
the device. For example, an user installed Solaris with root disk
attached to 'ssd', and then the user
changed the MPxIO setting in Solaris then the correct bootpah would be
changed to "../disk at ...".
The above makes that during boot time kernel has to try the possible 2
paths to find the root.
Overall here the best situation would be 2 candidate paths. So to
overcome this a new mechanism
to try to mount the root with possible paths needs to be introduced into
Solaris kernel.
One issue with the above trial-and-error approach is how to
differentiate the bootpath error with the
network configuration/traffic error.
The project has verified all above solutions are valid, and is trying to
select a best approach to solve
the bootpath issue stated, and so is open to comments, and surely other
better approaches.
