Alternate and Server CD installer fails to create encrypted swap parition

Bug #321732 reported by Carlos
2
Affects Status Importance Assigned to Milestone
partman-crypto (Ubuntu)
Fix Released
High
Colin Watson

Bug Description

I'm running Ubuntu 8.10 and I used the Alternate Install CD for my installation on a dell e1505 laptop. I also used the server install CD for installation onto an old PC. In both cases, I chose manual partitioning and chose to create a swap partition as a physical partition. I chose to have that partition be an encrypted volume, using a random key. In both cases, the installation seemed to work without any errors. However, when looking at the amount of memory I had available after the system was running, I noticed that there was no swap being reported. I checked /etc/crypttab and it had this entry:

sda3_crypt /dev/disk/by-uuid/ /dev/urandom cipher=aes-cbc-essiv:sha256,size=256,swap

As you can see, there isn't actually a uuid listed after the /dev/disk/by-uuid field. I replaced that field with /dev/sda3 in /etc/crypttab and that seems to work.

I haven't tried the desktop installer, but this at least happens with both the alternate and server install cds.

Revision history for this message
Colin Watson (cjwatson) wrote :

Could you please attach /var/log/installer/syslog and /var/log/installer/partman, so that I can see what the installer thought it was doing?

Changed in debian-installer:
status: New → Incomplete
Revision history for this message
Carlos (bitbuck3t) wrote :

Sorry for the delay, I didn't have access to my machine while I was at work. I have attached the two files you requested. I masked my ip addresses and hostname form syslog, but other than that, everything is exactly how it was.

Revision history for this message
Carlos (bitbuck3t) wrote :
Revision history for this message
Colin Watson (cjwatson) wrote :

Yow! It's trying to get the UUID from the encrypted block device, rather than from the unencrypted device exposed by device-mapper. That isn't going to work!

Changed in partman-crypto:
assignee: nobody → kamion
importance: Undecided → Critical
status: Incomplete → Triaged
Revision history for this message
Colin Watson (cjwatson) wrote :

LUKS (the passphrase key type) works, because LUKS has a header containing a UUID. Other key types appear not to work.

Changed in partman-crypto:
importance: Critical → High
Revision history for this message
Colin Watson (cjwatson) wrote :

And indeed it did actually want the UUID of the encrypted block device, if available. Therefore, the fix is simply to use it only if it's available.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package partman-crypto - 36ubuntu3

---------------
partman-crypto (36ubuntu3) jaunty; urgency=low

  * Use UUIDs only if available, fixing key types other than passphrase
    since only LUKS actually has a UUID (LP: #321732).

 -- Colin Watson <email address hidden> Wed, 28 Jan 2009 01:38:06 +0000

Changed in partman-crypto:
status: Triaged → Fix Released
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.