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