ubiquity does not always provide auto-resize option

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.

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

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.

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

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1663298

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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?

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.

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

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1664440

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.

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