Sarah Jelinek wrote: > > > Jan Damborsky wrote: >> Hi Sarah, >> >> I have done the modifications and updated the webrev >> accrodingly. It is now available at >> >> http://cr.opensolaris.org/~dambi/bug-1013-2/ >> >> Could I please ask you to look at the new changes ? >> >> > Looks fine. Thank you for working so hard on this.
No problem - thank you very much for reviewing this. Jan > > sarah > **** >> Thank you very much, >> Jan >> >> >> Sarah Jelinek wrote: >> >>>>> 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? >>>> >>> yes, where someone has a different root pool named the same. We want >>> to preserve existing pools on alternate targets and not >>> automatically assume we should delete them. >>> >>>> 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. >>>> >>> To do this would require a popup be available at the time the user >>> has chosen the disk for installation. As far as I know we don't >>> currently have this popup available to us in indiana. We had >>> something like this in dwarf. And the code in the GUI that allowed >>> the user to cancel or continue. >>> >>>> Sending the user to the Fail screen with a message to manually >>>> perform a zpool destroy and rerun the installer is pretty ugly. >>>> >>> It is indeed. The issue of course for May Indiana is time left to >>> fix bugs. Right now Jan is coding up a fix that fails the install >>> if there is an existing rpool, and logs the message. This is due to >>> the fact that the finish screen, even in failure, does not translate >>> error codes to error messages to display on the finish screen. The >>> user is required to go to the log for data. >>> >>> Jan's current fix is to detect a duplicate pool right before we try >>> to instantiate the target. This is so we don't modify any existing >>> partition data. So, for now, the best place for us to notify the >>> user of this issue is in the Finish screen. The part I don't like >>> is that we only have the ability log the error and subsequent >>> required action. Niall, can we do something to display an error >>> message on the Finish screen? Rather than just have the user look at >>> the log? >>> >>> thanks, >>> sarah >>> **** >>> >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>> >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >> >>
