Reinstalling over a previous installation with encrypted swap displays a "Continue without swap" warning dialog

Bug #1066342 reported by Jean-Baptiste Lallement
48
This bug affects 9 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Confirmed
High
Unassigned

Bug Description

Quantal Desktop 20121012.3

TEST CASE
1. Install Ubuntu once with the 'Encrypt home directory' option selected in user setup
2. Install it a second time, and in partman select "Reinstall Ubuntu 12.10"

ACTUAL RESULT
A warning dialog "Continue without swap" is displayed.
So the user can:
1. Reinstall but without swap
2. Use the manual partitioner but then he cannot reinstall
3. Format the swap space manually which is a highly technical task.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: ubiquity (not installed)
ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5
Uname: Linux 3.5.0-17-generic x86_64
ApportVersion: 2.6.1-0ubuntu3
Architecture: amd64
Date: Sat Oct 13 18:55:14 2012
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: ubiquity
UpgradeStatus: Upgraded to quantal on 2012-01-31 (255 days ago)

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :
summary: - Reinstalling over a previous installation with encrypted swap results
- displays a "Continue without swap" warning dialog
+ Reinstalling over a previous installation with encrypted swap displays a
+ "Continue without swap" warning dialog
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/1066342

tags: added: iso-testing
tags: added: testcase
Changed in ubiquity (Ubuntu):
importance: Undecided → High
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
tags: added: trusty
Revision history for this message
CSRedRat (csredrat) wrote :

When this fixed in 14.04 Trusty Tahr for 14.04.1 (24 July)?

Revision history for this message
John Gilmore (gnu-gilmore) wrote :

This is not fixed in Ubuntu-Gnome 14.04.2 LTS.

I recently installed Ubuntu-Gnome 14.04.2 LTS on a few machines and invented a workaround. The script that sets up encrypted swap (/usr/bin/ecryptfs-setup-swap) should first do a mkswap on the partition (if it isn't already set up), then use the "offset=" parameter in crypttab to avoid clobbering the first bytes of the swap partition. I set it to 2048 (512-byte blocks, totaling 1MB) because megabyte alignment of partitions is now the default for avoiding performance issues in disk drives with various physical block sizes, yet losing only 1 megabyte from a swap partition is a tiny fraction of a modern swap partition, and thus easily tolerable.

My crypttab currently reads:
cryptswap1 UUID=b742ddee-4f75-4826-9c43-2a08778560d4 /dev/urandom swap,cipher=aes-xts-plain64:sha256,size=512,offset=2048

The relevant change is "offset=2048" on the end.

This does not allow the installer to automatically detect swap from a PREVIOUSLY encrypted swap partition that starts at offset=0. But if the installer starts doing this now, FUTURE installers will be able to see the swap partition as a swap partition,
and can use it either encrypted or not.

Also, this allows the swap partition to be detected via its UUID. When encrypted with the offset defaulting to zero, it encrypts
the UUID, puts the UUID into crypttab, and then subsequent reboots cannot find the swap partition.

One additional change is in this crypttab for your consideration: I changed from the default cipher to aes-xts-plain64 (and the key size from 256 to 512) because the dm-crypt documentation says it's a better choice than the default.

I also recommend that the installer provide a checkbox to allow users to encrypt their swap partition even if they don't encrypt their file systems or drives. This is because active keys and other valuable data needing protection often exist in process address spaces that get written to the swap partition.

Revision history for this message
Simplehuman (simplehuman) wrote :

Can't confirm it on Xenial

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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