partman doesn't cache ntfsresize data

[John McCabe-Dansted]

Binary package hint: ubiquity

I was running Ubiquity from an already installed UNR9.04 drive (/dev/sdb) under VirtualBox (32bit client, 64bit host), and attempting to install onto /dev/sda. Once I had selected my keyboard type, my harddisks went crazy. I noticed that ntfsresize was running. This leads me to believe that Ubiquity started ntfsresize without any warning or permission.

As shown by the attached screenshot, ntfsresize started running when I was still on the "Keyboard Layout" screen. Also as shown the forward and back buttons are greyed out, so Ubiquity seems to be waiting for ntfsresize to finish whatever it is doing.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: ubiquity 1.12.12 [modified: lib/partman/automatically_partition/question]
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_AU.UTF-8
SourcePackage: ubiquity
Tags: ubuntu-unr
Uname: Linux 2.6.28-13-generic i686

[John McCabe-Dansted (gmatht)]

OK, after more than an hour of CPU time, ntfsresize appeared to finish. It doesn't appear to have done anything as /dev/sda is still one big NTFS partition. Now ntfsresize has started again, while "Scanning disks", as shown by Screenshot-1.png.

[John McCabe-Dansted (gmatht)]

I think it is running ntfsresize to query ntfsresize as to by how much space ntfsresize can shrink the partition by, rather than actually resizing the partition. This is reasonable, however it would be nice for Ubiquity to give some notification as to why it is sitting there churning the harddisk for over an hour.

[John McCabe-Dansted (gmatht)]

It would also be nice if it was cached so that we didn't have to do it twice per install.

[Paul Larson (pwlars)]

It appears that this bug is not specific to Ubuntu Netbook Remix, so the ubuntu-unr tag has been removed. If something changes, and you later believe that this bug only happens on UNR, please add the ubuntu-unr tag again.

If you were running under virtualbox, especially on a slower machine, or under limited vm resources, it could explain why it took so long. But if I'm understanding correctly, it sounds like probably non of the disks the installer could see even had ntfs on them, is that correct?

Please see if you see this same behavior with the current release in testing (karmic) and post back here.

[John McCabe-Dansted (gmatht)]

I was installing onto a 500GB device that was ntfs formatted, and had 120GB of free space. As it turns out ntfsresize couldn't create 30MB of unpartitioned space. Ntfsresize was also very slow outside of the VM.

As I understand, Ubiquity would run ntfsresize four times, if I were to resize the partition
1) Just after selected the keyboard layout.
2) When starting the manual partitioner.
3) Just before resizing the ntfs partition, to check that it will actually work.
4) Calling ntfsresize to actually resize the partition.

If ntfsresize is meant to be this slow on a large drive, then I would suggest removing 1+2, and just rely on df to give the user a clue as to how much space they can free up. To keep the windows drive usable you probably won't want to remove all free-space anyway, and ntfsresize isn't always reliable in its estimates as to how much space it can free up anyway. However other partitioners also behave in a similar way, e.g. gparted runs ntfsresize on start if there are unmounted ntfs partitions and partman also runs ntfsresize before it will even let you specify how much space you want to remove.

Even if ntfsresize isn't meant to be that slow, #2 seems redundant, since it could have been cached from #1.

The ntfsresize from
  https://launchpad.net/ubuntu/karmic/amd64/ntfsprogs/2.0.0-1ubuntu2
also takes a longing time to checking for freeable space. (over 5minutes, on the 500GB usb drive on a native Dual Core 2)

[Marcus Tomlinson (marcustomlinson)]

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.

[Launchpad Janitor (janitor)]

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