Dave Miner wrote: > Jan Damborsky wrote: >> 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? >> > > Let's just display that for now. I don't really understand the reasons for import/export of an rpool or why destroying it automatically is a bad idea I'm guessing that it might be part of multi-disk system?
Whatever, the best approach to dealing with it if it can't be automatically destroyed or exported would be to inform the user that to proceed it is necessary to destroy an existing root pool (and the consequences) and allow the user to proceed or cancel. While doing it from any screen (canceling from the progress screen would throw the user back to the summary screen). Better solutions, such as detecting and warning on the Disks screen, are probably out of the question at this point in time. Sending the user to the Fail screen with a message to manually perform a zpool destroy and rerun the installer is pretty ugly. Frank > >>> >>> 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. >> > > Yeah, we were just talking about this with William and we may be able > to just use the "zpool import" output to get what's needed. > > Dave >
