[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#492899: partman-crypto: cancel button unusable on "Erasing data" screen

On Wed, Jul 30, 2008 at 12:42:59AM +0200, J?r?my Bobbio wrote:
> On Tue, Jul 29, 2008 at 11:47:59AM -0600, dann frazier wrote:
> > When doing an LVM+crypto install, I am presented with a "Erasing data"
> > screen with a Cancel button. It doesn't seem to be possible to use the cancel
> > button - it is not highlighted, and pressing tab doesn't cause it to be.
> Are you using the newt frontend?  In that case, could you try with the
> GTK+ frontend?
> I have tried with both the newt and GTK+ frontend and the Cancel button
> was usuable in both cases.

hey Jeremy!

I tried both - in the GTK+ frontend I am able to click cancel, but it
doesn't seem to have any affect.

> What size is the partition being erased?


> After having a look at the source code, it's possible that, for a very
> large partition, the progress would be updated rarely enough to give you
> the impression that the Cancel button do not work, as its result would
> not be checked often enough.

That sounds plausible, and after adding some debug statments, I
believe that your theory is correct. A kill does occur after the next
iteration of the while loop after I click cancel. There's just a long
time between iterations.

But, I think the confusion might be the return value. At the end of
crypto_do_wipe is this code:

 	wait $pid
	[ $cancelled -eq 1 ] && ret=0
 	return $ret

Which causes the function to return 0 if the user cancelled the

Consider that a user might click cancel with no immediate result, then
a minute or two later they are moved along to the next step (creating
a password for the volume). They maybe led to believe that the wipe
completed successfully, even though their cancel attempt did
eventually succeed and cause the rest of the disk to not be cleared.

> A possible fix in that case would be to divide the progress into more
> steps than the current 100.  But a deeper investigation would be
> required before that.

I wonder if there's a way to split the cancel checking and the
progress checking? I'm still pretty green w/ d-i syntax, but it
appears that we know of a cancellation when db_progress returns 30 -
would it be possible/reasonable to do something like:

crypto_do_wipe() {  

  [existing code that starts up blockdev-wipe]

  ## fork a subshell to monitor for user cancels
  { while :; do
      sleep 1
      db_progress <some no-op args>
      if [ $? -eq 30 ]; then
      	 kill $pid
         echo somestring-to-advance-progress > $fifo
  } &

  [existing while loop that reads fifo]
  kill $watcherpid


dann frazier

Reply to: