Ubiquity doesn't suggest to install on unallocated free space

I tested this and your observation seems to be true...

I would very much appreciate a reaction from the developers.... This concerns a pretty important aspect of Ubiquity. And time is running out for Maverick final edition.

@Jan Claeys: thanks for your contribution. Could you please also click "this bug affects me" (upper left of this page) for this bug? That would help underline the need for fixing. :-)

The bug isn't present in ubiquity of Kubuntu 10.10, so I can't confirm it. The installer of Kubuntu 10.10 dated October 2, 2010 gave me the option to install on the unallocated free space.

Use the option "Install alongside other operating systems" for a new installation in a unpartitioned part of the disk.

@CeesSluis: that didn't work on my laptop. The hard disk of 100 GB contained a Windows partition of approximately 80 GB and about 20 GB free unallocated space (the former Ubuntu partition which I destroyed with Gparted).

When I chose the "alongside" option, Ubiquity then only offered the option to take some space from the existing Windows partition. It would do nothing with the unallocated free space.

Didn't work for me too. I have a 10 GB free unallocated space and choosing the alongside option, ubiquity wants to resize another partition.

It would be great if some developers could explain the criteria adopted by ubiquity besides this installation mode.

With three independent confirmations, I think it's appropriate to mark this bug as "confirmed" again.

Well, before anyone can confirm it, I first want an explanation why this bug isn't present in ubiquity of Kubuntu 10.10 They both use the same version and installer, only the design is different, but the rest is the same. So I don't think this is a bug in ubiquity, else the bug would've been present in ubiquity of Kubuntu too.

@Vistaus: this is the second time that you change the status from Confirmed to something else. Please don't do that.

This bug has been reported as "ubiquity (Ubuntu)", so this bug report targets Ubuntu and not Kubuntu. Of course it's interesting to know what ubiquity does in Kubuntu, but strictly speaking that's outside the boundaries of this bug report. The difference between KDE and Gnome is simply too big.

KDE has nothing to do with the installer of Kubuntu, just like GNOME has nothing to do with the installer of Ubuntu.

"This bug has been reported as "ubiquity (Ubuntu)" "
That obvious, 'cause there is no way to file a bug report against "ubiquity (Kubuntu)".

"Of course it's interesting to know what ubiquity does in Kubuntu, but strictly speaking that's outside the boundaries of this bug report."
For the second time, Ubuntu and Kubuntu use the SAME version of Ubiquity. So they both should work the same. Except for the design, there is NO difference between the Ubiquity's. So it's not that's interesting to know, 'cause it has to do with Kubuntu too, since it uses the same version of ubiquity.

I can confirm this bug. It is actually a HUGE problem for me right now. I didn't know this was going to be missing, so I deleted my previous ubuntu partitions and tried to install 10.10 on the free space. Now, I'm stuck working on the Live CD because there is no option to install in the "largest continuous free space" like in previous releases.

I've never used the advanced option. Is it possible to install ubuntu in the free space using that option? What are the steps? Since people will likely be affected by this bug without much recourse (it's not like they can update the installer on 10.10), it would be good to list the steps for a workaround with the advanced option if possible.

@DanielRoesler:
I've published a workaround with screenshots on this page:
http://sites.google.com/site/easylinuxtipsproject/partitioning

I very much hope that this problem will be fixed in 11.04.

This affected me too. I did not install 10.10 'cos the option was missing and the installer is not as easy and clear as 10.04. Please go forward by going back to the 10.04 style!

It affected me too.
I have been using this method since 9.10 (when I had my first Ubuntu upgrade) and it was easy and fast.
Now I removed the partition, resized windows to the full hd and went back and picked the install dualboot option.
This obviously takes a lot longer and is not as direct.
I know of the manual option, but I am afraid of using it as I don´t know how. (I only saw the tutorial minutes ago)

-Glenn

This affects me too. IMHO this is a grave usability regression and should at least be addressed as known issue in the release notes.

As with any new install, I spent time checking through all the known issues, then decided to go ahead and install.
As I'm installing on a not-so-fast tablet pc, the whole process of booting the Ubuntu CD, resizing Windows partition, rebooting into Windows for its disk check (which does a reboot of its own), rebooting again into Ubuntu CD, running install, only to find out that the only way to install into free space is to do the old hackish 'whip out the calculator and a scratchpad and roll your own partition layout' is simply _unacceptable_ anno 2010.

Please fix this!

I cannot believe there aren't more than 14 for "this effects me." It effects EVERYONE because the option to install using free space DOES NOT EXIST.

Seems someone, somewhere within the bowels of the Canonical / Ubuntu dev team should just put back what was either intentionally left out or left out by mistake. In any event, this effects ALL users trying to install 10.10.

Sorry about the spelling error above. "effects" should be "affects". There seems to be no edit button.

I have this issue on a newly downloaded 64bit install

This is a serious screw up by Canonical.

If the folks at Ubuntu think "install into free space" is too complicated for the average user, maybe this feature could be put into the advanced partitioner screen? Alongside the "Add..." button to add a new partition in the selected free space could be an "Allocate automatically" button or some such.

I thought I should update this a bit because the instances of people wiping out their existing Windows OS and/or data have clearly increased.

The following three bugs are all related:

bug 655950

bug 682429

bug 657397

IMHO we need to bring back the option to "Install to largest continuous free space" and get rid of the "Use entire partition" and "Use entire disc" in the screen after choosing to "Install alongside"!

Doing so would potentially only leave bug 657397.

What can I say? Terrible terrible terrible...

Instead of upgrading this, my 3rd maverick machine, from lucid, I decide to do a clean wipe. I install Windows 7 from usb, giving it a smallish 50GB partition, leaving ~450GB free. Very straightforward. Then, I boot up the livecd off usb, choose install alongside, and what the hell? It's trying to split up the existing 50GB NTFS partition into two smaller ones. No option in sight to use the available 450GB that I specifically set aside for Ubuntu. Duh!

Thanks for forcing me into using the manual partitioner. I'm a huge proponent of Ubuntu, but this deserves the harshest possible criticism. No need to have a humble opinion on this one. I've said it before and I'll say it again: see bug #1.

Note that this was serious problem 3 out of 3 that I encountered while doing what should have been a straightforward install on a very vanilla system. No sane user would have bothered.

I changed this to a regression/confirmed status. The "use largest continuous space" option did add value to ubiquity, and any loss of usability is a bug.

OTOH adding the options to use entire disc/partition to the side-by-side option have only resulted in confusion and in many cases data loss as I've reported in the aforementioned bugs.

Since Colin Watson is now assigned to bug 659106 I'm in hopes that we'll be able to restore some sanity to ubiquity.

Google this: "The installation experience should be attractive and effortless to reassure new users that Ubuntu is the right choice. The process should feel safe and should only highlight risk when necessary (e.g. when data will be destroyed)."

We're NOT living up to that standard!

This is back in Natty, but the UI isn't complete.

Maybe I'm being dense, but would it help move this forward if "UI isn't complete" is more detailed?

Why is the status changed from confirmed to invalid?

 > Why is the status changed from confirmed to invalid?

Because we don't track bugs against the Ubiquity project; we use the ubiquity source package in Ubuntu. The bug is still marked as confirmed against the latter.

 > Maybe I'm being dense, but would it help move this forward if "UI isn't complete" is more detailed?

You can once again use a large amount of unpartitioned space on the disk for Ubuntu. The option is "Install Ubuntu alongside it." However, in current daily-live CDs, this will proceed to a second screen (and likely crash, given bug 727842) that's currently unrelated to this option.

This is fixed in ubiquity trunk, which I'll be uploading shortly. New CDs will be out roughly one day after this bug gets automatically closed. Make sure the version of ubiquity you're using (ubiquity --version) is 2.5.23 or greater before filing any new bugs.

This bug was fixed in the package ubiquity - 2.5.23

---------------
ubiquity (2.5.23) natty; urgency=low

  [ Evan Dandrea ]
  * Ensure we always have an automatic partitioning option selected.
  * Merge in latest change to apt-clone from Michael Vogt:
    - Current apt_pkg API methods.
    - Better command line argument parsing.
    - Set DPkg::Chroot-Directory (LP 727758).
  * Do not attempt to proceed to a second page with the biggest_free
    option (LP: #727842, LP: #652852). This will change once we have an
    interface for the biggest_free option.
  * If the partition table is full and a copy of Windows exists, replace the
    resize option with a copy of wubi.exe to the Windows startup folder,
    followed by a reboot.
  * Temporary fix for translations with carriage returns (LP: #730498).
  * Update translations from Launchpad.
  * Automatic update of included source packages: console-setup
    1.57ubuntu10.

  [ Colin Watson ]
  * Set Dir::Media::MountPath as well as Acquire::cdrom::mount (in line with
    base-installer), and pass all the options set by configure_apt to
    python-apt as well so that attempts to install packages from python-apt
    will behave consistently (LP: #727783).

  [ Julien Lavergne ]
  * bin/ubiquity-dm:
   - Wait lxsession before launching the panel, to have theming support.
     (LP: #684802)
  * src/panel/panel.c
   - Load lxpanel background for the panel when it's available.
 -- Evan Dandrea <email address hidden> Mon, 07 Mar 2011 09:16:26 +0000

I'm iso-testing the first Beta1 i386 image and just revisiting this. In bug 655950 post #39 I'd asked:

"I understand this being marked as "milestone beta" and I'm sure that's a challenge. I do appreciate the complexity of dealing with this issue.

With Alpha 2 iso-testing coming up I see no need to re-report this bug but given the fact that I've had no feedback from either Evan or Colin I'm curious what the status is regarding bug 652852 ?

Have any redesign decisions been made?"

And in post #43 Evan Dandrea replied:

"It's assigned to me and milestoned for 11.04 beta."

Not to be pushy, but I began this test with a 20GB unallocated space and this option was still not offered. Instead it offered to resize the most proper partition. Not a huge problem but I do need to know what the plans are regarding this ;^)

If there is more space free in a partition that could be resized than is available in unallocated space, then the unallocated-space option is dropped. I'm guessing that the theory here may be that you can just use the "Install alongside" option and leave the other OS' size unchanged, thereby reducing the number of automatic partitioning options we need to present. However, the "Install alongside" option doesn't actually let you use unallocated space - it always resizes. I think we should present unallocated space, as people may well prefer not to reduce the amount of space available to their other OS.

Another problem I notice is that if the only other partitions present are data partitions - that is, os-prober outputs nothing - then you get neither the unallocated-space option nor the resize option. This seems like a bug, as resizing is perfectly possible here. Perhaps the 'if os_count == 0:' branch in calculate_autopartitioning_options needs to consider resize options.

I'll ask Evan to comment on this, and reopen or spin off a new bug report as necessary.

"If there is more space free in a partition that could be resized than is available in unallocated space, then the unallocated-space option is dropped."

That makes sense, at least to some degree. I'll do some retesting - probably between beta1 and beta2 - and report back :^)

Do you and Evan have a dart board dedicated to me yet?

"If there is more space free in a partition that could be resized than is available in unallocated space, then the unallocated-space option is dropped."

I disagree with this logic. It should not be assumed that the user always wants to install in the largest available space (whether that be in a partition or unallocated).

This is the case for me. I have a 60GB WinXP partition (30GB free) and 20GB unallocated. This logic assumes that I want to install by resizing the WinXP partition, but I just want to install in the unallocated space (more than enough for the install).

The the option for installing in unallocated space should always be offered when there is enough space, not just when the unallocated space is the largest available.

I agree with Daniel above. The existing logic as described is a bit silly. The option to install to an unallocated partition should *always* be available. And really, since it's the safest option, it should also be the default (when unallocated space is available).

Daniel and Martin make a very point. It's quite likely that a person with a very large disc might still allocate only a small bit, say 20GB out of a 1TB disc, for Ubuntu.

I need to repeat a number of tests, like what does Ubuntu do if 4 primary partitions already exist, what happens with 3 primary partitions, etc.

Have a look at bug 655950 and the two dupes I attached. I need to perform a lot of installation scenarios to be certain that we don't repeat any of the mistakes made in Maverick.

All testers welcome ;^)

I think a careful reading of my comment will reveal that I agree with you.

This is an important issue for me, it caused me to stop recommending 10.10 to inexperienced students. I'm sorry I've not found the time to test some alphas.

So my comment may not be correct, but the feeling I'm getting is that there's unwise effort being put in to make the installer too "smart". What's wrong with having an installer say "I see you have the following partitions and free space, I recommend such and such" and listing all the partitions as candidates. If the punter picks a poor choice, lots of warning, e.g. "You have chosen to overwrite your Windows partition, DO NOT do this if you wish to keep Windows, all your data will be lost, etc etc", lots of 'back' buttons. Ideally by means of a diagram, much as GParted does it, but otherwise a simple text list if that's too ambitious.

Sometimes all this "smart help" just gets in the way. Inexperienced users can make good choices if they're presented in a straightforward and transparent fashion.

[insert cartoon of dancing paperclip: "I see you're writing a suicide note, would you like help with that?"]

OK testing this AM with the 03/29 i386 iso-testing image and after choosing the side-by-side option no new window popped up indicating what the installer was going to do, so I kind of freaked out.

At this point I noticed that the option to quit the install no longer existed. I didn't notice yesterday if the quit option existed or not.

Anyway, I clicked on the back button and it did go back - kind of - the screen indicated it was going back but I could tell by the progress bar and the sound of the optical drive that the installer was installing, or partitioning.

As I said above, I kind of freaked out, so I just hit Alt>SysReq>B to reboot. As it turns out the installer was basically doing the preferred thing. I began with my typical two drives:

Model: ATA WDC WD5000AAKS-0 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 32.3kB 43.3GB 43.3GB primary ext3 boot
 2 43.3GB 86.2GB 42.8GB primary ext3
 3 86.2GB 129GB 43.0GB primary ext3
 4 129GB 500GB 371GB extended
18 129GB 151GB 21.8GB logical ext4
14 151GB 172GB 21.1GB logical ext4
15 172GB 193GB 21.1GB logical ext4
16 193GB 215GB 21.4GB logical ext4
17 215GB 236GB 21.4GB logical ext4
13 236GB 258GB 22.0GB logical ext4
12 258GB 280GB 21.6GB logical ext3
11 280GB 301GB 21.7GB logical ext4
10 301GB 323GB 21.8GB logical ext4
 5 323GB 378GB 55.1GB logical ext3
 6 378GB 432GB 53.6GB logical ext3
 7 432GB 487GB 54.9GB logical ext3
 8 487GB 498GB 10.7GB logical ext3
 9 498GB 500GB 2517MB logical linux-swap(v1)

Model: ATA WDC WD800JB-00JJ (scsi)
Disk /dev/sdb: 80.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 1049kB 39.5GB 39.5GB primary ext4 boot
 2 39.5GB 80.0GB 40.5GB extended
 7 39.5GB 74.7GB 35.2GB logical ext4
 8 74.7GB 76.8GB 2128MB logical linux-swap(v1)
 6 76.8GB 77.9GB 1074MB logical ext3
 5 77.9GB 80.0GB 2136MB logical linux-swap(v1)

So things were actually going OK, /dev/sda had been left untouched, and /dev/sdb had begun with:

Number Start End Size Type File system Flags
 1 1049kB 39.5GB 39.5GB primary ext4 boot
 2 39.5GB 80.0GB 40.5GB extended
 6 76.8GB 77.9GB 1074MB logical ext3
 5 77.9GB 80.0GB 2136MB logical linux-swap(v1)

Note: sdb1, 2, and 5 made up a typical Ubuntu install, and I'd previously added sdb6 as casper-rw to do persistence testing. And the free space between sdb1 and sdb6 was pre-existing.

So the installer had created sdb7 and sdb8 in the existing free space properly, but my concern is that there was no typical "review screen" showing what it was going to do, or offering the option to use the advanced partitioner.

Is that intentional?

Also, as I said, I didn't notice if the "quit" buttons were present or not in yes...

I just completed a successful manual install and the quit and back buttons work as expected, so I think that's a non-issue.

I was just shocked that the partitioning (in this case just creating sdb7 & 8) went forward after selecting the side-by-side option with no additional indication of what the installer intended to do.

Maybe that's OK, I'm unsure. Outside of testing I always prefer laying out my partitions in advance and then using the manual install option to properly assign the partitions.

I know the old (pre-Maverick) ubiquity considered side-by-side and use largest free space two totally different options, so I guess I was expecting something either like that or the addition of use largest free space after selecting side-by-side if applicable.

I always have to try and ponder what a total noob would expect from the installer. I've twice failed in my testing responsibilities because things looked simple enough to me but it tripped up a lot of less experienced users.

I'm going to do some repeat testing using side-by-side with and without free space, and with various existing partition arrangements, but it's doubtful I'll get it all done before Beta1 releases. I'd think that's OK though.

I'll definitely keep watching the ubiquity changelog and test like crazy between now and Beta2.

Before I could report my last "manual install" results they'd begun a rebuild. So, once it was done, I repeated a live test followed by two "side-by-side" tests.

The first I did with three "occupied" (one was a SWAP) primary partitions on sdb and no free space. The installation worked as expected, that is I got the common screen telling which partition would be resized, allowing for the option to choose advanced partitioning. I think that's great! No more buttons to confuse noobs ;^)

The next I did after deleting some partitions on sdb so there was about 35 to 40GB of free space and I let her rip! It all worked fine, I just still question if another screen should follow indicating which free space/which device is going to be used.

What if someone had a live iso running on a fairly large flash drive with an additional partition? Or if they'd left a data drive with free space plugged in?

I'm just looking for what could possibly go wrong. But I'm absolutely unsure.

The one person that I know for sure shouldn't make the final decision is me!

Regarding the latest changes to return this option I performed a couple more tests this AM, mostly to be sure we still handled primary partition limits properly, and it appears we did.

But I was also curious what size free space would be considered appropriate to allow the installation to just proceed with no further warning after selecting side-by-side.

I'd already tried one scenario where the existing primary root partition was just over 39GB and the free space was about 37GB. In that case the partitioning and installation process just began as described above (using the free space), so I know that the free space can be smaller than the existing partition, I just don't know how much smaller.

In this latest test I created only about 10GB of unallocated space and I got the fall-back to actual resizing. Screenshot attached.

Many apologies in advance. I hope you know I'm only trying to help, but if the UI stays as is I think we'd need to document exactly how ubiquity determines whether to use the newly created free space or offer to resize an existing partition.

Could that also effect what the minimum size displayed prior to installation should be, RE: bug 745148.

I'll still bet Colin and Evan have a dartboard dedicated to me ;^)

I would say that this effects just about anyone who installs Ubuntu. Glad to see that there is movement on this.

I just happened to do a couple of installs in VMs with ubiquity 2.6.5, and this worked wonderfully. Thanks!

Improvement! But not entirely good enough yet.

I just performed an installation with the bèta 2 CD of Natty. On a computer with a 31 GB NTFS partition with Windows XP on it, and 69 GB of free unallocated space.

Ubiquity installed Natty flawlessly and automatically on the unallocated space, after I selected the "alongside Windows" option. But: Ubiquity didn'n notify me that it was doing so! It just went along without reporting anything. Only after the installation I could verify that everything had gone well, by means of Disk Utility.

When Ubiquity plans to use the unallocated space, it should say so beforehand. So that you know what it'll do to your hard disk, before you give the "go" command.

I agree with you but that's not what the spec calls for:

https://docs.google.com/View?id=dfkkjjcj_101gnkrpg5v#4_5_1_Automatic_partitioning_o_8475526086986065

I've beat my brains out on this, and I'm not even sure who to argue with any more.

BTW I tried this again just this AM by freeing up only 10GB on my drive sdb and it worked great:

lance@lance-desktop:~$ sudo parted /dev/sdb print
Model: ATA WDC WD800JB-00JJ (scsi)
Disk /dev/sdb: 80.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 1049kB 67.3GB 67.3GB primary ext4
 2 67.3GB 80.0GB 12.7GB extended
 6 67.3GB 75.8GB 8455MB logical ext4
 7 75.8GB 77.9GB 2132MB logical linux-swap(v1)
 5 77.9GB 80.0GB 2136MB logical linux-swap(v1)

lance@lance-desktop:~$ sudo parted /dev/sda print
Model: ATA WDC WD5000AAKS-0 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 32.3kB 43.3GB 43.3GB primary ext3 boot
 2 43.3GB 86.2GB 42.8GB primary ext3
 3 86.2GB 129GB 43.0GB primary ext3
 4 129GB 500GB 371GB extended
18 129GB 151GB 21.8GB logical ext4
14 151GB 172GB 21.1GB logical ext4
15 172GB 193GB 21.1GB logical ext4
16 193GB 215GB 21.4GB logical ext4
17 215GB 236GB 21.4GB logical ext4
13 236GB 258GB 22.0GB logical ext4
12 258GB 280GB 21.6GB logical ext3
11 280GB 301GB 21.7GB logical ext4
10 301GB 323GB 21.8GB logical ext4
 5 323GB 378GB 55.1GB logical ext3
 6 378GB 432GB 53.6GB logical ext3
 7 432GB 487GB 54.9GB logical ext3
 8 487GB 498GB 10.7GB logical ext3
 9 498GB 500GB 2517MB logical linux-swap(v1)

But what if someone didn't plan on using that free space?

It seems like using free space and side-by-side should be two different things.

Since this is marked fix released I created bug 766265 (Natty ubiquity proceeds to use free space without warning).

I hope I'm not just coming across as pushy.