Jan, auto_install.c: 756: iSCSI boot target might be identified and mounted, but 807 auto_select_install_target() does not automatically select it. Possible actions: - moving 753-802 into auto_select_install_target() and if iscsi_devnam[0] != '\0', take iscsi_devnam as the install disk and set target_disk_identified = B_TRUE, or - passing in iscsi_devnam to auto_select_install_target() do the same if iscsi_devnam[0] != '\0'
I would have a slight preference in the latter, since the iSCSI mount call would remain in the mainline of auto_install.c and not hidden away in auto_select_install_target(). auto_td.c: 214 suggest relaxing case for AIM_TARGET_DEVICE_BOOT_DISK using strcasecmp(3c). There is potential justification for insisting on case matches for device names, since the subsequent routines aren't as lenient, but there is no added value in insisting on a case match for "boot_disk". 218 "but the boot disk was not found", since "none" implies that there could be more than one. The changes making the manifest elements mutually exclusive warrants a release note, since it will break manifests, formerly passing validation, now failing with a confusing error message. The most likely case of this is combining the device name tag with the group 2 tags. This point in the doc should be updated, too. William Jan Damborsky wrote: > Hi William, > > I have incorporated all your suggestions > and the webrev has been updated accordingly: > > http://cr.opensolaris.org/~dambi/bug-7057-cr/ > > Once we agree on the final version, I'll update > bug reports accordingly as well. > > Thank you very much for review, > Jan > > William Schumann wrote: >> Jan, >> Jan Damborsky wrote: >>> William Schumann wrote: >>>> auto_td.c: auto_select_install_target >>>> RE: order or evaluation. c#t#d# formate precedes more >>>> deterministic means, including: physical path, volume name. >>>> Shouldn't the evaluation of the more consistent and deterministic >>>> tags precede the less reliable c#t#d#? >>> >>> This is a good point. As we have discussed, deterministic attributes >>> will have the highest priority and will be processed first. >>> >>> So we would end up with three groups of attributes: >>> >>> G1 - boot disk, devid, physical path, volume name >>> G2 - ctd name >>> G3 - rest of attributes (vendor, bus type, ...) >>> >>> attributes in G1 and G2 will be mutually exclusive, >>> e.g. only one could be specified in AI manifest. >>> They will be also mutually exclusive with G3 as a whole. >> Sounds good. These can be similarly modularized in the code: process >> G1, then G2, then G3, then the default disk selection algorithm. >>> >>> AI schema will be modified to enforce that policy. >> Yes, I think these can be made mutually exclusive in the schema. As >> we discussed, this will enforce strict checking on the user, and >> manifest parse error messages have many problems, which should be >> addressed. The documentation should carefully explain it, and it >> might help to have these commented in the schema - at least to >> indicate that the tags are mutually exclusive. >>> >>> Please let me know if it reflects correctly what has been >>> discussed. >> Yes >>> >>> Also, once we sort this out, I'll update bug reports accordingly. >> Thank you, >> William >
