resized partition size doesn't count swap space size.

apport information

apport information

apport information

apport information

apport information

apport information

Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here.

I can confirm this issue using the Xubuntu Desktop image dated 20110422.1 . This results in the user being unable to install to the partition, and the must manually resize the partition to complete the installation.

Thanks for taking the time to make Ubuntu better!

Since it's not just a KDE front end issue, making it RC at least for release team review.

Confirmed with ubiquity 2.6.10, this is not a problem with Ubiquity but with partman and it is reproducible with the debian-installer.

Actually, the partition is correctly resized to the size indicated by the slider but it creates 2 partitions in this space, a root partition and a swap partition. So in the case where you resize to 2.7GB, the allocated space to the root partition is 2.7 - swapsize (e.g 1GB) leaving only 1.7GB for the root partition.

It's the same problem with the text installer, if the user selects 'resize' and resizes the partition to the maximum value proposed, then the partition is correctly resized but it also creates a swap partition in the free space. The installer doesn't stop immediately after the partitioning but further in the installation process when files are being installed and stops with a 'No space left on device'

On a side note, when a system is installed more than on time and the user chooses to overwrite the Ubuntu partition (e.g Windows installed alongside with Ubuntu, and reinstalling Ubuntu) a new swap partition is created each time ending up with as many swap partition as times the system has been reinstalled.

I'm moving to partman-auto

That or the minimum Ubiquity should allow is minimum install space plus planned swap space.

> Actually, the partition is correctly resized to the size indicated by the
> slider but it creates 2 partitions in this space, a root partition and a
> swap partition. So in the case where you resize to 2.7GB, the allocated
> space to the root partition is 2.7 - swapsize (e.g 1GB) leaving only 1.7GB
> for the root partition.

I'd prefer that we fix this by moving to swap files. Doing so will offer no
additional space, but will more clearly line up with the user's expectations
of the size of the partition.

> It's the same problem with the text installer, if the user selects 'resize'
> and resizes the partition to the maximum value proposed, then the partition
> is correctly resized but it also creates a swap partition in the free space.
> The installer doesn't stop immediately after the partitioning but further in
> the installation process when files are being installed and stops with a 'No
> space left on device'

I don't think this is the same problem. Ubiquity has logic in it to check
that the requested partition size is greater than a multiple of the size of
the read-only copy of the squashfs. This is the figure that's presented on
the "Prepare to install Ubuntu" page.

debian-installer, lacks the ability to have similar functionality due to its
flexibility and construction. It is close to impossible to determine the
minimum size needed for the installation in this environment. If you resize a
partition too small and try to install onto it, then sorry, but don't do that.

> On a side note, when a system is installed more than on time and the user
> chooses to overwrite the Ubuntu partition (e.g Windows installed alongside
> with Ubuntu, and reinstalling Ubuntu) a new swap partition is created each
> time ending up with as many swap partition as times the system has been
> reinstalled.

This should not happen if you choose the "Upgrade/Reinstall Ubuntu" or "Erase
Ubuntu and reinstall" options in ubiquity. These options are made to reuse
the existing swap partition. Please file a separate bug if this not the case.

It's too late in the cycle to move to swap files for oneiric, and that wouldn't help for natty-updates anyway (which also has a bug target here). Evan, can we do something here to make sure users don't get this "insufficient space" error after already repartitioning?

Yes. We can get the minimum swap size from the partman recipe and factor it into the bounds for the resize slider as well as our consideration of presenting the resize option.

I've started on a patch to this effect and hope to have something done by the end of Monday.

ubiquity (2.8.4) oneiric; urgency=low

  [ Evan Dandrea ]
  * Handle the keyboard query window closed callback being fired twice
    (LP: #865493).
  * Allow focusing of labels when we're in the screen reader
    acessibility profile, so that Orca can read them
    (LP: #856782, LP: #856773).
  * Make sure we account for the size of the installation and swap
    partition when calculating the bounds for the partition resizer
    (LP: #769350).

  [ Colin Watson ]
  * Don't install duplicate copies of console-setup-apply,
    localechooser-apply, and netcfg-wrapper.
  * Bump fallback Ubuntu version number in ubi-language to 11.10.
  * Update translations from Launchpad.
  * For cases where selecting a different location may imply a different
    dialect of the language, i.e. Portuguese and Chinese, take care to set
    LANG to something reflecting the location and
    LANGUAGE/LC_MESSAGES/LC_CTYPE/LC_COLLATE to something reflecting the
    language (LP: #590108). This roughly matches the behaviour of
    language-selector.
  * Automatic update of included source packages: localechooser 2.37ubuntu2,
    partman-partitioning 81ubuntu3.

  [ Stéphane Graber ]
  * Update ubiquity-dm to export self.username as SUDO_USER.
    Make gsettings work properly later on during the install.
  * Whenever we call wget, set --tries=1 instead of the default
    of 20.
  * If we think we're offline, don't try to contact geoip or run
    rdate. (LP: #868668)
 -- Colin Watson <email address hidden> Thu, 06 Oct 2011 02:20:53 +0100