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