On 01/27/10 06:34 AM, Jan Damborsky wrote: > On 01/21/10 08:07 PM, Dave Miner wrote: >> On 01/21/10 12:07 PM, William Schumann wrote: >>> initially misnamed: auto-install creates bogus partition table >>> >>> http://cr.opensolaris.org/~wmsch/bug-13331/ >>> http://defect.opensolaris.org/bz/show_bug.cgi?id=13331 >>> >>> Interoperability issue: in some cases, Jumpstart will create an >>> alternates, or ALT slice. OpenSolaris Target Instantiation is not >>> preserving the ALT slice presently. The fix starts new slice creation >>> after the BOOT slice and the ALT slice, if present. >> >> Looks OK. I do think we need to assess whether creating alternate >> slices on non-SCSI disks is required in the installer, though. > > I had discussion some time ago with Shidokht Yadegari about how > user could get rid of existing ALT slice (format -e allows this) > he pointed out with respect to the ALT slice during that discussion: > > ... > Yes, We don't create slice 9 for scsi disks on x86. > DKIOCADDBAD ioctl has not been supported on scsi disks since > PSARC 1997/281 (guess who submitted it ;-)), when we switched to use > sd instead of cmdk for scsi disks. Later on, creating the alternate slice > for scsi disks in sd was removed all together. > > I agree with this slice being kind of useless and probably nobody > uses addbadsec anymore. However imho, the installer has to agree > with kernel and disk partitioning utility. If we want to not make > slice 9 on these devices anymore, I believe the proper way of fixing > it would be by EOLing the addbadsec, DKIOCADDBAD ioctl and changing > target driver, utilities and installer to all agree on that. > Otherwise if addbadsec is still not ready to be EOLed, then installer > should create the slice and be consistent. > > I think we need a low pri bug to be filed for caiman. We may need a > separate RFE later probably against cmdk and format to get rid of alt > slice. > Perhaps it should have dealt with when sata framework was introduced and > some ide devices migrated from cmdk to sd. > ... >
If you wouldn't mind following up with Shidokht and agreeing on where this needs to go, I'd appreciate it. Dave
