Step 3 of 6 takes for about an hour

Bug #480957 reported by Dmik
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Binary package hint: ubiquity

When installing Ubuntu 9.10 64-bit (using the desktop install CD), step 3 of 6 (the one that starts with the "Starting partitioner" progress dialog) takes for about an hour here. The "Starting partitioner" dialog runs up to 100% in about 1 min, disappears, and then the (previous) keyboard layout selection page stays visible all the remaining time with the mouse pointer having the "please wait" shape. The hard disk led keeps blinking during this hour. When the process finishes and I select the manual partition configuration, it takes another 10 minutes to show the "Prepare partitions" dialog. As long as I perform manual assignments, the "Scanning disks..." progress dialog periodically appears, sometimes taking another ~10 min each time to complete. I noticed that this 10 min delay always happens when I change the properties (e.g. mount point) of the NTFS partition which is ~123G in size (/dev/sda14, see below) and that changing the properties of other partitions is way faster (less than a minute). When I'm finished with partitions and press Next, the remaining part of the installation process goes flawlessly up to the end.

Note that I also tried to run "gparted /dev/sda" manually from the terminal while booted from the desktop install CD and I must confirm that the gparted start-up also takes about 10 min in this case (it says "scanning /dev/sda..." while starting), so the delay is somehow related to the layout of my hard disk it seems -- the difference is that the installer probably scans the hard disk several times and hence the 5-6 times longer delay. BTW, I looked at the output of gparted and it doesn't print anything interesting to the terminal except the libparted version (so it's definitely not the missing floppy delay I read somewhere about when searching for an explanation).

Here is the output of 'fdisk -l /dev/sda':

Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xfb7cfb7b

   Device Boot Start End Blocks Id System
/dev/sda1 * 1 1 8001 a OS/2 Boot Manager
/dev/sda2 2 524 4200997+ 7 HPFS/NTFS
/dev/sda3 525 1569 8393962+ 17 Hidden HPFS/NTFS
/dev/sda4 1570 30401 231593040 5 Extended
/dev/sda5 * 1570 2614 8393931 7 HPFS/NTFS
/dev/sda6 * 2615 3659 8393931 83 Linux
/dev/sda7 * 3660 3921 2104483+ 82 Linux swap / Solaris
/dev/sda8 * 3922 4183 2104483+ 7 HPFS/NTFS
/dev/sda9 * 4184 4445 2104483+ 82 Linux swap / Solaris
/dev/sda10 * 4446 4968 4200966 7 HPFS/NTFS
/dev/sda11 * 4969 8102 25173823+ 7 HPFS/NTFS
/dev/sda12 * 8103 11236 25173823+ 83 Linux
/dev/sda13 * 11237 14370 25173823+ 7 HPFS/NTFS
/dev/sda14 14371 29355 120366981 7 HPFS/NTFS
/dev/sda15 29356 30401 8401963+ c W95 FAT32 (LBA)

I also attached the /var/log/installer/syslog and /var/log/installer/partman files, as requested. I see a lot of messages related to ntfs and /dev/sda14 in there and it even complains that NTFS is inconsistent but I think it's unrelated because I've just fixed the NTFS partition from Windows and repeated the install attempt -- the same long-long delay in step 3 of 6 (though I didn't wait till the end this time).

PS. Starting gparted from Ubuntu running from the hard disk is much faster BTW -- it takes just half a minute instead of 10.

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

I was also annoyed with this long time spent scanning the disk every time I made a change to just one partition. my disk only had 8 partitions, where 2 of them should be modified to be reused (mounted, but not formated), but it took forever to make even such a small change to the partition editor. Too sad.

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

Could this be a duplicate of bug 282193 ?

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

There are several other bugs that describe the same slowness regarding the partitioner. These bugs are potential duplicates: bug 89357, bug 164030, bug 282193, bug 341095, bug 288450, bug 480957

Changed in ubiquity (Ubuntu):
status: New → Confirmed
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 does the rest of you think?

tags: added: ubiquity-2.0.6
tags: added: karmic
Revision history for this message
Ingo Gerth (igerth) wrote :

What is the current status of this bug? Do you still experience the problem in 12.10 or 13.04?

Revision history for this message
Phillip Susi (psusi) wrote :

It appears that you have several Windows filesystems that are damaged. Please run chkdsk /f on them from Windows and try again.

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.