add installer status message for "Wiping Swap Space"

Is /dev/sda1 your swap partition? Can you please attach /var/log/installer/syslog and /var/log/installer/partman to this bug report?

Thanks!

sry typo, it should be sda2 (root) and sda4 (swap)

I had the same problem: 82% installation stopped for long time.

Message: "creating user"

I installed karmic alpha 6 in the asus 1101ha with crypt in /home and ext4 system to / and /home and used swap-area to /swap

I booted by pendrive in my eeepc

After long time my installation concluded.

I think this dd command should erase all data on / or accordingly /home to prevent any possible unintentional data recovery of stuff that were on the machine before encrypting first.

the command is not the problem. Security first.
But there is NO visual FEEDBACK of the installation progress, which is alienating.

The installer is writing over any swap partitions to be used by Ubuntu with zeros, to prevent leaking of data that could enter swap before the encrypted swap was set up. The solution, as mentioned, is to provide a progress message for this operation.

I have also noticed this behaviour and it's rather perplexing. First of all (as others have noted) there isn't any feedback at all that this operation might take a long time (I personally expected "Creating user" to be a rather quick operation). Second: why *does* it take so long? Even with a big swap partition it should not take 15 minutes to zero it out. Might providing a bigger block-size to the dd command increase the speed? As this is time the user usually spends waiting before being able to use his new and shiny Ubuntu installation it is a really bad first impression.

Still present in 8.10 Karmic Koala beta netbook-remix.

Related discussion:

http://ubuntuforums.org/showthread.php?p=7975573#post7975573

This might make the user to quit the installer so I think it's quite a showstopper. Should this be nominated for a release blocker?

Ubuntu Karmic 9.10 alternate cd installer hangs with home partition encrypted at 26% setting up users and passwords stage

I am using:
encrypted disk partition with LVM

tried several times with private home partition and install constantly hangs

Worked flawlesly after I disabled the private home partition

I'm having the same issue here. Stucked at 26% for almost an hour. Tested with beta and October 14th daily build of karmic 9.10 AMD64 alternate.

If you drop to tty4 with ctrl-alt-F4, what do you see there?

:-Dustin

I edited /usr/lib/ubiquity/user-setup/user-setup-apply in the karmic beta UNR liveCD, while Ubiquity was running (still copying files). I changed:

  dd if=/dev/zero of=$device 2>/dev/null || true

to

  dd bs=16m if=/dev/zero of=$device 2>/dev/null || true

The original command was reading 512 bytes of zeroes, writing 512 bytes of zeroes to the disk, and looping. Very slow -- one sector at a time. Adding "bs=16m" means that each write zeroes 16 megabytes of disk. It's about 1000x as fast. Totally eliminates the problem. If you're concerned that in small-memory machines there isn't enough RAM to briefly allocate 16MB for this, change it to 8MB or 4MB, it'll be almost as fast.

With this fix, I saw no perceptible problem with the speed of ubiquity installing around 80%, despite having a swap area of 5GB.

Dustin,

I don't remember what tty4 was showing at time, but I do remember that I called "ps" and I saw this process:

"dd if=/dev/zero of=/dev/sda5"

sda5 is the swap partition created with automated partition, using the whole disk. It's a 250GB disk, and I have 4GB of RAM on this machine, so swap was automatically created with aprox. 10GB.

I think John's comment (https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/432422/comments/13) could explain why this step takes so much time on my machine.

I have the same thing with the Karmic final.

Ubuntu Karmic 9.10 alternate cd installer hangs with home partition encrypted at 26% setting up users and passwords stage-

I am using:
encrypted home partition.

Hi Ali,

I haven't tested 9.10 final yet, but RC had the same issue. In fact, the installer is not really "hanged" - after 80 (!) minutes, the installation was finished.

The problem here is that installer displays no feedback to user about what's going on. Annoying, yes, but after some (big) time installation is successfully finished.

Marking wishlist, triaged, assigning to Evan (for now, feel free to update, Evan).

Also, updating bug title.

The installer should note in the status bar what's going on here...that it's cleaning out the swap space due to the encrypted-swap setup. Quibble over the text, but I think the best way of solving this is making it clearer what's actually going on.

Evan-

Any chance we could get something into Lucid's d-i and ubiquity that prints a message about "Wiping swap space for security...this may take several minutes..." ?

Absolutely. I'll work on that once we're in FF next month.

This bug was fixed in the package user-setup - 1.28ubuntu5

---------------
user-setup (1.28ubuntu5) lucid; urgency=low

  * Provide a progress message for wiping swap space (LP: #432422).
 -- Evan Dandrea <email address hidden> Fri, 05 Mar 2010 11:51:32 +0000

/me high fives Evan!

Wiping Swap space for security (this may take a while)... This is a understatement. Two hours later I am still waiting. Even at 512k at a time it shouldn't take this long. I have 250g so that would be a 5g or 10g swap. It should only take an hour at the most. I'm going to let it set and see if it is acually working or if it is indeed hung up. Doing encrypted LVM with encrypted home. It is currently stuck at 22%. I will post an update later today.

I should add that I am also setting it up as a ltsp-standalone server.

lol. Okay it just finished at just under 2 hours. This is something that still needs to be addressed cause most people won't wait that long.

If you want to want to encrypt your system, and you actually want to
protect your keys, then your swap space must be wiped. Or, you need
to run with no swap space.

OK, so now we have a message, that's progress, but it still hangs for minutes after printing the message. How about fixing the underlying bug, which is that a shell script is doing *512-byte* writes from /dev/zero to the swap partition using dd! See comment #13 above. Making it run 1000x as fast, with full security, is *trivial* - just add a bs=16m parameter - but nobody's done it in the year since that comment.

Thanks, John.

Looks like Evan did inadvertently miss this part of the fix. Our apologies. No one has really monitored this bug since it was marked "fix-released".

In the future, when you see an obvious bug with an equally obvious fix, I recommend doing two simple things:
 1) file a NEW bug against the package (adding information to an old bug is always a bad idea), and attach a patch (this marks the bug in a special way)
 2) poke a developer in #ubuntu-devel in IRC

If you do those two things, I bet you'd get your fix committed within a day or two. Perhaps within the hour, as I'm uploading the change now.

:-Dustin

This bug was fixed in the package user-setup - 1.28ubuntu8

---------------
user-setup (1.28ubuntu8) maverick; urgency=low

  * user-setup-apply.py: when wiping the swap space, use a large (16M)
    block size rather than the default (512-byte), to speed up the slow-but-
    necessary operation, LP: #432422
 -- Dustin Kirkland <email address hidden> Tue, 24 Aug 2010 14:25:33 -0400