Dave Miner wrote: > Jan Damborsky wrote: >> Hi Dave, >> >> >> Dave Miner wrote: >>> Jan Damborsky wrote: >>>> Hi Sarah, Dave, >>>> >>>> could I please ask you to review changes for >>>> following bug? >>>> >>>> 1013 - TI shouldn't destroy 'rpool' on other than target disk >>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=1013 >>>> >>>> Webrev is available at >>>> http://cr.opensolaris.org/~dambi/bug-1013 >>>> >>> One thing that occurred to me which you need to test is whether a root >>> pool that ends up being exported from the block at 488 will still boot >>> after the export. I seem to recall there being a problem with booting >>> a pool that was left exported. >> You are right - when pool is exported, it is no longer bootable. >> When it is then imported, it can be booted again. >> >> Since we are not able to export without loosing the ability to boot, >> should we then just let user know that pool already exists and >> installation can't proceed ? >> > > I think that's the least risky choice at this time. I'd have the > message say that it exists and if the user really wants to use that disk > to run a "zpool destroy" to get rid of the pool then start the installer > again.
This seems reasonable - I am including Frank for this, since it seems there might be some UI changes involved - or should we just display this message on failure screen? > > It would be even better if we could catch this at the Disk screen, but I > think we've got the same problem in target discovery so I don't see how > that could work right now, either. I think this might be doable, if TD would take care of ZFS pool discovery. Then orchestrator and GUI would have appropriate information available by the time target discovery finishes and thus at the moment when GUI starts populating Disk screen with data. Jan
