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. ... Jan
