Encrypted swap no longer mounted at bootup

Bug #953875 reported by Alan Pope 🍺🐧🐱 🦄 on 2012-03-13
This bug affects 254 people
Affects Status Importance Assigned to Milestone
Dustin Kirkland 
Fix Released
ecryptfs-utils (Ubuntu)
Martin Pitt
Martin Pitt
systemd (Debian)
Fix Released
systemd (Ubuntu)
Martin Pitt
Martin Pitt
ubiquity (Ubuntu)

Bug Description

During installation with "encrypt my home folder" mode, a broken /etc/crypttab gets created which defines a non-existing swap device (usually "cryptswap1") with a UUID. This will also be put into /etc/fstab. As after installation the UUID does not exist, such systems don't have any actual swap.

An upgrade to Ubuntu 15.04 ("vivid") will detect and comment out these broken swap devices from /etc/fstab and /etc/crypttab. If you actually want to use those, do these steps:

 - Find the swap device that was meant to be used in "sudo fdisk -l" (it should say "Linux swap" in the last column), remember the device name (something like "/dev/sda5")
 - Find the UUID in /etc/crypttab (the long alphanumeric ID after UUID=)
 - Run "sudo mkswap -U 1234... /dev/sda5", replacing "1234" with the above UUID, and /dev/sda5 with the device name from step 1.
 - Edit /etc/crypttab to append ",offset=1024" in the fourth (last) column of the cryptswap1 line; ensure that there is *no space* between the "cipher=aes-cbc-essiv:sha256" and the appended option. If there is a leading "#" in the file, remove that too.
 - If there is a leading "#" in /etc/fstab in the line starting with /dev/mapper/cryptswap1 line, remove that.
 - Run "sudo update-initramfs -u".


Clean install of 12.04 and with encrypted home for my user. Did all updates and now the bootup hangs waiting for swap to become available and it never seems to ever finish. The 200GB SSD below is my boot drive and root filesystem.

alan@mesh:~$ sudo swapon -a
[sudo] password for alan:
swapon: /dev/mapper/cryptswap1: stat failed: No such file or directory

alan@mesh:~$ grep swap /etc/fstab
# swap was on /dev/sdg5 during installation
#UUID=22d3f7f0-f715-4582-81ba-dcbd4cdd1495 none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw 0 0

alan@mesh:~$ sudo fdisk -l

Disk /dev/sda: 115.0 GB, 115033153536 bytes
255 heads, 63 sectors/track, 13985 cylinders, total 224674128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ba2ed

   Device Boot Start End Blocks Id System
/dev/sda1 * 2048 206847 102400 7 HPFS/NTFS/exFAT
/dev/sda2 206848 224671743 112232448 7 HPFS/NTFS/exFAT

Disk /dev/sdb: 200.0 GB, 200049647616 bytes
255 heads, 63 sectors/track, 24321 cylinders, total 390721968 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xf0fa0806

   Device Boot Start End Blocks Id System
/dev/sdb1 2048 349304831 174651392 7 HPFS/NTFS/exFAT
/dev/sdb2 374722558 390721535 7999489 5 Extended
/dev/sdb3 * 349304832 374720511 12707840 83 Linux
/dev/sdb5 374722560 390721535 7999488 82 Linux swap / Solaris

Partition table entries are not in disk order

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: libecryptfs0 96-0ubuntu2
ProcVersionSignature: Ubuntu 3.2.0-18.29-generic 3.2.9
Uname: Linux 3.2.0-18-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 1.94.1-0ubuntu2
Architecture: amd64
Date: Tue Mar 13 09:56:56 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120215)
SourcePackage: ecryptfs-utils
UpgradeStatus: No upgrade log present (probably fresh install)

Launchpad Janitor (janitor) wrote :

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

Changed in ecryptfs-utils (Ubuntu):
status: New → Confirmed

alan@mesh:~$ sudo blkid
[sudo] password for alan:
/dev/sda1: LABEL="System Reserved" UUID="DCE0AE59E0AE39A2" TYPE="ntfs"
/dev/sda2: UUID="46A4B5A6A4B5993F" TYPE="ntfs"
/dev/sdb1: LABEL="New Volume" UUID="3A003B11003AD41B" TYPE="ntfs"
/dev/sdb3: UUID="2438b8df-efe6-4e65-946e-7eb9437990ec" TYPE="ext4"

alan@mesh:~$ sudo dmsetup status
No devices found

Dustin Kirkland  (kirkland) wrote :

Hiya Popey,

Can you post the contents of your /etc/crypttab?

Changed in ecryptfs-utils (Ubuntu):
importance: Undecided → High
status: Confirmed → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for ecryptfs-utils (Ubuntu) because there has been no activity for 60 days.]

Changed in ecryptfs-utils (Ubuntu):
status: Incomplete → Expired
Sean Watson (sean.watson) wrote :

I have the same trouble as OP,

my cryptab is:

cryptswap1 /dev/sda6 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

It is sda6 in Disks

Sean Watson (sean.watson) wrote :

sudo blkid:

/dev/sdb1: LABEL="PQSERVICE" UUID="E448870D4886DE24" TYPE="ntfs"
/dev/sdb2: LABEL="Vista" UUID="10941D2C941D15B6" TYPE="ntfs"
/dev/sdb4: UUID="0d4eac87-8092-4f4f-aaae-d5cb2f1247b2" UUID_SUB="1f795372-0c73-412a-9348-7e1acb5282ce" TYPE="btrfs"
/dev/sdb5: UUID="54ebe60f-388b-4e95-96a1-2238d3163401" TYPE="ext4"
/dev/sr0: LABEL="Mobile Partner" TYPE="iso9660"
/dev/mapper/cryptswap1: UUID="6ae55e5d-522a-4e03-b732-0bcb44bb2225" TYPE="swap"

I have to manually do sudo cryptdisks_start cryptswap1 before encrypted swap works. Could the status be changed from expired please?

Changed in ecryptfs-utils (Ubuntu):
status: Expired → Confirmed
Maciel (macielcalebe) wrote :

I know that it's old, but I had the same problem. Maybe it can help others.

My fstab was quite the same as @Alan Pope's, and my crypttab was...

cat /etc/crypttab
cryptswap1 /dev/sdb3 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

I found that my swap device should be /dev/sda3 instead of /dev/sdb3. So, just changing /etc/crypttab contents to

cryptswap1 /dev/sda3 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

solved my problem.

Oh, that's interesting... So the actually device name changed. Looks
like we should be using UUID's here instead of fixed device names.


On Thu, Sep 19, 2013 at 3:06 PM, Maciel <email address hidden> wrote:
> I know that it's old, but I had the same problem. Maybe it can help
> others.
> My fstab was quite the same as @Alan Pope's, and my crypttab was...
> cat /etc/crypttab
> cryptswap1 /dev/sdb3 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
> I found that my swap device should be /dev/sda3 instead of /dev/sdb3.
> So, just changing /etc/crypttab contents to
> cryptswap1 /dev/sda3 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
> solved my problem.
> --
> You received this bug notification because you are subscribed to
> ecryptfs-utils in Ubuntu.
> https://bugs.launchpad.net/bugs/953875
> Title:
> Encrypted swap no longer mounted at bootup
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/953875/+subscriptions

Changed in ecryptfs-utils (Ubuntu):
status: Confirmed → Triaged
NoOp (glgxg) wrote :

Appears to be random - sometimes it mounts, sometimes it doesn't. I think it will be necessary to use UUID's?

$ uname -a
Linux .. 3.8.0-32-generic #47~precise1-Ubuntu SMP Wed Oct 2 16:19:35 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/crypttab
cryptswap1 /dev/sda7 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

$ sudo cryptdisks_start cryptswap1
 * Starting crypto disk... * cryptswap1 (skipped, device /dev/sda7 does not exist)... [fail]

I think part of the issue is that /etc/fstab uses UUID and /dev/sdX# can change on boot (e.g. from sda# to sdb#).

My fstab (UUID's modified slightly):
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
# / was on /dev/sda5 during installation
UUID=8ed19201-fabf-4364-a507-XYZ / ext4 errors=remount-ro 0 1
# swap was on /dev/sda6 during installation
# /dev/sda7/ none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw 0 0

$ sudo blkid
/dev/sdb1: LABEL="SYSTEM" UUID="C2E04BEXYZ" TYPE="ntfs"
/dev/sdb2: LABEL="Win7" UUID="32B682AXYZ" TYPE="ntfs"
/dev/sdb4: LABEL="RECOVERY" UUID="120C19F4XYZ" TYPE="ntfs"
/dev/sdb5: LABEL=".." UUID="8ed19201-fabf-4364-a507-XYZ" TYPE="ext4" <===
/dev/sdb6: LABEL="..." UUID="6C94DF5A9XYZ" TYPE="ntfs" x

Note that all of those are are mounted as /dev/sdb#. If I boot with and external USB drive, that drive is mounted as /dev/sda#:

/dev/sda1: LABEL="GGNTSF" UUID="4868D7FF68XYZ" TYPE="ntfs"
/dev/sda5: UUID="27bd7267-ab0b-48f4-8a56-XYZ" TYPE="crypto_LUKS"
/dev/mapper/udisks-luks-uuid-27bd7267-ab0b-48f4-8a56-XYZ-uid1000: LABEL="ext4" UUID="86d20931-6b90-4082-9b14-XYZ" TYPE="ext4"

Now if I modify crypttab:
$ cat /etc/crypttab
# cryptswap1 /dev/sda7 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
cryptswap1 UUID= /dev/urandom swap,cipher=aes-cbc-essiv:sha256


$ sudo mount -a
$ sudo cryptdisks_start cryptswap1
 * Starting crypto disk... * cryptswap1 (starting)..
Attaching loopback device failed (loop device with autoclear flag is required).
device-mapper: rename ioctl failed: No such device or address
Command failed
 * cryptswap1 (started)... [ OK ]

$ sudo dmsetup status
udisks-luks-uuid-27bd7267-ab0b-48f4-8a56-67f8713b56ea-XYZ crypt

It is attempting to use the UUID of /dev/sda5, the external USB drive partition rather than /dev/sdb5: LABEL=".." UUID="8ed19201-fabf-4364-a507-XYZ" TYPE="ext4" - the partition that I booted into.

I'll reboot without the external USB drive connected.

NoOp (glgxg) wrote :

Put crypttab back to original:
~$ cat /etc/crypttab
cryptswap1 /dev/sda7 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
# cryptswap1 UUID= /dev/urandom swap,cipher=aes-cbc-essiv:sha256

Booted without the external USB drive connected. I now have cryptswap:
$ free
             total used free shared buffers cached
Mem: 3012820 1104584 1908236 0 102960 597320
-/+ buffers/cache: 404304 2608516
Swap: 5829984 0 5829984
$ sudo blkid
/dev/sda1: LABEL="SYSTEM" UUID="C2E04BE0xyz" TYPE="ntfs"
/dev/sda2: LABEL="Win7" UUID="32B682AExyz" TYPE="ntfs"
/dev/sda4: LABEL="RECOVERY" UUID="120C19Fxyz" TYPE="ntfs"
/dev/sda5: LABEL=".." UUID="8ed19201-fabf-4364-a507-xyz" TYPE="ext4"
/dev/sda6: LABEL="." UUID="6C94DF5A9xyz" TYPE="ntfs"
/dev/mapper/cryptswap1: UUID="aa98592b-39c3-42f3-82f0-858f1616ec97" TYPE="swap"

Notice that the drives are now /dev/sda# instead of /dev/sdb#. If I now plugin the USB drive & mount, the partitions are mounted as /dev/sdb#.

$ sudo dmsetup status
cryptswap1: 0 11659977 crypt

Cruiz (cruiz) wrote :

I have the same problem with Kubuntu 14.04

aslam karachiwala (akwala) wrote :
Download full text (3.8 KiB)

I discovered this issue with Kubuntu 14.04 which I installed from scratch using a CD/DVD. During installation I selected full-disk encryption as well as an encrypted home directory -- my understanding is that home directory encryption also encrypts the swap space.

Below is the current state of the drives. Note that:
1. 'blkid' does not list swap, and /proc/swaps is empty; however,
2. /etc/crypttab has entries that apparentlly correspond to the encrypted disk as well as the swap, as does /etc/fstab; but
3. 'swapon' does not like the swap drive/s.

I only have a single physical disk (plus the optical drive).

$ sudo blkid
/dev/sda1: UUID="f8ac0867-47e7-4c5c-8988-ab680388df78" TYPE="ext2"
/dev/sda5: UUID="2fb151ab-a2e3-4007-9cff-a61034e7a0c7" TYPE="crypto_LUKS"
/dev/mapper/sda5_crypt: UUID="8tXqxi-M5bU-r75F-4VPY-ur6s-60P6-3qK3uV" TYPE="LVM2_member"
/dev/mapper/kubuntu--vg-root: UUID="67d318ec-2121-4da9-a705-7258033d64b3" TYPE="ext4"

$ sudo fdisk -l

Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00037417

   Device Boot Start End Blocks Id System
/dev/sda1 * 2048 499711 248832 83 Linux
/dev/sda2 501758 625141759 312320001 5 Extended
/dev/sda5 501760 625141759 312320000 83 Linux

Disk /dev/mapper/sda5_crypt: 319.8 GB, 319813582848 bytes
255 heads, 63 sectors/track, 38881 cylinders, total 624635904 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/sda5_crypt doesn't contain a valid partition table

Disk /dev/mapper/kubuntu--vg-root: 313.4 GB, 313377423360 bytes
255 heads, 63 sectors/track, 38099 cylinders, total 612065280 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/kubuntu--vg-root doesn't contain a valid partition table

Disk /dev/mapper/kubuntu--vg-swap_1: 6417 MB, 6417285120 bytes
255 heads, 63 sectors/track, 780 cylinders, total 12533760 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/kubuntu--vg-swap_1 doesn't contain a valid partition table

# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/kubuntu--vg-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation


José Lou Chang (obake) wrote :

This bug affects all derivatives of Ubuntu 14.04.


Albert Pool (albertpool) wrote :

At https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1310058/comments/3 is a possible fix for non-working UUID's in crypttab.

aslam karachiwala (akwala) wrote :

This sounds like a Known Issue in the ReleaseNotes of Ubuntu 14.04:

When using installer to upgrade or reinstall an existing installation with encrypted swap, the installer may fail to reuse the partition. A warning will be shown, however the installation can be completed. The installed system will not have swap activated and users are advised to recreate swap on their systems. Please see advice about adding and activating swap at: https://help.ubuntu.com/community/SwapFaq (Bug #1066342)

isync (o-zucker) wrote :

I've got a clean install of Ubuntu 14.04, amd64 here and the same issue came up - no swap being mounted although the boot drive (an SSD) has tree partitions (all created during install): the main partition /dev/sda1 and two smaller ones /dev/sda3, /dev/sda5 , one of the smaller ones /dev/sda5 being identified as swap space.

UUIDs in crypttab and fstab (the commented out one) and the other one don't match.

Fix was:
Use "drive name" instead of UUID in crpyttab.
Replaced UUID in crpyttab with /dev/sda5 and after a reboot, swap was there. So the issue seems to be that the UUID of the swap is being overwritten each time on boot and changes (there's a fix for that, with offset=0, somewhere in bugs here).

For me it happened with the Ubuntu 14.04 amd64 installer. Having «/home» and SWAP on separated partitions, and trying to encrypt both of them. Bug prevents SWAP partition to be encrypted and mounted.
Meanwhile, I'm still using Precise due to this installation bug; so that's why I'd like to know if this bug will be adressed for the forthcoming Ubuntu 14.04.1 release, or not?

It wasn't at all.
So, I made it work by installing 12.04 and then inmediately upgrading to 14.04
Every other way to get SWAP properly encrypted and stable failed for me.

dino99 (9d9) on 2014-08-16
tags: added: utopic
dino99 (9d9) wrote :

Have met the same issue with a fresh utopic amd64 install: ext4, 'private' home folder chosen at installation and shared/non-encrypted ext4 /swap partition.

- /swap not mounted (was seen as 'commented' into fstab; wonder if ubiquity have to be blamed there ?)
- sudo ecryptsfs-setup-swap also fails: it force the desired /swap entry to be mommented into fstab, and then stop the process.

This appear to be seriously broken, and looks like no one care about the ecryptfs bugs, sadly. (Hopes i'm wrong about that !!!)

Just faced it here today. I have 8 Gb of RAM and was not using swap for weeks, untill today when I asked how much RAM was used, so I noticed that the swap was off.

I changed crypttab to use the device and not the UUID and seems that worked.

Similar here on Mint 17.

I manually setup ecryptfs and used ecryptfs-setup-swap to encrypt the swap parition. However, my swap partition lost its UUID thous rendering the UUID entry in /etc/crypttab useless. Changing the entry to /dev/sda2 solved it.

Bruno Nova (brunonova) wrote :

I tested ecryptfs-setup-swap in Debian sid and, guess what: it worked!
When running that command, swapon gave an error but, after reboot, the encrypted swap was working.
So, the bug is in Ubuntu!

In Debian, /etc/crypttab contains /dev/sdxX instead of the UUID.

And funny thing: ecryptfs-utils version in Debian sid is 103-3, while in Ubuntu Trusty it's 104-0ubuntu1 (the package is not being imported from Debian?).

tags: added: trusty
Bruno Nova (brunonova) wrote :

I edited /usr/bin/ecryptfs-setup-swap and replaced the line:
   echo "cryptswap$i UUID=$uuid /dev/urandom swap,cipher=aes-cbc-essiv:sha256" >> /etc/crypttab
    echo "cryptswap$i $swap /dev/urandom swap,cipher=aes-cbc-essiv:sha256" >> /etc/crypttab

Then I ran (in Virtualbox) ecryptfs-setup-swap, then rebooted.
Sometimes the encrypted swap was successfully mounted.
Other times a message appeared during boot complaining that the cryptswap1 was not ready yet (or something), and the swap was not mounted. In that case, running "sudo cryptdisks_stop" and "sudo cryptdisks_start" would mount the swap.
Interestingly, the failures happened randomly in my Xubuntu 14.04 virtual machine, but never happened in my Kubuntu 14.04 virtual machine (didn't test in the actual Ubuntu).

So, it's something!
Note: without editing the file, "sudo cryptdisks_start" would throw an error, so the edit is necessary.

Bruno Nova (brunonova) wrote :

Tested a few more times, and the encrypted swap mount failures started appearing in my Kubuntu virtual machine. Oh well.

Bruno Nova (brunonova) wrote :

Thank you tnrng! I'm not currently using encrypted swap, but your workaround may be useful for other people.
I was going to investigate this further, but then I saw the other bug reports (like the one you linked).

For others seeing this issue on 14.04, see: https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1310058

45 comments hidden view all 113 comments

It's a long-standing well-known limitation:

/* Options Debian's crypttab knows we don't:


Some of those will probably never be implemented (noearly, keyscript, loud, ...), but offset certainly should.

44 comments hidden view all 113 comments
Jarno Suni (jarnos) wrote :

Could someone link this bug to the release notes?

Jarno Suni (jarnos) wrote :

As for the fix in
adding noauto anywhere and doing step 3 was not necessary.
I did install using LVM, not encrypting the whole disk, but encrypting home (and consequently encrypting swap), so I used /dev/mapper/mythbuntu--vg-swap_1 instead of /dev/sdaX in step 2. (It is shown in the output of "sudo fdisk -l".)

I've checked this bug started happening first on Ubuntu 13.04. It's been three editions now and it's not corrected yet. Will it be when 16.04 LTS version comes out?

sudodus (nio-wiklund) wrote :

I found what I think is this bug in a system installed from the Lubuntu Vivid alternate 32-bit daily iso file.


cryptswap is there when I reboot from the installer, but the second time I reboot it is gone.
cryptswap1 UUID=b66610ce-376c-42cf-8d02-8983f2a40d70 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

/dev/sda1: UUID="63725e48-ebeb-4c33-a023-d34191a6b2bd" TYPE="ext4" PARTUUID="ef7fb1de-01"
/dev/sda5: PARTUUID="ef7fb1de-05"

modified /etc/crypttab:
# <target name> <source device> <key file> <options>
cryptswap1 /dev/sda5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
Hint to the developers: It works with the modified crypttab :-)

So it seems that the device information is wrong in /etc/crypttab. Maybe it would be better to have to PARTUUID than the device /dev/sda5.

John Hupp (john.hupp) wrote :

Hi, Nio.

I think this bug is related to this one: https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1310058

I found that the workaround from the original 1310058 report (to fix ecryptfs-setup-swap) did the job for me.

But indeed, that would also point the way to the permanent fix!

sudodus (nio-wiklund) wrote :

Thanks for the tip, John :-)

Do you mean post #41 by syscon-hh (syscon-kono) written on 2015-02-04?

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:

tags: added: iso-testing
1 comments hidden view all 113 comments
John Hupp (john.hupp) wrote :

Nio: No, in a very recent case installing 14.04.02 i386, I successfully used the installer script patch from 1310058 Comment #3:

Edit the installer script /usr/bin/ecryptfs-setup-swap and add:

# Add crypttab entry

echo "cryptswap$i UUID=$uuid /dev/urandom swap,offset=8,cipher=aes-cbc-essiv:sha256" >> /etc/crypttab

sudodus (nio-wiklund) wrote :

Thanks, it works for me too in Lubuntu Vivid i386 with that added option


to create cryptswap that survives rebooting :-)

Martin Pitt (pitti) on 2015-03-09
Changed in ecryptfs-utils (Ubuntu):
milestone: none → ubuntu-15.03
Martin Pitt (pitti) wrote :

This is a lot worse now that systemd actually complains about the missing device and blocks the boot on it for 90s. I just discussed that with Dustin. Summary:

 - This was introduced in https://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/revision/776 but can't work (see https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryption).
 - Fix for future installs: Add offset=1024, to maintain the swap signature and UUID on the underlying hardware device
 - While we are at it: change the obsolete cipher setting to the current cryptsetup default "cipher=aes-xts-plain64"

For upgrades:
Add postinst code to clean up broken installs: find the missing swap partitions and comment them out in crypttab and fstab. We also discussed a possible salvation of swap partitions, running mkswap -U <expected UUID> on them, but IMHO it is unexpected and intrusive to suddenly get a swap partition after having an existing installations for years without one.

Changed in ecryptfs-utils (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
Martin Pitt (pitti) wrote :

This script finds and comments out cryptswap devices which are broken in this way. It's very defensive and focussed, so I believe this is reasonably safe to put into ecryptfs-utils' postinst script.

Martin Pitt (pitti) on 2015-03-09
description: updated
Martin Pitt (pitti) on 2015-03-09
Changed in ecryptfs-utils (Ubuntu Vivid):
status: Triaged → In Progress
Changed in ecryptfs:
status: New → In Progress
importance: Undecided → High
assignee: nobody → Dustin Kirkland  (kirkland)
Changed in ecryptfs:
status: In Progress → Fix Released
Changed in ecryptfs-utils (Ubuntu Vivid):
status: In Progress → Fix Committed
Changed in ecryptfs-utils (Ubuntu Vivid):
status: Fix Committed → Fix Released
Martin Pitt (pitti) on 2015-03-31
Changed in ecryptfs-utils (Ubuntu Vivid):
status: Fix Released → Confirmed
milestone: ubuntu-15.03 → ubuntu-15.04
tags: added: rls-v-incoming vivid
Martin Pitt (pitti) on 2015-04-13
Changed in ubiquity (Ubuntu Vivid):
status: New → In Progress
importance: Undecided → High
assignee: nobody → Martin Pitt (pitti)
milestone: none → ubuntu-15.04
Changed in ecryptfs-utils (Ubuntu Vivid):
status: Confirmed → Fix Released
Martin Pitt (pitti) on 2015-04-14
Changed in ubiquity (Ubuntu Vivid):
assignee: Martin Pitt (pitti) → nobody
status: In Progress → Fix Committed
Changed in ubiquity (Ubuntu Vivid):
status: Fix Committed → Fix Released
Martin Pitt (pitti) on 2015-04-14
Changed in systemd (Ubuntu Vivid):
assignee: nobody → Martin Pitt (pitti)
tags: removed: rls-v-incoming
Martin Pitt (pitti) on 2015-04-16
Changed in systemd (Ubuntu Vivid):
status: New → In Progress
34 comments hidden view all 113 comments

Created attachment 115118
cryptsetup: Implement offset and skip options

Simple patch.

Created attachment 115119
reproducer/test script

This is the reproducer and test script which I used.

Changed in systemd (Ubuntu Vivid):
importance: Undecided → High

I think a failure to parse those parameters should be fatal. It's just to dangerous to continue.

Also "meatadata" in description :)

Martin Pitt (pitti) on 2015-04-16
Changed in systemd (Ubuntu Vivid):
milestone: none → ubuntu-15.04
status: In Progress → Fix Committed
Changed in systemd (Debian):
status: Unknown → Confirmed
Changed in systemd:
importance: Unknown → Medium
status: Unknown → Confirmed
1 comments hidden view all 113 comments

Created attachment 115126
cryptsetup: Implement offset and skip options

Indeed! Fixed both. I tested with "offset=x8" and it now correctly aborts and doesn't touch the device. offset=1024 and no offset still continue to work.

Thanks for the review!

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package systemd - 219-7ubuntu2

systemd (219-7ubuntu2) vivid; urgency=medium

  * cryptsetup: Implement offset and skip options. (Closes: #751707,
    LP: #953875)
 -- Martin Pitt <email address hidden> Thu, 16 Apr 2015 14:59:39 -0500

Changed in systemd (Ubuntu Vivid):
status: Fix Committed → Fix Released
1 comments hidden view all 113 comments

Hmm, please use parse_bytes() for parsing byte values.

(In reply to Lennart Poettering from comment #6)
> Hmm, please use parse_bytes() for parsing byte values.

Sorry, I meant parse_size() of course.

Also, please add the initialization of .offset and .skip into the declaration of the params variable, as initializer. i.e.:

struct crypt_params_plain params = {
        .offset = arg_offset,
        .skip = arg_skip,

Also, please document the new switches in crypttab(5).

Created attachment 115162
cryptsetup: Implement offset and skip options

parse_size() is not appropriate here, as the offset=/skip= argument is a plain natural number, and the unit is always "512 byte blocks". So allowing things like "3.3K" there would be confusing, wrong, imprecise, and incompatible with the cryptsetup project.

I added documentation, the initializer, and also incorporated warning that Zbigniew suggested on the ML.

OK, if this is not a bytes value, parse_size() is probably not a good idea. (that said, I think it's a pretty poor choice to expose this as 512byte block value...)

Anyway, looks good. Please push!

Changed in systemd (Debian):
status: Confirmed → Fix Released
Changed in systemd:
status: Confirmed → Fix Released
sudodus (nio-wiklund) wrote :

ISO testing result for Lubuntu Vivid


step 1 OK: cryptswap works when rebooting after installation.
step 2 OK: no long delay when rebooting again.
step 3 OK: cryptswap works when rebooting again. I provoked using swap, and it seems to work correctly.
step 4 OK: cryptswap works when rebooting again. I provoked using swap, and it seems to work correctly.

Encrypted home with cryptswap works again. Thank you Martin Pitt :-)

Barry Warsaw (barry) wrote :

So my multi-cycle-upgraded-currently-vivid machine had a cryptswap entry with an old device name instead of the UUID. As per earlier comment in this bug, I just changed the device name to the now-current one rather than mess around with UUIDs and it works fine. Probably *should* use a UUID, but this was a quick and easy fix.

Jason Gerard DeRose (jderose) wrote :

As far as I can tell, lp:1447282 is a different bug, but it would be helpful to have input from the other ecryptfs users who are following this bug:

Albert Pool (albertpool) wrote :

It is different I think, the bug to which we are replying at the moment pre-dates systemd in Ubuntu. Systemd was just an additional problem which appeared while fixing this bug.

Sergio Mena (sergio-mena) wrote :

I was in a situation similar to akwala's, post #13 (http://unix.stackexchange.com/questions/1367/how-to-test-swap-partition). In my case I use Mint 17 Rebecca (based on Trusty).

In this case, both "encrypt home" and "encrypt the full partition" have been selected during installation.

I believe that the need for an encrypted swap in this case is not that important if the system is to be used by a single user: the swap partition (in akwala's case, /dev/mapper/kubuntu--vg-swap_1) resides in an encrypted disk anyway.

Of course, one could choose to reinstall and select only "encrypt the full partition" and not "encrypt home". In my particular case, I am interested in also encrypting home because I use rsync to back up my (encrypted) home dir (i.e., /home/.ecryptfs/my_username/.Private) to an untrusted machine.

So, my fix consists in configuring my fresh Mint 17 installation to use /dev/mapper/mint--vg-swap_1 (which is encrypted) as a non-encrypted swap partition:

* Format the swap partition:
sudo mkswap /dev/mapper/mint--vg-swap_1

(for ubuntu, replace mint--vg-swap_1 by ubuntu--vg-swap_1, for other releases, run "sudo fdisk -l" and adapt the name accordingly)

* Edit /etc/fstab:
  - comment out the line starting with: /dev/mapper/cryptswap1
  - if not there, add a line for mounting mint--vg-swap_1 as a regular swap partition:
/dev/mapper/mint--vg-swap_1 none swap sw 0 0
(if needed, replace mint--vg-swap_1 as described above)

* Edit /etc/crypttab and comment out the line starting with: cryptswap1

* Reboot

* After reboot verify that the swap was mounted:

$ swapon -s
Filename Type Size Used Priority
/dev/mapper/mint--vg-swap_1 partition 4075516 0 -1

$ free
             total used free shared buffers cached
Mem: 4000156 1266520 2733636 15452 25604 524712
-/+ buffers/cache: 716204 3283952
Swap: 4075516 0 4075516

$ sudo swapoff /dev/mapper/mint--vg-swap_1

(no errors)

$ sudo swapon -a

(no errors)

Sergio Mena (sergio-mena) wrote :

Some important points to add to my previous post:

1) This worked for me. However there is NO GUARANTEE that it will work for you, hence, point 2)

2) If you don't have a fresh installation, BACK UP YOUR DATA before any attempt at playing with your partitions. I have a couple of "scars" that show I'm damn right :-)

3) Be particularly careful when you edit /etc/crypttab . Change ONLY the cryptswap1 line. Leave the line starting sd[XY]_crypt alone

Good luck!

Albert Pool (albertpool) wrote :

Can anybody mark this bug as affecting Trusty too? In Trusty, the offset in crypttab has not been fixed yet. In Vivid it has (along with a lot of systemd stuff, that Trusty does not require of course).

sudodus (nio-wiklund) wrote :

I'm testing Lubuntu Wily installed from the alternate 32-bit iso file, and see that there is a regression (or maybe a new bug). The test-case with encrypted disk and encrypted home with cryptswap does not work. There is swap which survives reboot, but no cryptswap.

There are two entries in fstab, and the cryptswap entry cannot be activated with 'sudo swapon -a'. It complains that /dev/mapper/cryptswap1 does not exist.

I will come back after testing how it works with only encrypted home with cryptswap.

sudodus (nio-wiklund) wrote :

Cryptswap works with only encrypted home with cryptswap.

Is it by intention, that there is regular swap in a system with both encrypted disk and encrypted home? In that case I think it is better to keep it like it was long ago and also in Vivid when it started to work again. Think of the case of two or more users of the computer: information can leak via swap between the users, if it is standard swap.

sudodus (nio-wiklund) wrote :

There was only a temporary glitch in yesterday's build. Cryptswap works again in today's daily build :-)

The Lubuntu test-case with encrypted disk and encrypted home with cryptswap works again.

This Bug still persists in 15.04 and I'm affected with this. Did the steps mentioned in the header. It helped but but cryptswap asks me for a password on startup.

Martin Pitt (pitti) wrote :

@Jochen: This bug is closed. If you are using LVM, then you are experiencing bug 1453738. Otherwise please file a new bug report. Thanks!

Albert Pool (albertpool) wrote :

@Martin Pitt: This bug has not been fixed on 14.04 LTS, only on later editions. I do not know how to add trusty as affected, can you do that?
We lost sight on trusty in this bug when it became apparent that vivid had an additional problem to fix, namely systemd.

Martin Pitt (pitti) wrote :

@Albert: trusty tasks added for ecryptfs and ubiquity. I'll upload ecryptfs for trusty together with the fix for bug 1453738.

Changed in ecryptfs-utils (Ubuntu Trusty):
status: New → Triaged
no longer affects: systemd (Ubuntu Trusty)
Changed in ubiquity (Ubuntu Trusty):
status: New → Triaged
importance: Undecided → High
Changed in ecryptfs-utils (Ubuntu Trusty):
importance: Undecided → High
Changed in ubiquity (Ubuntu Trusty):
milestone: none → ubuntu-14.04.3
Mathew Hodson (mhodson) on 2015-10-08
Changed in ecryptfs-utils (Ubuntu):
milestone: ubuntu-15.04 → none
Changed in systemd (Ubuntu):
milestone: ubuntu-15.04 → none
Changed in ubiquity (Ubuntu):
milestone: ubuntu-15.04 → none
Mathew Hodson (mhodson) on 2015-11-12
Changed in ubiquity (Ubuntu Trusty):
milestone: ubuntu-14.04.3 → ubuntu-14.04.4
Changed in ecryptfs-utils (Ubuntu Trusty):
milestone: none → ubuntu-14.04.4
Jason Gerard DeRose (jderose) wrote :

I get the impression this is known and expected, but this problem still exists in the latest 14.04.4 daily ISOs (which have proposed enabled).

CrazySky (makarovdenis11) wrote :

When will be fix on Ubuntu 14.04?

damien (gognoscranes) wrote :

Any news on 14.04 ?

sudodus (nio-wiklund) wrote :

Encrypted home and crypt-swap work in the new LTS release, 16.04. I have tested, and it seems reliable. I don't know about 14.04 LTS.

1 comments hidden view all 113 comments
Albert Pool (albertpool) wrote :

Yes, that is a possible fix for the issue, but the point is, the bug has been fixed on the newest releases but not on the 14.04 long term support edition. As damien asked, I have not seen any news on this recently.

Eric W. Scott (ewscott9) wrote :

(EDIT to 104, it should have been offset=1024, not offset=20)
Okay, here's what I do to fix the problem (for 14.04). I'll break it down into three steps.

1. Reformat the original swap partition on the system and make note of it's new uuid. You need to do this, because ubuntu wipes the uuid when it encrypts the partition on the first boot.

2. Now change /etc/crypttab to include an offset of 1024 so that cryptdisks doesn't wipe the uuid on the new swap partition.
Change from:
cryptswap1 UUID="old-uuid" /dev/urandom swap,cipher=aes-cbc-essiv:sha256
cryptswap1 UUID="new-uuid" /dev/urandom swap,cipher=aes-cbc-essiv:sha256,offset=1024

3. Now run the following commands to activate the encrypted swap partition:
   sudo cryptdisks_start cryptswap1
   sudo swapon -a

This should fix the issue, and the system should automatically have an active encrypted swap on each subsequent boot.

Eric W. Scott (ewscott9) wrote :

Yeah, I don't know why they haven't patched this bug. It's very unfortunate. Luckily, the work around isn't too much of a hassle.

D (360-dennis) wrote :

I had this error on 16.04 LTS as well. I had it on 2 systems, so this does not seem to be fixed yet.

userDepth (markonuvo) wrote :

Same here using MATE 16.04, I fixed ( At least I think did ) the UUID problem at /etc/crypttab and now I'm asked for the passphrase at boot. Boot and Shut down is still slow.

Robeen (robert-galambos) wrote :

Same problem here with Ubuntu 16.04.1 LTS

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial

$ cat /etc/crypttab
#<name> <device> <password> <options>
sda5_crypt UUID=84d61165-80eb-46cf-9d48-b0117c7a8a92 none luks,discard
sda6_crypt UUID=e335f91e-58bb-4a57-8e10-2854ff8358db none luks,swap,discard

$ cat /etc/fstab
UUID=a370331b-c037-40fa-8d6c-2445960d94e0 /boot ext4 defaults 0 2
/dev/mapper/sda5_crypt / ext4 errors=remount-ro 0 1
/dev/mapper/sda6_crypt none swap sw 0 0

Config was not changed since 14.04 LTS, and it seems to be fine, but during startup I get the same error after updating to 16.04:

systemd[1]: dev-disk-by\x2duuid-e335f91e\x2d58bb\x2d4a57\x2d8e10\x2d2854ff8358db.device: Job dev-disk-by\x2duuid-e335f91e\x2d58bb\x2d4a57\x2d8e10\x2d2854ff8358db.device/start timed out.
systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-e335f91e\x2d58bb\x2d4a57\x2d8e10\x2d2854ff8358db.device.
systemd[1]: Dependency failed for Cryptography Setup for sda6_crypt.
systemd[1]: Dependency failed for Encrypted Volumes.
systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'.
systemd[1]: Dependency failed for dev-mapper-sda6_crypt.device.
systemd[1]: Dependency failed for /dev/mapper/sda6_crypt.
systemd[1]: Dependency failed for Swap.
systemd[1]: swap.target: Job swap.target/start failed with result 'dependency'.
systemd[1]: dev-mapper-sda6_crypt.swap: Job dev-mapper-sda6_crypt.swap/start failed with result 'dependency'.
systemd[1]: dev-mapper-sda6_crypt.device: Job dev-mapper-sda6_crypt.device/start failed with result 'dependency'.
systemd[1]: systemd-cryptsetup@sda6_crypt.service: Job systemd-cryptsetup@sda6_crypt.service/start failed with result 'dependency'.
systemd[1]: dev-disk-by\x2duuid-e335f91e\x2d58bb\x2d4a57\x2d8e10\x2d2854ff8358db.device: Job dev-disk-by\x2duuid-e335f91e\x2d58bb\x2d4a57\x2d8e10\x2d2854ff8358db.device/start failed with result 'timeout'.

I did not tried the workaround yet, but anyway this is quite a big issue in my opinion...
It should be fixed soon in the LTS version...

Robeen (robert-galambos) on 2016-08-14
tags: added: mate xenial
getsnoopy (getsnoopy) wrote :

@akwala, I have the same setup (full disk + home folder encryption). I just ran a mkswap on the swap mapped device that fdisk reports providing the UUID that blkid gives, and it seemed to work:

~$ sudo blkid # Grab UUID from here (if not for the swap-mapped partition, then the root-mapped one)
~$ sudo fdisk -l # Grab device path from here
~$ sudo mkswap -U 7e44a598-e057-42ec-9d1d-f0b693467211 /dev/mapper/elementary--vg-swap_1

I then just edited the UUID in the /etc/crypttab file to match and ran swapon which worked (verified in System Monitor). After rebooting, however, it gave me a message about the swap partition not being ready yet, though it worked after waiting for a couple seconds until the device was ready. I didn't want to see the message, so I followed the instructions here (http://askubuntu.com/questions/341979/what-to-do-about-the-disk-drive-for-dev-mapper-cryptswap1-is-not-ready-yet-or) to add the noauto flags to the swap partition in the /etc/crypttab and /etc/fstab files, and then created a /etc/init/cryptswap1.conf file with the following:

start on started mountall
  /sbin/cryptdisks_start cryptswap1
  /sbin/swapon /dev/mapper/cryptswap1
end script

This got it working well for me.

I am running Ubuntu 14.04.5 LTS and the offset parameter to preserve the UUID simply does not work for me. A later version of Ubuntu on the same PC shows there is a PARTUUID for the encrypted swap partition, but this is not visible in 14.04. The UUID for the cryptswap partition is always lost after reboot of 14.04.

Reverting back to using a device ID in conjunction with the solution in Comment #22 works, but I would like to add an additional piece of helpful information. I have a multi-disk system and periodically the /dev/sd_ drive IDs re-order themselves. Normally, UUIDs would solve this problem, but we can't use a UUID in this instance. This post pointed me in the direction of a solution (https://gebloggendings.wordpress.com/2016/06/14/cryptsetup-etccrypttab-a-workaround-for-gpt-partuuid-support/). Turns out you can use the /dev/disk/by-id alias for the partition ID in /etc/crypttab, as these drive IDs are also unique, i.e. drive make, model & serial number.

Peter Schüller (schueller-p) wrote :

I ran into the same problem on "Ubuntu 18.04.2 LTS" but the only required thing to fix it was to run "sudo update-initramfs -u".

Displaying first 40 and last 40 comments. View all 113 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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