ubiquity resizes partition even when not asked to.

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/1218702

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

This sounds like the same bug as bug 1164783.

@psusi in general it is customary to mark the newer bug as a dup of the older bug, not the other way around.

In this case, the newer bug was better documented.

comment copied from "dup" bug 1164783

The only proper way to decide if a resize is needed is to compare the original value that was placed into the Change dialog, to the value that was returned from the dialog. This comparision must be preformed on the numeric value so as to avoid getting confused by leading zeros and space characters etc. Only if the values are different should the resize action be invoked.

Furthermore it may make sense to limit it to some minmum threshold, does it really make sense to resize a partition by less than N megs? Anything less than 100 megs is probably a mistake.

i have a problem related to this bug too.. most likely

after the ubuntu partition > i have an extended partition which contains two logical partitions..
each logical partition has an 2048 free space in front of it....

ubuntu not only that resizes the partition in which it must install... but its moving the begining of the extended partition by 2046 to the right... (maybe he doesnt read the extended partition right, ...)..
i dont think this is a good ideea and i have to manually repair that after ubuntu instalation...
baybe i m not clear enought, i could upload some pictures if its needed...

something like:

2048 | sda1 | sda2 - swap | sda3 - ext4 | sda4 - extended |

extended looks like:

2048 | sda1 | sda2 - swap | sda3 - ext4 | 2048free| sda5-logical | 2048free| sda6-logical |

so it pushes sda3 to the right over extended sda 4 --- and sda 4 2046 to the right...

ty

This is specially annoying when you're installing from an ISO file that is located in another partition of the same hard disk (using the "loopback" facility of GRUB). The installer needs to umount that partition, but it can't because it's in use, obviously. If the installer didn't resize at all, one could prevent this problem.

saucy has seen the end of its life and is no longer receiving any updates. Marking the saucy task for this ticket as "Won't Fix".

but this happens in 14.04, 14.04.01 LTS also...
it s really annoying to have to repair the partition after ubuntu installation..

it pushes the end of the partition to the right over an extended partition and resize it.. this is not normal behavior..

Is that bug can be fixed before the Ubuntu 15.10 release please ?
It's been annoying for, at least, the last 2 years.

The next version is a LTS and this bug need to be fixed.
Thank you.

Hello, just a little reminder that this bug need to be fixed ;)

That really need to be fixed for the next LTS.
Thanks

Again please fix this old bug...

Again, please, fix this old bug it's a LTS after all !

Hello Mathieu,

Did you find the problem ?

And thank you for taking care of this !

Still here in Zesty (surprise!)

Experiencing this bug in Artful Ardvark 17.10.

I didn't experienced this bug on 17.10 but it didn't seem to be fixed as said in comment #22...
18.04 is coming...

I encountered this bug installing 18.04.

I was able to work around the bug by:
dd if=/dev/zero of=/dev/sdXN

(... where /dev/sdXN is the appropriate device on my system.)

I used two partitions: one for / (root), and the other for /boot

It was the /boot partition that Ubiquity would resize.
Ubiquity would shrink it from 500 MiB to slightly less, perhaps around 499.7 MiB.

It may be that Ubiquity is shrinking from 500MiB to 524MB. Ubiquity may display and analyze partitions in MB (base 10), not MiB (base 2).

It is interesting that:

1) the shrink only seems to happen if the partition is formatted prior to Ubiquity running.

In other words:

2) I believe the (unwanted) shrink dose not happen if the partition is filled with zeros. (Actually, it is possible that only the beginning of the partition needs to be zeroed.)