Editing partitions is slow

Bug #89357 reported by Trouilliez vincent
84
This bug affects 5 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Expired
Medium
Unassigned

Bug Description

Binary package hint: ubiquity

I am testing Herd5, though the issue is not new...

Probably because I have 9 partitions to look after, and probably because I use Ubiquity a lot ;-) to test the advanced partitioner mostly, I get more and more annoyed at the slowness of the partitioner. That is, for each and every partition, no matter what I do on it (disable it, or select a mount point, or format it), it takes a little while to complete the operation, and also pops up a "Scanning disks" progress bar".
I can understand that it needs to scan the hard drives when launching the partitioner, obviously, but why does it need to scan them 20 times ? If I select a mount point or tick the "format" check box, why does it need to scan the disks all the time ?
It's particularly annoying, considering that the text installer, which I thought now was the new base of the graphical installer, IS NOT slow, nor does it pop up any progress bat or anything.

Here is hoping you can do some magic in time for the final release ! ;o)

Revision history for this message
Colin Watson (cjwatson) wrote :

Yeah, it's due to the way we drive the underlying partitioning code, which I haven't yet optimised. I hope to get some time to do this before Feisty releases. Basically, it's slow because in order to figure out what to display on the partition list screen we need to navigate through many different screens of the underlying text installer.

Changed in ubiquity:
importance: Undecided → Medium
status: Unconfirmed → Confirmed
Revision history for this message
Mikel Ward (mikelward) wrote :

I assume this is the one I just saw when trying to install Intrepid RC.

It was painfully slow.

Each time I deleted a partition or added a partition, I had to wait about 30 seconds while it re-scanned the partitions.

I have two SATA drives with simple layouts (sda = SCSI 1: sda1 = 80 GB ntfs, sda2 = 78 GB ext3, sda3 = 2 GB swap; sdb = SCSI 3: sdb1 = 500 GB+ ntfs).

Why on earth does it take this long?

Revision history for this message
LimCore (limcore) wrote :

Still true for 9.04.

Revision history for this message
Evan (ev) wrote :

Bug 394575 is related.

Revision history for this message
Francisco T. (leviatan1) wrote :

Before it was slow, but in karmic was very very slow.
15 minutes to setup 5 partitions!!

I installed kubuntu, with the new intaller, Could this be the problem?

Revision history for this message
Jarl (jarl-dk) wrote :

These bugs are potential duplicates: bug 89357, bug 164030, bug 282193, bug 341095, bug 288450, bug 480957

Revision history for this message
LimCore (limcore) wrote :

This retarded installer is annoying milions of users world wide ;) Please fix this seriously.. Still true for 9.10

Revision history for this message
Hein van Rensburg (hvralpha) wrote :

And now for Lucid 10.4 RC. The installer only detects one of my 4 processors on my fast intel system and took ages to install.
This must be something to do with which kernel it loads using a single processor version.

Revision history for this message
Evan (ev) wrote :

LimCore,

Please refer to the code of conduct (http://www.ubuntu.com/community/conduct) before making any further comments.

Revision history for this message
Evan (ev) wrote :

Hein,

All of our kernels support SMP. If you think the kernel is not using all of your processors, please run `ubuntu-bug linux`.

Please do not post new bugs as comments in existing bugs.

Revision history for this message
Jarl (jarl-dk) wrote :

This has improved a lot in Lucid.

Still I find it a bit slow. But not much slower than the rest of the installer-wizard. Which in general I find a bit slow. So to me I think this bug (regarding editing partitions only) is solved.

What do the rest of you think?

Revision history for this message
Alex Engelmann (alex-engelmann) wrote :

I think editing partitions is an intrinsically slow process, but Ubiquity's partition manager is about as fast as GParted or faster, so I think this bug is solved. I'm using Natty.

Changed in ubiquity (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Trouilliez vincent (vincent-trouilliez-modulonet) wrote :

Oh dear...

Revision history for this message
Bob/Paul (ubuntu-launchpad-bobpaul) wrote :

It still refreshes the partition table after every change, which seems unnecessary. In GParted I can setup 15 partitions one after another without delay, the click apply and let it do it's thing. In Ubiquity I make 1 partition, wait, make another partition, wait, and still nothing is actually written to the disk until I click next, when I have to wait yet again.

In the past, partitioning with Ubiquity was absolutely painful. Now it doesn't seem painful, but I do still have to wait needlessly between steps; my hardware is just 3+ years newer.

What's been fixed exactly? That I have a Core2 Quad instead of an Athlon XP? That sounds like a workaround.

Revision history for this message
Trouilliez vincent (vincent-trouilliez-modulonet) wrote :

There is obviously a problem since, if you read my original report and the first comment on it:

A) The TEXT/alternative installer has NO sluggishness whatsoever.

B) Colin Watson himself, who wrote the ubiquity partitioner, acknowledged that it was slow and explained why.

So please don't pretend that it's "fixed".. nothing is fixed, despite the numerous years that have elapsed. It would more honest to just say "we can't be bothered to make it just work like it should, let's close this bug report". At least I would understand that...

Changed in ubiquity (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Vladimir Rutsky (rutsky-vladimir) wrote :

I experience similar behaviour during installation of Ubuntu 13.10 (and previously I experienced it during installation of Ubuntu 11.10).

Revision history for this message
Marcus Tomlinson (marcustomlinson) wrote :

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

Changed in ubiquity (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for ubiquity (Ubuntu) because there has been no activity for 60 days.]

Changed in ubiquity (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.