resize takes a lot of time without user-feedback

Created an attachment (id=3321)
partman log

Created an attachment (id=3322)
syslog

(From update of attachment 3321)
Ignore this. Bugzilla tricked me.

(From update of attachment 3322)
Ignore this. Bugzilla tricked me.

Using the iso of 1/oct/2005 I got the same problem: resizing a partition would
take a long long time with no move on the screen, no progress in the bar
(staying at 0%). The first time I rebooted after 5 minutes waiting without any
change. The second time I just went to do other things and then I realized after
som time (20 minutes?) that actually the process wasn't stalled and the new
partitions had been automatically created.

If only the progress bar had started to move I would have waited more the first
time.

I wonder if the average new Ubuntu user would give it a second try.

(Colin, this is happening with ANOTHER box different as the one that still has
the http://bugzilla.ubuntu.com/show_bug.cgi?id=13250 bug. This one is another
old box with only ext2 partitions in a 40Gb hard drive)

Sorry for the delayed response. What filesystem type were you resizing? (NTFS, perhaps?)

I resized a ext3 partition back then.

Thank you for posting this bug.

Does this issue occur in Lucid?

@ rusivil,

I filed the duplicate #571802 not knowing that this was a long standing issue. Quoting:

"This is one of those minor "cosmetic" bugs that I'm almost reluctant to report, but here goes. Using the iso-testing build of 04/29 and performing an "auto-resize" when I begin the actual resizing (step 4 of 7) and the "progress gui" pops up it almost immediately goes to 50% and it then remains there until the resizing is complete."

"However the resizing does complete successfully in the expected amount of time (5 to 10 minutes). During this the gui does also indicate "please wait" so I would think this is very minor, although I can imagine someone assuming that the partitioner is "frozen" if they get impatient. I would however think "please wait" means please wait"

IMO the length of time it takes for the resize operation is "normal" in comparison with using Gparted from a Live CD.

Since 10.10 is getting a whole new ubiquity I think it would be reasonable to mark this "won't fix", but that's only my opinion.

Nothing has been done about this bug. It should stay open; nobody should ask for repeated reconfirmation from users; and it shouldn't be marked Won't Fix, because it is a real bug that should be fixed at some point (it's just not easy).

@ Colin,

I apologize if I made incorrect assumptions.

Please look at bug 659106 and related bugs:

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/659106/comments/6

We're well past my opinion and absolutely into destructive behavior regarding the new ubiquity.

I just had this issue as well. I'm a Sysadmin/dev by trade and this bug puzzled even me. Lucky for Google where I found other users complaining of this and they just waited it out. Please fix. Joe Blow shouldn't have to get stuck on something like this if Ubuntu is supposed to be as simple as advertised. I can see someone rebooting after they've already screwed their partition tables...

in my case I wanted to setup ubuntu 10.04 on a 7 year old pc with a 7 year old pata 80gb wd blank hdd, which was previously ntfs formated. the drive had only 1 partition, went to change its size plus turn it to swap. since I clicked ok to begin, about 30 minutes or more have passed and it is still at 61%. I believe its an operation that should complete very very fast. I though of posting this here while it is doing it next to me.