Ubuntu installer says: The creation of swap space in partition failed

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

Same problem, all partitions are shown at least twice (precise release), and if swap space is there, the mentioned error is displayed.

In my case, the system was already partitioned, I just needed to reformat some of them. Choosing "do not use" for all swap partitions helped me to get through the installation successfully. Guess I'll have to add the swap space later by hand.

So, the bug is confirmed but is anyone fixing it?
I'm not a coder, but I will reiterate that any information needed I'll gladly post it, if I can. I really want to use this LTS.

Make sure you have run the last item in the long list of executable items (<down> many times, or you won't see).

This item will commit your disk using plan - write to disk, then you may advance to next step.

What list? The one showed in a block box during setup?

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

Just to say I tried this in 12.10 aplha 3 ang get the same result.

I tried this with 13.10 and had the same problem.
The work-around is to manually set every swap partition entry to 'do not use', save one.
It installed fine for me afterwards.

Present in the latest Wily Xubuntu ISO.

Just happened to me while performing an auto-resize test with Ubuntu GNOME 20151020 Wily, see screenshot.

20151023 wily install: I cleared up, or bypassed, the problem by unlocking the swap partition using "Swapoff" option found in GParted.

^^^^^
Xenial install: This has something to do with how extended partitions are treated as locked.

After reformatting the drive through GParted live:
1. Delete main ext4 partition
2. Delete swap partition inside the extended container.
3. Delete extended container partition.

The container partition will not permit itself to be formatted until the swap partition inside is cleared.
After using these steps, the installation successfully completed.

Very user-unfriendly when installing and selecting "ERASE ENTIRE DISK", knowing the implications.
Anyway to instruct the installer to bypass the lock and force format?

mkswap fails because you appear to have something that looks like an MBR ( like a previous fat filesystem ) in that partition and mkswap has a foolish check where it refuses to wipe out an MBR that is triggered by this and the fact that you are using fakeraid. You can work around this by using dd to copy /dev/zero to the first sector of the partition. The proper fix for this is for mkswap to be invoked with a -f switch to force it to erase the MBR.

ISO-testing Lubuntu Xenial desktop amd64:

There is a window with the title ' Could not create a swap partition' and the text 'Failed to create swap in partition no 5 on SCSI7 (0,0,0) (sda) [In Swedish]

There was already swap created by the i386 version and accepted by it at 'Something else' (by the same Xenial beta 1). But this amd64 version does not like it for some reason.

I have been able to share a swap partition before between i386 and amd64 versions of linux.

It did not help to swapoff manually before running the installer.

Yes Phillip Susi,

I was not even able to create a new swap partition (using the whole drive).

A clean drive worked (I wiped the SSD) - It seems the amd64 version is more picky than the i386 version (of the same Xenial beta 1).

Xubuntu Xenial Beta 1 - desktop amd64

I have this bug too. During the ubiquity installation, if I chose the option "Erase disk and Install Ubuntu", just after clicked "continue", a window appear (during the timezone window) and says :

"Failed to create a swap space:
The creation of swap space in partition #5 of SCSI3 (0,0,0) (sdb) failed"

I click on "ok", and I'm back on the window "installation type". I can't install in these state.

Which is weird is I don't have /dev/sdb but it's detected, and it supposed to be the usb key which I use to install Xubuntu Xenial.

"The proper fix for this is for mkswap to be invoked with a -f switch to force it to erase the MBR."

- the ever-knowledgeable Phil Susi

Yes, I trust Phillip Susi, but during an installation with Ubiquity is supposed to work without this fix. The installation is suppose to work automatically.

I'm talking for myself, I don't know how to use this fix.

"I'm talking for myself, I don't know how to use this fix."

He gave two options. One was a workaround. The other, a fix was intended to be patched into the Ubiquity installer. But then he moved the bug to partman-basicfilesystems.

Unless ubiquity is calling on partman to do the format, I'm left scratching my head as to why it was moved...

Yes, partman-basicfilesystems is what actually does the format.

Still affects 20160323.1 Ubuntu GNOME.

Also clicking OK does nothing so you have no choice but to reboot the live image.

This is turning out to be a real show-stopper for Xenial!

Of course we could just recommend users use dd as suggested, and then listen to the users weep when they find that they've invoked it against the wrong device and learned why it earned the moniker data destroyer.

I see a new bug has been filed, bug #1552539. So are the two duplicates?