ubiquity resizes partition even when not asked to.

Bug #1218702 reported by Len Ovens
This bug affects 20 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Won't Fix

Bug Description

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)

Revision history for this message
Len Ovens (len-ovenwerks) wrote :
Revision history for this message
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
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Revision history for this message
Brian Murray (brian-murray) wrote :

This sounds like the same bug as bug 1164783.

Changed in ubiquity (Ubuntu):
importance: Undecided → High
Phillip Susi (psusi)
Changed in ubiquity (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
codeslinger (codeslinger) wrote :

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

Revision history for this message
Phillip Susi (psusi) wrote :

In this case, the newer bug was better documented.

Revision history for this message
codeslinger (codeslinger) wrote :

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.

Revision history for this message
Etss (heaven-ro) wrote :

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


Etss (heaven-ro)
description: updated
description: updated
Revision history for this message
negora (negora) wrote :

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.

Revision history for this message
Rolf Leggewie (r0lf) wrote :

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

Changed in ubiquity (Ubuntu Saucy):
status: Confirmed → Won't Fix
Revision history for this message
Etss (heaven-ro) wrote :

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)
tags: added: wily
Revision history for this message
Waz (paviluf) wrote :

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

tags: added: rls-x-incoming
Waz (paviluf)
tags: added: ubiquity xenial
removed: amd64 saucy ubiquity-2.15.15 ubuntustudio wily
Revision history for this message
Waz (paviluf) wrote :

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

Revision history for this message
Waz (paviluf) wrote :

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

Revision history for this message
Waz (paviluf) wrote :

That really need to be fixed for the next LTS.

Revision history for this message
Waz (paviluf) wrote :

Again please fix this old bug...

Revision history for this message
Waz (paviluf) wrote :

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

Changed in ubiquity (Ubuntu):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Revision history for this message
Waz (paviluf) wrote :

Hello Mathieu,

Did you find the problem ?

And thank you for taking care of this !

Revision history for this message
Len Ovens (len-ovenwerks) wrote :

Still here in Zesty (surprise!)

Revision history for this message
PJSingh5000 (pjsingh5000) wrote :

Experiencing this bug in Artful Ardvark 17.10.

Revision history for this message
Waz (paviluf) wrote :

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

tags: added: bionic
removed: xenial
Revision history for this message
mpb (mpb) wrote :

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

Changed in ubiquity (Ubuntu):
assignee: Mathieu Trudel-Lapierre (cyphermox) → nobody
tags: added: rls-x-notfixing
removed: rls-x-incoming
tags: added: rls-ee-incoming
tags: added: rls-ee-notfixing
removed: rls-ee-incoming
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.