Encrypted swap no longer mounted at bootup

[Alan Pope 🍺🐧🐱 🦄]

SUMMARY
=======
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.

UPGRADE FIX
===========
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".

ORIGINAL REPORT
===============

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)
ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=xterm
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: ecryptfs-utils
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

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

[Alan Pope 🍺🐧🐱 🦄 (popey)]

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)]

Hiya Popey,

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

[Launchpad Janitor (janitor)]

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

[Sean Watson (sean.watson)]

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)]

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?

[Maciel (macielcalebe)]

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.

[Dustin Kirkland  (kirkland)]

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

:-Dustin

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

[NoOp (glgxg)]

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

and

$ 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)]

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)]

I have the same problem with Kubuntu 14.04

[aslam karachiwala (akwala)]

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).

======blkid===============
$ 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"

=========fdisk===========
$ 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==========
# /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
UUID=f8ac0867-47e7-4c5c-8988-ab...

[José Lou Chang (obake)]

This bug affects all derivatives of Ubuntu 14.04.

http://ubuntuforums.org/showthread.php?t=2221067

[Albert Pool (albertpool)]

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)]

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

https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#Known_issues
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)]

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).

[José Lou Chang (obake)]

Work around: http://ubuntuforums.org/showthread.php?t=2224129&p=13023818#post13023818

[Star Man (starman-deactivatedaccount)]

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?

[Star Man (starman-deactivatedaccount)]

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)]

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.

Results:
- /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 !!!)

[Eustaquio Rangel (eustaquiorangel)]

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.

[Michael Gissing (michael.gissing)]

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)]

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?).

[Bruno Nova (brunonova)]

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
with:
    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)]

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

[> "Wetware Random Number Generator" (tnrng-purge-deactivatedaccount)]

Maybe my workaround can help you brunonova:

https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1310058/comments/22

[Bruno Nova (brunonova)]

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

[Vecu-bosseur (vecu-bosseur)]

Dear Developpers,

My /etc/crypttab contains:

cryptswap1 UUID=c836dd13-1b4e-4bfb-9be5-6e5d972aa75a /dev/urandom swap,offset=2048,cipher=aes-cbc-essiv:sha256

And my /etc/fstab contains:

/dev/mapper/cryptswap1 none swap sw 0 0

And this worked fine with cryptdisks_start however the option "offset" is not understood by systemd 215. I did change init system from sysvinit to systemd, and now, after 2 reboots, I don't have any swap and my device that had UUID c836dd13-1b4e-4bfb-9be5-6e5d972aa75a has seen its start erased, and thus its UUID itself, as if I had not mentioned an offset=>>0 in crypttab.

The use case for "offset=2048" is to be able to use a UUID to identify the partition I want to have encrypted swap on. Not using an offset=>>0 parameter would unconditionally erase the whole partition, including the portion where its UUID is stored. Using any other way to identify a partition can thus cause data loss if I reparttion my disk and forget to update /etc/crypttab.

Please make systemd understand the "offset=" paramater of /etc/crypttab.

Has this problem been addressed in a subsequent systemd version?

Note: related to debian bug #751707
( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751707 )

Thanks,
Vecu Bosseur

[Zbigniew Jędrzejewski-Szmek (zbyszek-in)]

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

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

    offset=
    skip=
    precheck=
    check=
    checkargs=
    noearly=
    loud=
    keyscript=
*/

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

[Jarno Suni (jarnos)]

Could someone link this bug to the release notes?

[Jarno Suni (jarnos)]

As for the fix in
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1310058/comments/22
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".)

[Star Man (starman-deactivatedaccount)]

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)]

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

vivid-alternate-i386.iso

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

blkid:
/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)]

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)]

Thanks for the tip, John :-)

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

[Ubuntu QA Website (ubuntuqa)]

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/953875

[John Hupp (john.hupp)]

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)]

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

offset=8

to create cryptswap that survives rebooting :-)

[Martin Pitt (pitti)]

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.

[Martin Pitt (pitti)]

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.

[sudodus (nio-wiklund)]

Hi Martin,

I'm glad that you are working to squash this bug :-)

If you need help to test different solutions, please post at the following thread in the Ubuntu Forums

'Ubuntu Development Version - LVM encrypted disk & encrypted home in Lubuntu Vivid complicated or buggy'

http://ubuntuforums.org/showthread.php?t=2266912

[Launchpad Janitor (janitor)]

This bug was fixed in the package ecryptfs-utils - 106-0ubuntu1

---------------
ecryptfs-utils (106-0ubuntu1) vivid; urgency=medium

  [ Dustin Kirkland and Martin Pitt ]
  * debian/ecryptfs-utils.postinst: LP: #953875
    - detect and clean up after nonexisting cryptswap devices

  [ Tyler Hicks ]
  * tests/userspace/Makefile.am: Fix the 'make check' failure present in the
    ecryptfs-utils-105 release tarball. The failure was due to the automake
    file not specifying that some data files should be distributed as part
    of the v1-to-v2-wrapped-passphrase test, causing the test to fail due to
    the missing files.

  [ Dustin Kirkland ]
  * scripts/release.sh:
    - ensure that we try a binary build as part of the release process
    - make sure we're in the original working directory when we release
    - remove the -x option, too noisy
  * vivid
  * vivid
  * vivid
 -- Dustin Kirkland <email address hidden> Wed, 11 Mar 2015 18:42:19 -0500

[sudodus (nio-wiklund)]

The following instructions from the release message *did not work for me* when testing Lubuntu Vivid. See also

http://ubuntuforums.org/showthread.php?t=2266912

Is this bugfix only avoiding 90 seconds waiting time when upgrading, or should it be possible to use 'Encrypted home' with cryptswap in new installations? (The option is still there in the installer.)

---
** Branch linked: lp:~ubuntu-branches/ubuntu/vivid/ecryptfs-utils/vivid-proposed

-- You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/953875

Title: Encrypted swap no longer mounted at bootup Status in eCryptfs: Fix Released

Status in ecryptfs-utils package in Ubuntu: Fix Committed

Status in ecryptfs-utils source package in Vivid: Fix Committed

Bug description: SUMMARY
=======
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.

UPGRADE FIX
===========
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".
---

[Martin Pitt (pitti)]

> or should it be possible to use 'Encrypted home' with cryptswap in new installations?

It should, if you use a very recent image with ecryptfs-utils 1.0.6.

[sudodus (nio-wiklund)]

I used the version that came with yesterday's iso file. I see now, that it is 1.0.4-0ubuntu1 while the newest version available via the repos is 1.0.6-0ubuntu1. I'll update to the new one and see if things improve.

[sudodus (nio-wiklund)]

I tested now with 1.0.6-0ubuntu1 (everything updated/dist-upgraded). It reboots with cryptswap the first time, but the second time it takes 90 seconds, and cryptswap is gone

[sudodus (nio-wiklund)]

I should say that things work with Lubuntu 14.04.1 LTS desktop i386 (corresponding to what I try here).

In Lubuntu 14.04.1 LTS it is even possible to install 'Encrypted home with cryptswap' inside 'Encrypted disk vid LVM' and cryptswap will survive several reboots.

[José Lou Chang (obake)]

I'm running Ubuntu 14.04 Gnome 64-bit.

The Swap became available after I applied the updates presented to me today. But upon restarting the computer it lost the Swap again.

Here is the upgrade log from /var/log/apt/history.log

Start-Date: 2015-03-12 11:14:51
Commandline: aptdaemon role='role-commit-packages' sender=':1.191'
Upgrade: oxideqt-codecs-extra:amd64 (1.4.3-0ubuntu0.14.04.1, 1.5.5-0ubuntu0.14.04.3), spideroak:amd64 (5.1.8, 5.1.10), google-chrome-stable:amd64 (41.0.2272.76-1, 41.0.2272.89-1), libecryptfs0:amd64 (104-0ubuntu1, 104-0ubuntu1.14.04.3), linux-image-extra-3.13.0-46-generic:amd64 (3.13.0-46.77, 3.13.0-46.79), linux-image-3.13.0-46-generic:amd64 (3.13.0-46.77, 3.13.0-46.79), linux-headers-3.13.0-46:amd64 (3.13.0-46.77, 3.13.0-46.79), linux-headers-3.13.0-46-generic:amd64 (3.13.0-46.77, 3.13.0-46.79), ecryptfs-utils:amd64 (104-0ubuntu1, 104-0ubuntu1.14.04.3), linux-libc-dev:amd64 (3.13.0-46.77, 3.13.0-46.79), opera-stable:amd64 (27.0.1689.76, 28.0.1750.40)
End-Date: 2015-03-12 11:17:27

-----------------------------------------------------------------------------------------------------

After you guys find a solution, could you PLEASE backport them to Ubuntu 14.04? Remember that 14.04 is an LTS and there are many of us who require an ecrypted Home and encrypted Swap.

Thank you.

[sudodus (nio-wiklund)]

@Linux Lover,

You can make it work with some tweaks in 14.04.1 LTS. See this link (post #52)

http://ubuntuforums.org/showthread.php?t=2266912&page=3&p=13244000#post13244000

But I'm also looking forward to a solution when it works without tweaks :-)

[frostschutz (frostschutz)]

What if the system were to use the unencrypted swap (since there's a valid header for it) and the encrypted swap (since an encrypted device with offset was created for it) at the same time? The two swaps would overlap and overwrite each others memory, and the system goes *ka-boom*.

Now, that's an unrealistic scenario because it's unlikely to ever happen, and there's even a check in the kernel that prevents overlapping devices from being accepted as valid swap devices. So an explicit 'swapon /dev/sda3' currently fails with an invalid device message.

Still, this seems a bit like a damocles sword to me.

As a lower risk, the system may end up using unencrypted swap since the header is there and looks valid.

Swap partitions also have a size recorded in the header; if it only serves as an UUID provider, maybe it should be set to the smallest possible size, so it won't overlap with the encrypted side of things and nothing terribly bad could happen even if both were somehow to be used at the same time.

The minimum size seems to be 40 so you could prepare the partition with (mkswap --uuid="$uuid" "$dev" 40) or something like that (assuming the unencrypted swap is not in use at this stage).

On a side note, the offset should probably be a multiple of MiB (2048), to retain MiB alignment on the partition/block layer which seems to be the standard nowadays (regardless of what the underlying filesystem/swap makes of it).

[Albert Pool (albertpool)]

swapon -a by default only enables swap partitions that are in fstab, and ecryptfs-setup-swap comments the old swap's line there, so the correct swap is mounted on boot. And with the encrypted swap as provided by ecryptfs-setup-swap, hibernate is not possible so you shouldn't mind overwriting data from a previous session.

[Martin Pitt (pitti)]

> What if the system were to use the unencrypted swap

That's actually a valid point -- systemd-gpt-auto-generator will see this on GPT systems and activate it, so we need to verify that it ignores this non-working swap partition header.

[sudodus (nio-wiklund)]

@ Martin Pitt,

When you test your tweaks, please reboot several times and check that the cryptswap survives!

And when it works for you, please tell us what steps are necessary to make it work (if it is still not working automatically after an installation of 'Encrypted home'. I promise that I will test it, and I think I can make some other people test it too (in other computers).

[frostschutz (frostschutz)]

> swapon -a by default

I'm not worried about default behaviour, just wondering what can go wrong long term.

How about putting a keyless LUKS header on it. You can't do anything with it (as the manpage states, "Removing the last passphrase makes the LUKS container permanently inaccessible."). But it provides a UUID and it makes the device look like it's supposed to be encrypted, which it is.

    echo swap | cryptsetup --batch-mode --iter-time=1 --uuid="$uuid" luksFormat "$dev"
    echo swap | cryptsetup --batch-mode luksKillSlot "$dev" 0

And then forget & ignore this header (only the first 4K need to be left intact) and use plain cryptsetup with offset as it were.

I'm not sure what various mount helpers would make of such a "LUKS" partition though. Ideally with the crypt mapping in place they should recognize it as already open.

But maybe I'm just overthinking things. Sorry for butting in. :)

[sudodus (nio-wiklund)]

ISO-tested Lubuntu Vivid desktop i386, the current daily build version dated

ecryptfs-setup-swap is updated with the offset.

I ran it, and cryptswap worked again :-) but only after one reboot :-( After the next reboot it was gone again, and login was slow.

Please compare with Lubuntu 14.04.1 LTS desktop i386, where cryptswap survives, and try to figure out what has changed in the code, what can cause the failure in later versions (e.g. 14.04.2 and Vivid). See the testing 'recipe' in this link

http://ubuntuforums.org/showthread.php?t=2266912&page=3&p=13244000#post13244000

[sudodus (nio-wiklund)]

Added to the previous post: ISO-tested Lubuntu Vivid desktop i386, the current daily build version dated 2015-03-15

[sudodus (nio-wiklund)]

Another alternative is not using ecryptfs-setup-swap, but using a script with the following content
-----
#!/bin/bash

swpdev=$(grep '# swap was on' /etc/fstab|cut -d ' ' -f 5)
uuid=$(cut -d ' ' -f 2 /etc/crypttab |cut -d = -f 2)
sudo mkswap -U "$uuid" "$swpdev"
sudo blkid -c /dev/null
sudo swapon -a
sudo swapon -s
-----
This way I have to wait for a loooooooooooooooong time (90 seconds), but after that I can re-create cryptswap with the script in Lubuntu Vivid i386 daily build (installed with the desktop installer). This cryptswap works only once, and must be re-created after reboot.

This is inconvenient, but indicates what can be done.

1. If the long waiting time can be avoided, things would improve.
2. If the actions of the script can be run automatically (maybe improved to be more robust), things would be even better.

[sudodus (nio-wiklund)]

*affects Xubuntu*

This bug does not only affect Lubuntu but also Xubuntu. There is no cryptswap, no swap at all. See this link to the Ubuntu Forums thread

LVM encrypted disk & encrypted home in Lubuntu Vivid complicated or buggy posts # 58, 59, 60.

http://ubuntuforums.org/showthread.php?t=2266912&page=3&p=13246722#post13246722

[gravy45 (gravy45)]

I commented out cryptswap1 in crypttab and the problem corrected itself. I am running ecryptfs-utils 106-0ubuntu1 in Ubuntu MATE 15.04 Beta 2 released what yesterday, and it doesn't appear to be cleaning up after cryptswap.

[sudodus (nio-wiklund)]

Are you running without swap or with unencrypted swap? (Unencrypted swap can be a security hole.)

[Martin Wimpress  (flexiondotorg)]

I've noticed that Ubuntu 15.04 and Ubuntu MATE 15.04 experienced significant delay when booting if encrypted home directory has been selected during install. As requested by Martin Pitt, here is the additional information.

    sudo fdisk -l

Disk /dev/sda: 16 GiB, 17179869184 bytes, 33554432 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
Disklabel type: dos
Disk identifier: 0x829eccc4

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 31457279 31455232 15G 83 Linux
/dev/sda2 31459326 33552383 2093058 1022M 5 Extended
/dev/sda5 31459328 33552383 2093056 1022M 82 Linux swap / Solaris

    sudo blkid

/dev/sda1: UUID="6febe79a-7116-464a-832b-7959cb237775" TYPE="ext4" PARTUUID="829eccc4-01"
/dev/sda5: PARTUUID="829eccc4-05"

    cat /etc/crypttab

cryptswap1 UUID=d57ffbf4-27ba-42f6-9f16-c40786779a46 /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

    cat /etc/fstab

# /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>
# / was on /dev/sda1 during installation
UUID=6febe79a-7116-464a-832b-7959cb237775 / ext4 errors=remount-ro 0 1
# swap was on /dev/sda5 during installation
#UUID=d57ffbf4-27ba-42f6-9f16-c40786779a46 none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw 0 0

[Martin Wimpress  (flexiondotorg)]

Here is the output of `grep systemd /var/log/syslog`

Mar 31 11:49:53 martin-VirtualBox systemd-modules-load[230]: Inserted module 'lp'
Mar 31 11:49:53 martin-VirtualBox systemd-modules-load[230]: Inserted module 'ppdev'
Mar 31 11:49:53 martin-VirtualBox systemd-modules-load[230]: Inserted module 'parport_pc'
Mar 31 11:49:53 martin-VirtualBox systemd-modules-load[230]: Module 'fuse' is builtin
Mar 31 11:49:53 martin-VirtualBox systemd[1]: Started Load Kernel Modules.
Mar 31 11:49:53 martin-VirtualBox systemd[1]: Starting Apply Kernel Variables...
Mar 31 11:49:53 martin-VirtualBox systemd[1]: Mounted Configuration File System.
Mar 31 11:49:53 martin-VirtualBox systemd[1]: Mounting FUSE Control File System...
Mar 31 11:49:53 martin-VirtualBox systemd[1]: Started File System Check Daemon to report status.
Mar 31 11:49:53 martin-VirtualBox systemd[1]: Starting File System Check Daemon to report status...
Mar 31 11:49:53 martin-VirtualBox systemd[1]: Starting udev Wait for Complete Device Initialization...
Mar 31 11:49:53 martin-VirtualBox kernel: [ 0.877201] random: systemd-udevd urandom read with 2 bits of entropy available
Mar 31 11:49:53 martin-VirtualBox kernel: [ 5.248622] systemd[1]: Inserted module 'autofs4'
Mar 31 11:49:53 martin-VirtualBox kernel: [ 5.263893] systemd[1]: systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN)
Mar 31 11:49:53 martin-VirtualBox kernel: [ 5.263950] systemd[1]: Detected virtualization oracle.
Mar 31 11:49:53 martin-VirtualBox kernel: [ 5.263959] systemd[1]: Detected architecture x86-64.
Mar 31 11:49:53 martin-VirtualBox kernel: [ 5.266652] systemd[1]: Set hostname to <martin-VirtualBox>.
Mar 31 11:49:53 martin-VirtualBox kernel: [ 5.266906] systemd[1]: Initializing machine ID from random generator.
Mar 31 11:49:53 martin-VirtualBox kernel: [ 5.266967] systemd[1]: Installed transient /etc/machine-id file.
Mar 31 11:49:53 martin-VirtualBox kernel: [ 5.274049] systemd[1]: /etc/mtab is not a symlink or not pointing to /proc/self/mounts. This is not supported anymore. Please make sure to replace this file by a symlink to avoid incorrect or misleading mount(8) output.
Mar 31 11:49:53 martin-VirtualBox kernel: [ 5.664805] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
Mar 31 11:49:53 martin-VirtualBox kernel: [ 5.664830] systemd[1]: Starting Arbitrary Executable File Formats File System Automount Point.
Mar 31 11:49:53 martin-VirtualBox kernel: [ 5.665000] systemd[1]: Reached target Remote File Systems (Pre).
Mar 31 11:49:53 martin-VirtualBox kernel: [ 5.665017] systemd[1]: Starting Remote File Systems (Pre).
Mar 31 11:49:53 martin-VirtualBox kernel: [ 5.665093] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
Mar 31 11:49:53 martin-VirtualBox kernel: [ 5.665109] systemd[1]: Starting Forward Password Requests to Wall Directory Watch.
Mar 31 11:49:53 martin-VirtualBox kernel: [ 5.665294] systemd[1]: Created slice Root Slice.
Mar 31 11:49:53 martin-VirtualBox kernel: [ 5.665312] s...

[Albert Pool (albertpool)]

The bug already exists in Trusty, is there any chance of a fix in the LTS edition too?

[Charles Cruz (charlesmejiacruz)]

Doing a "sudo mkswap -U ..." seems to work after booting, but upon reboot, I need to do this again and again on Vivid. Any ideas? I'm thinking it has something to do with systemd?

[Martin Wimpress  (flexiondotorg)]

Just tried this:

    sudo swapon -a

And got this:

    swapon: stat failed /dev/mapper/cryptswap1: No such file or directory

[Martin Wimpress  (flexiondotorg)]

From '/var/log/syslog'.

Mar 31 12:46:37 martin-VirtualBox systemd[1]: Job dev-disk-by\x2duuid-d57ffbf4\x2d27ba\x2d42f6\x2d9f16\x2dc40786779a46.device/start timed out.
Mar 31 12:46:37 martin-VirtualBox systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-d57ffbf4\x2d27ba\x2d42f6\x2d9f16\x2dc40786779a46.device.
Mar 31 12:46:37 martin-VirtualBox systemd[1]: Dependency failed for Cryptography Setup for cryptswap1.
Mar 31 12:46:37 martin-VirtualBox systemd[1]: Dependency failed for dev-mapper-cryptswap1.device.
Mar 31 12:46:37 martin-VirtualBox systemd[1]: Dependency failed for /dev/mapper/cryptswap1.
Mar 31 12:46:37 martin-VirtualBox systemd[1]: Job dev-mapper-cryptswap1.swap/start failed with result 'dependency'.
Mar 31 12:46:37 martin-VirtualBox systemd[1]: Job dev-mapper-cryptswap1.device/start failed with result 'dependency'.
Mar 31 12:46:37 martin-VirtualBox systemd[1]: Job <email address hidden>/start failed with result 'dependency'.
Mar 31 12:46:37 martin-VirtualBox systemd[1]: Job dev-disk-by\x2duuid-d57ffbf4\x2d27ba\x2d42f6\x2d9f16\x2dc40786779a46.device/start failed with result 'timeout'.

[Martin Pitt (pitti)]

ecryptfs is actually fine now, but ubiquity has yet another scripts/user-setup-encrypted-swap wrapper which zeros out the complete original swap partition. It must not do that to retain the UUID.

[Martin Pitt (pitti)]

With the ubiquity fix we get further, but after the second boot something wipes the entire original swap partition again, not respecting the offset.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubiquity - 2.21.19

---------------
ubiquity (2.21.19) vivid; urgency=medium

  * user-setup-encrypted-swap: Don't zero out the first 4K of the swap
    partition so that the UUID gets retained. /etc/crypttab refers to the
    cipher device via UUID. See corresponding fix in ecryptfs-utils.
    (LP: #953875)
 -- Martin Pitt <email address hidden> Tue, 14 Apr 2015 10:55:05 -0500

[Martin Pitt (pitti)]

This definitively did work a few weeks ago when I tested this. I have a gut feeling the offset= bit isn't respected by the systemd integration of cryptsetup, so adding a systemd task for the time being.

[Martin Pitt (pitti)]

This shell script quickly reproduces the issue on a temporary scsi_debug disk. That's useful for a first round of verification and putting into an autopkgtest.

[Martin Pitt (pitti)]

Created attachment 115118
cryptsetup: Implement offset and skip options

Simple patch.

[Martin Pitt (pitti)]

Created attachment 115119
reproducer/test script

This is the reproducer and test script which I used.

[Zbigniew Jędrzejewski-Szmek (zbyszek-in)]

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)]

systemd fix sent upstream and committed to Debian experimental branch.

[Martin Pitt (pitti)]

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)]

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

[Lennart-poettering (lennart-poettering)]

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

[Lennart-poettering (lennart-poettering)]

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

Sorry, I meant parse_size() of course.

[Lennart-poettering (lennart-poettering)]

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).

[Martin Pitt (pitti)]

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.

[Lennart-poettering (lennart-poettering)]

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!

[Martin Pitt (pitti)]

http://cgit.freedesktop.org/systemd/systemd/commit/?id=4eac277367

Thanks for the review and suggestions!

[sudodus (nio-wiklund)]

ISO testing result for Lubuntu Vivid

http://iso.qa.ubuntu.com/qatracker/milestones/338/builds/92211/testcases/1439/results

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)]

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)]

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:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1447282

[Albert Pool (albertpool)]

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)]

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)]

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)]

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)]

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)]

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)]

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.

[Jochen Hörmann (jochen-hoermann)]

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)]

@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)]

@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)]

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

[Jason Gerard DeRose (jderose)]

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)]

When will be fix on Ubuntu 14.04?

[damien (gognoscranes)]

Any news on 14.04 ?

[sudodus (nio-wiklund)]

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.

[Albert Pool (albertpool)]

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)]

(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
To:
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)]

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)]

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 (binarydepth)]

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)]

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...

[getsnoopy (getsnoopy)]

@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
script
  /sbin/cryptdisks_start cryptswap1
  /sbin/swapon /dev/mapper/cryptswap1
end script

This got it working well for me.

[Curtis Schroeder (publicpanther)]

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)]

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".