ubiquity resizes partition even when not asked to.

[Len Ovens]

Choose "Something else" at install options, select a partition change the FS to ext4, select format, set partition to be /. Do not change the size.... size gets changed anyway, ( I lost 8M)

I think what is happening is that ubuiquity reads the partition size and displays it in Mb. It is rounded or truncated to make it fit the display. the user doesn't change it, but the size never was the same as the original partition and so the partition gets resized.

What should happen is that if the given size is the same as before and after no resize should happen. That is ubiquity should compare what the user enters with a recalc for display rather than comparing with the actual size to determine if the size is actually changed.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: ubiquity 2.15.15
ProcVersionSignature: Ubuntu 3.11.0-2.1-lowlatency 3.11.0-rc5
Uname: Linux 3.11.0-2-lowlatency x86_64
ApportVersion: 2.12.1-0ubuntu2
Architecture: amd64
CasperVersion: 1.336
Date: Thu Aug 29 19:34:04 2013
InstallCmdLine: noprompt cdrom-detect/try-usb=true file=/cdrom/preseed/ubuntustudio.seed boot=casper initrd=/casper/initrd.lz quiet splash --
LiveMediaBuild: Ubuntu-Studio 13.10 "Saucy Salamander" - Alpha amd64 (20130829)

MarkForUpload: True
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

[Ubuntu QA Website (ubuntuqa)]

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

[Launchpad Janitor (janitor)]

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

[Brian Murray (brian-murray)]

This sounds like the same bug as bug 1164783.

[codeslinger (codeslinger)]

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

[Phillip Susi (psusi)]

In this case, the newer bug was better documented.

[codeslinger (codeslinger)]

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.

[Etss (heaven-ro)]

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

[negora (negora)]

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.

[Rolf Leggewie (r0lf)]

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".

[Etss (heaven-ro)]

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..

[Waz (paviluf)]

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

[Waz (paviluf)]

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

[Waz (paviluf)]

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

[Waz (paviluf)]

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

[Waz (paviluf)]

Again please fix this old bug...

[Waz (paviluf)]

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

[Waz (paviluf)]

Hello Mathieu,

Did you find the problem ?

And thank you for taking care of this !

[Len Ovens (len-ovenwerks)]

Still here in Zesty (surprise!)

[PJSingh5000 (pjsingh5000)]

Experiencing this bug in Artful Ardvark 17.10.

[Waz (paviluf)]

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...

[mpb (mpb)]

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.)