"unsafe swap space detected" error prevents encrypted install when swap partition exists

Bug #1490824 reported by mpb
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I am trying to install wily-desktop-i386.iso, downloaded on August 31.

I am trying to install onto a USB drive, sdc, with sdc1 being /boot and sdc2 being a physical volume for encryption.

Also on this system is a hard drive, sda, with a previous Ubuntu install, including a swap partition.

When I try to create a physical volume for encryption on sdc2, I am prompted for a password. After entering the password, the following message is displayed:

"Unsafe swap space detected. An unsafe swap space has been detected. [snip] Please disable the swap space (e.g. by running swapoff) ..."

The problem is, no matter how many times I run swapoff, ubiquity reactivates the swap automatically and repeatedly.

For example, even if I run swapoff immediately prior to entering the encryption password, ubiquity will reactivate the swap prior to creating the physical volume for encryption, and the creation will again fail.

So...

1) It appears that swapoff is insufficient. In reality, there must be no visible swap partitions on the system.

2) The error message "Unsafe swap space detected" could certainly be displayed prior to asking me to enter my password.

Either or both of these could be fixed. Or the error message could be updated to say: "Sorry, you cannot create encrypted partitions as long as swap partitions are visible on this system."

Thanks!

Tags: iso-testing
mpb (mpb)
description: updated
Revision history for this message
Jb (jebsolutions) wrote :

Confirmed. Still broken.

While there is a work around for this that works I would ask the devs to please consider the following three things and to increase the priority of this item.

First, I don't think I'm the only one who thinks full disk encryption is a "must have" security feature on any operating system in 2015. Must have also implies must work.

Secondly, this should just work out of box. If you know enough to google and figure out how to manually unmount the compressed ram swap then congratulations. You are the less than 1% of people who will succeed in getting this feature to work. The other 99% will just call this feature broken.

Third, this feature has been broken since at least 14.04.

Changed in ubiquity (Ubuntu):
status: New → Confirmed
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:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1490824

tags: added: iso-testing
Revision history for this message
GizmoChicken (gizmochicken) wrote :

Now that Ubuntu uses a swap file instead of a swap partition, this bug should be less of an issue for most users. But for when a swap partition, rather then a swap file, is truly needed (for example, when using a swap file unfriendly file system, like btrfs), here's a work around:

Before installing your system, create an additional partition for swap using gparted.

Then, during system installation, create a LUKS-encrypted volume on that partition, but do NOT format the volume as swap. (Last time I tried, swap, even if within a LUKS volume, blocked installation.) Rather, during installation, format the extra LUKS volume as ext4 or btrfs, but leave it otherwise unused.

After Ubuntu is installed, reformat the file system within the LUKS volume to swap, and then adjust fstab and crypttab as needed.

Using this work around, swap will be protected within its own LUKS volume. But again, unless a swap partition is truly needed, using a swap file may be an easier approach.

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.