ubiquity does not always provide auto-resize option

Bug #1663298 reported by Colin Ian King on 2017-02-09
This bug affects 3 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)

Bug Description

[[[[[[ READ ME FIRST ]]]]]]

At time of writing, ubiquity will not tell you why it doesn't offer certain options. It just does.

The most likely causes for this symptom:
 1. you do not have enough space on the target disk for the install.
 2. your existing install is encrypted LVM, which ubiquity currently can't handle.

If you have checked that you are not experiencing these particular conditions, please consult getting debug information from ubiquity first:


[Original Bug Report]
Tried to install Xubuntu 16.04.2 i386 following the testcase (Install (auto-resize) in Xubuntu Desktop i386 in Xenial Daily)


There was no "Install Xubuntu XX.XX alongside SYSTEM YY.YY" option at all. This also fails on Xubuntu Desktop amd64 too.

Test machines:
  1. KVM/QEMU, 4 procs, 20GB virtual HDD
  2. Lenovo X220, 250GB HDD

I tried this against 2 previously installed images (clean install and OEM install xubuntu 16.04.2).

Robert Hooker (sarvatt) wrote :

This also affects the lubuntu image at http://iso.qa.ubuntu.com/qatracker/milestones/372/builds/142584/testcases/1301/results in KVM against a clean install. The only options are to erase and reinstall.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Stefan Bader (smb) wrote :

Same here with MATE desktop 16.04.2 (amd64). There was a "alongside" option when I doubled the virtual disk (so it had real unused space). But that does not feel like what one would expect from an auto-resize.

Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:

tags: added: iso-testing
Stefan Bader (smb) wrote :

Ok, looks like this is only not working with (KVM) VMs. Repeated this on a bare metal machine and I get a resize dialog.

Seeing the same for Kubuntu. On bare metal, I'd performed the "Install (entire disk with lvm and encryption) in Kubuntu Desktop amd64" (http://iso.qa.ubuntu.com/qatracker/milestones/372/builds/142600/testcases/1451/results) which passed, but I then followed up performing the "Install (auto-resize) in Kubuntu Desktop amd64" (http://iso.qa.ubuntu.com/qatracker/milestones/372/builds/142600/testcases/1301/results) . I'm also not seeing the "Install Kubuntu XX.XX alongside SYSTEM YY" option, only seeing the "Guided - use entire disk..." options.

Kev Bowring (flocculant) wrote :

Using a 20Gb vm I have:

Upgraded 14.04 to 16.04 rebooted - got the option to resize - took that, allowed the minimum.

Rebooted again to clean install and then got the option to install alongside a second time (screenshot)

Clean install - got option to resize.

Not seeing this on Xubuntu.

Ftr - vm is set to use 2048Mb Ram - consequently installer is creating a swp partion of the same size, so effectively managing to see the option to install 3 xubuntu's on 18Gb.

Kev Bowring (flocculant) wrote :

If I had follewed through with the 3 installs I would have seen the 'partition too small warning'

Colin Ian King (colin-king) wrote :

With 12.04 already installed, I get the uto-resize installation option. With 16.04 already installed, I don't. Running on a VM with 20GB disk, 4GB RAM.

Colin Ian King (colin-king) wrote :

This seems related to the size of the already installed swap partition and memory at time of the new install. For example, I had 16.04 originally installed on a VM machine with 12GB, then I bumped it to 13GB and the option is not available. If I drop the VM size down to say 8B, the option appeared on the next try.

Adam Conrad (adconrad) wrote :

I'm fairly sure it's a feature, not a bug, that if we don't have enough free space we don't offer installation options that would fail.

Walter Lapchynski (wxl) wrote :

Admittedly, Adam, based on #10, the issue appears to occur when the virtual disk is increased, which does not seem to be consistent with the conditions of your assertion.

Walter Lapchynski (wxl) wrote :

I will say I find a lot of conflicting information in the comments. Looking at the tracker, it seems that it is not consistently reported by all testers. I also noticed flocculant tested not only Xubuntu but Lubuntu with success. I notice that it has been reported against i386 and amd64 but not across all flavors.

tl;dr, without a very clear testcase, this bug is likely to be difficult to reproduce. I realize the tracker testcases themselves describe a process, but perhaps there's some ambiguity that is resulting in different results. That said, please revise the description with steps to reproduce.

Walter Lapchynski (wxl) wrote :

For VMs, too, it would be valuable to have more explicit details on what's being used. What's the host OS, hypervisor type/version, virtual disk type/size, memory, CPU, etc.

Walter Lapchynski (wxl) wrote :

I think because of the above, I'm marking this as incomplete.

Changed in ubiquity (Ubuntu):
status: Confirmed → Incomplete
Walter Lapchynski (wxl) wrote :

I cannot confirm this, at least for the following conditions:

Host: Lubuntu 16.04.1, 4.4.0-53-generic kernel
Hypervisor: VirtualBox 5.1.14-112924~Ubuntu~xenial
VM: 32-bit, 20GB disk (fixed or dynamic), 2GB RAM
Installation media: Kubuntu 16.04.2 i386
Initial install: standard entire disk

Walter Lapchynski (wxl) wrote :

Another user attempted to install on real hardware given the following partition map:

Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 73EB9828-4715-4D2C-B6E0-ED0B07CE0C22

Device Start End Sectors Size Type
/dev/sda1 2048 206847 204800 100M EFI System
/dev/sda2 206848 239615 32768 16M Microsoft reserved
/dev/sda3 239616 243537919 243298304 116G Microsoft basic data
/dev/sda4 484710400 488396799 3686400 1.8G Windows recovery environment
/dev/sda6 243537920 468117503 224579584 107.1G Linux filesystem
/dev/sda7 468117504 484710399 16592896 7.9G Linux swap

/dev/sda6 contains a standard Kubuntu install. It is not encrypted
To be more clear about available space:

Filesystem 1K-blocks Used Available Use% Mounted on
udev 4021440 0 4021440 0% /dev
tmpfs 808336 9668 798668 2% /run
/dev/sda6 110396248 6704732 98060648 7% /
tmpfs 4041680 28304 4013376 1% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 4041680 0 4041680 0% /sys/fs/cgroup
/dev/sda1 98304 24253 74051 25% /boot/efi
tmpfs 808336 12 808324 1% /run/user/1000

Despite all that available space, he was not given the resize option.

Just to remove variables, I confirmed that LVM was not used and none of the Linux partitions are encrypted.

There is a GPT partition, so maybe that's the issue?

To further help figure this out, the output from running `ubiquity --debug` is attached. It seems the resize option is removed, though I'm not clear from the log how that conclusion was arrived at.

Walter Lapchynski (wxl) wrote :

I assume it is expected that ubiquity cannot resize encrypted LVM, right? I certainly can't get that to work and that seems to be the issue with #6.

Walter Lapchynski (wxl) wrote :

Confirmed with #ubuntu-installer that encrypted LVM will not offer the auto-resize option. So that's out. I know that affect at least one commenter. What about the OP?

Walter Lapchynski (wxl) wrote :

To eliminate the possibility that ubiquity won't offer to resize if there is more than one installation on there, I drummed up a virtual machine with *3* installs on it, and ran the installer and was still given the option. So at least 4 are supported.

summary: - Xubuntu 16.04.2 has no auto-resize installation option
+ ubiquity does not always provide auto-resize option
Walter Lapchynski (wxl) on 2017-02-13
description: updated
Walter Lapchynski (wxl) wrote :

Moved discussion about #17 to a new bug report with a proper apport collect:


Walter Lapchynski (wxl) wrote :

Just wanted to also emphasize the fact that even though I tested against VirtualBox, even though it's not clear from the text, flocculant did test with KVM/QEMU, so I'm disinclined to believe that to be the issue.

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  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers