On Fri, Sep 11, 2009 at 11:31:10PM +0800, Jack Meng wrote: > The project team has been trying different approaches to solve the > 'bootpath' issue, > > 2. Store the bootpath in boot_archive as the existing mechanism to > support UFS booting in x86. > > 3. Dynamically build the bootpath before mounting the root disk in > Solaris kernel.
How about a combination? Since the issue is really about "which disk driver to layer above iSCSI" why not: a) pick a default driver, b) allow one to be specified in the boot archive or as a boot argument. See below. > 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. Er, how can the OBP not know about TPGT? If the OS needs to know that, and since it's not OS-specific, then the firmware should provide that information. If by oversight the OBP does not provide TPGT, then defaulting its value plus allowing for a boot archive/option override seems like a reasonable approach. > 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. Just because of the driver selection you'd force the admin to put the entire bootpath in the boot archive? That seems to me like throwing the baby out with the bathwater. Why would choosing a default driver selection, and allowing boot archive/option override, not be a good enough solution? Nico --
