Bug#492899: partman-crypto: cancel button unusable on Erasing data screen
On Tue, Jul 29, 2008 at 06:03:34PM -0600, dann frazier wrote: What size is the partition being erased? ~73G blockdev-wipe writes random data in blocks of 65536 bytes. So we have (70 * 2^30) / 2^16 = 70 * 2^14 blocks to write. With the progress bar divided into 100 steps, this means that we have one update every 11468 written blocks. Does not really sound reactive to me! :) 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. […] 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. Let's make it more reactive then and leave the current code as is, IMHO. 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? […] It might be, but I am not inclined to do this kind of changes that tend to breaks in very subtle way just before Lenny. Dividing the progress bar in 65536 parts will give us an abitility to cancel it every 1114112 written bytes, and should make it reactive enough. Cheers, -- Jérémy Bobbio.''`. [EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#492899: partman-crypto: cancel button unusable on Erasing data screen
On Wed, Jul 30, 2008 at 11:58:38AM +0200, J?r?my Bobbio wrote: On Tue, Jul 29, 2008 at 06:03:34PM -0600, dann frazier wrote: I wonder if there's a way to split the cancel checking and the progress checking? [???] It might be, but I am not inclined to do this kind of changes that tend to breaks in very subtle way just before Lenny. makes sense Dividing the progress bar in 65536 parts will give us an abitility to cancel it every 1114112 written bytes, and should make it reactive enough. Another option might be to make it dynamic, based on the size of the disk - I assume we'd need to add a parameter to the wipe utility to negotiate this in advance. That too might be something better suited for post-lenny exploration. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492899: partman-crypto: cancel button unusable on Erasing data screen
Package: partman-crypto Version: 33 Severity: normal 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. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: ia64 Kernel: Linux 2.6.25-2-mckinley (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492899: partman-crypto: cancel button unusable on Erasing data screen
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. 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. 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. Cheers, -- Jérémy Bobbio.''`. [EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
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?
~73G
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
ret=$?
[ $cancelled -eq 1 ] ret=0
return $ret
}
Which causes the function to return 0 if the user cancelled the
process.
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
fi
}
watcherpid=$!
[existing while loop that reads fifo]
kill $watcherpid
[...]
}
--
dann frazier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
