encrypting swap partitions leaves behind a line in fstab for unencrypted swap

[Donny Viszneki]

Binary package hint: cryptsetup

After a routine software update, I get this message when booting:

"One or more of the mounts listed in /etc/fstab cannot yet be mounted:"
"swap: waiting for UUID=4dcb..."
"Press ESC to enter a recovery shell"

Pressing ESC takes me to gdb where I can login and work somewhat normally for some arbitrary period of time. Initially there is one problem: switching to a VT gives me a corrupt, useless display. Usually while playing a game or working on an application using OpenGL, but sometimes when not doing anything like that, my display becomes completely black for about 1-2 seconds, and then returns. After returning, Xorg is pegging one of my CPU cores for 100% of its processing power, and applications randomly give me errors.

I was able to solve these problems by disabling swap, but this solution is really only temporary. I disabled swap by commenting out these lines from my fstab:

# swap was on /dev/sda2 during installation
#UUID=4dcb7a74-0f73-4f1f-9215-a1dcef29549e none swap sw 0 0 # /dev/sda2
#/dev/mapper/cryptswap1 none swap sw 0 0

I discovered also that /dev/sda2 was no longer assigned the "4dcb.." UUID:

donny@donny-desktop:~/src/hg/gpsee$ ls -l /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 2010-01-21 03:09 2c20b79b-bb2c-4422-9d48-d1cc487b189f -> ../../sda1
lrwxrwxrwx 1 root root 10 2010-01-21 03:09 46ad1127-89ed-4d27-886e-3ad3898f9243 -> ../../sda3
lrwxrwxrwx 1 root root 23 2010-01-21 03:09 c0bb7577-4587-4b9d-8dc6-48a3df1b9079 -> ../../mapper/cryptswap1

So I suspect that somehow cryptsetup ends up blowing away my swap partition so that it can no longer be identified by UUID. It should probably be removing or commenting out the line about the old unencrypted swap mount. Here is the output of mount, followed by the contents of my /etc/crypttab:

donny@donny-desktop:~/src/hg/gpsee$ mount
/dev/sda1 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
/dev/sda3 on /home type ext3 (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
/home/donny/.Private on /home/donny type ecryptfs (ecryptfs_sig=eb08bc25547c96d2,ecryptfs_fnek_sig=2640208f63a25b5d,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)
gvfs-fuse-daemon on /home/donny/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=donny)
donny@donny-desktop:~/src/hg/gpsee$ cat /etc/crypttab
# <target name> <source device> <key file> <options>
cryptswap1 /dev/sda2 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

I suppose next I'll try to uncomment the fstab entry for the cryptswap1 system, but first I'll submit this bug report...

ProblemType: Bug
Architecture: amd64
CheckboxSubmission: f46ebfb233fc249e0f808211ccbc994b
CheckboxSystem: daed2f3d6643b4a84b4520a2427f8c2b
Date: Fri Jan 22 06:08:05 2010
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
NonfreeKernelModules: nvidia
Package: cryptsetup 2:1.0.6+20090405.svn49-1ubuntu7.2
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-17.54-generic
SourcePackage: cryptsetup
Uname: Linux 2.6.31-17-generic x86_64

[Steve Langasek (vorlon)]

Hi Donny,

# swap was on /dev/sda2 during installation
#UUID=4dcb7a74-0f73-4f1f-9215-a1dcef29549e none swap sw 0 0 # /dev/sda2
#/dev/mapper/cryptswap1 none swap sw 0 0

What precisely did this look like before you commented it out? Where both the 'UUID' and '/dev/mapper/cryptswap1' lines uncommented?

The /etc/crypttab, paired with the latter line from /etc/fstab, look correct to me; but if you had both of these 'swap' lines enabled before, then it's no surprise this would not work as expected. The question is, what created these lines in /etc/fstab? This looks like an installer problem, not a cryptsetup bug.

However, I'm not sure how to attribute most of the other problems you describe (video corruption, CPU usage, etc) to the fstab issue, either. Have you tested with uncommentin the cryptswap1 fstab line yet? What was the esult?

[Steve Langasek (vorlon)]

BTW, one reason the cryptsetup update would have caused this to manifest is that prior to the update, cryptsetup in karmic would *completely fail* to start encrypted swap for most users. So if re-enabling the fstab line causes your stability problems to reappear, this likely points to an underlying problem with swap on your system, not an issue with cryptsetup itself...

[Donny Viszneki (donny-viszneki)]

Steve: Yeah I agree with all of your assessments. To address your questions:

> What precisely did this look like before you commented it out?

Nothing was commented out initially. I commented both out as an experiment before posting the bug.

> Have you tested with uncommentin the cryptswap1 fstab line yet? What was the esult?

Yes, it seems to be working normally.

> if re-enabling the fstab line causes your stability problems to reappear, this likely points to an underlying problem with swap on your system, not an issue with cryptsetup itself...

I plan on giving it a try sometime soon. I am, though, just a little bit worried about some kind of corruption permanently affecting something I use for work or long-term operation of the system. "Random errors from programs" as I stated in my original report probably sounds a lot like running out of memory, but to be clear, I had plenty of free RAM, using under a gigabyte of the four I have.

So, to close this up: definitely an installer/upgrader problem, not an actual operation problem, with cryptsetup. Is your reason for pointing this out because I filed my bug improperly, or just taking stock of the situation?

hasta luego :)

[Steve Langasek (vorlon)]

I wouldn't say that you've filed it improperly, but from here I do need to reassign the bug to a different package to hand off to someone else. :) Pointing this at user-setup, which Colin says is likely the installer component responsible.