Ubiquity problem with encrypted home option: system hangs because of ecryptfs-setup-swap not working with swapfiles

I patched ecryptfs-setup-swap and now it works.
The first modification is to avoid to run udevadm on a file (you get a "device node not found" error, harmless but annoying)
The second modification is to put filename instead of UUID in /etc/crypttab if you have a swap file and not a swap partition.
The third modification is to actually restart cryptdisk, since "/etc/init.d/cryptdisks restart" does nothing (see http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/cryptsetup/vivid/view/head:/debian/cryptdisks.init ), the right command is "systemctl restart cryptsetup.target"

The attachment "ecryptfs-setup-swap_patch_to_work_with_swapfiles.diff" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Dimitri - Could you have a look at this? I believe you worked on the encrypted swap changes.

Maybe also Ubiquity needs to be patched, I am not sure since I did not have time to test it yet.

I did the following test to isolate the problems.

1) Fresh ubuntu 17.04 installation with no encrypted home (and no encrypted swap). /etc/crypttab is empty, and in /etc/fstab I have the following line:

/swapfile none swap sw 0 0

2) After successfully running ecryptfs-migrate-home, I run ecryptfs-setup-swap (the "original" version, not the one with the above patch) and I get:

INFO: Setting up swap: [/swapfile]
device node not found
WARNING: Commented out your unencrypted swap from /etc/fstab
swapon: cannot open /dev/mapper/cryptswap1: No such file or directory

Now in /etc/fstab I have:

#/swapfile none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw 0 0

and in /etc/crypttab I have:
cryptswap1 UUID=98a3bb25-2c4d-4897-974c-d5dfcc16be8f /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

If I run free, I see that I have no swap:
              total used free shared buff/cache available
Mem: 8084440 1421116 4575096 273228 2088228 6086972
Swap: 0 0 0

3) I reboot, and the system hangs a lot during boot. I see "a start job is running for dev-mapper-cryptswap1.device". After a couple of minutes, the boot process ends and I can login. If I run "systemctl status swapfile.swap" and "free" I see that (unencryted) swapfile has been activated anyway.
THIS IS DIFFERENT FROM WHAT I GOT WHEN DOING A FRESH UBUNTU 17.04 INSTALL WITH THE "ENCRYPT HOME FOLDER" OPTION SELECTED.
In that case, I got the system hanging during boot, too, but when I finally managed to login I got no swap at all ("systemctl status swapfile.swap" returned "failed to activate swap /swapfile").
Looking at ubiquity scripts, I see that if encrypted home option is selected, it runs also ecryptfs-setup-swap (so ubiquity is actually affected by the bug described above); but the fact that system fails also to activate unencrypted swap seems to suggest that Ubiquity may need to be patched too.

4)

I have run again the Ubuntu 17.04 installer on a virtual machine, with the "encrypted home folder" option.
I confirm that in such case even the unencrypted swap is not activated after boot.
In particular:

- at boot, the system hangs a couple of minutes telling that "a start job is running for dev-mapper-cryptswap1.device"

- when I finally manage to login, I see that no swap is activated:

alberto@alberto-VirtualBox:~$ free
              total used free shared buff/cache available
Mem: 2046200 1143772 67400 40392 835028 697220
Swap: 0 0 0

alberto@alberto-VirtualBox:~$ sudo systemctl status swapfile.swap

● swapfile.swap - /swapfile
   Loaded: loaded (/etc/fstab; generated; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2017-03-07 15:45:40 CET; 2min 51s ago
     What: /swapfile
     Docs: man:fstab(5)
           man:systemd-fstab-generator(8)

mar 07 15:45:40 alberto-VirtualBox systemd[1]: Activating swap /swapfile...
mar 07 15:45:40 alberto-VirtualBox swapon[346]: swapon: /swapfile: read swap header failed
mar 07 15:45:40 alberto-VirtualBox systemd[1]: swapfile.swap: Swap process exited, code=exited status=255
mar 07 15:45:40 alberto-VirtualBox systemd[1]: Failed to activate swap /swapfile.
mar 07 15:45:40 alberto-VirtualBox systemd[1]: swapfile.swap: Unit entered failed state.

alberto@alberto-VirtualBox:~$ sudo systemctl status cryptsetup.target

● cryptsetup.target - Encrypted Volumes
   Loaded: loaded (/lib/systemd/system/cryptsetup.target; static; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:systemd.special(7)

mar 07 15:47:09 alberto-VirtualBox systemd[1]: Dependency failed for Encrypted Volumes.
mar 07 15:47:09 alberto-VirtualBox systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'

but swap file has been created:

alberto@alberto-VirtualBox:~$ ls -l /swapfile
-rw------- 1 root root 394264576 mar 7 15:25 /swapfile

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

I just tried to install Ubuntu 17.04 from a daily build and ran into this too.

This looks pretty similar to bug #1668535. Should one of these be marked as a duplicate?

It seems that they are two different things.

This bug affects encrypting a swap *file* via ecryptfs (so affecting also ubiquity when using ecrypfs to encrypt home and swapfile), and the patch I made is for an ecryptfs-utils script (even if also ubiquity may need to be patched, too, see above my comment #6)

bug #1668535 instead concerns encryption of a swap *partition*, and the patch you find there is for systemd

Aha. Alberto, thanks for the helpful explanation!

Dimitri,

I have just found time to do another test: Ubiquity does need to be patched too.

Steps to reproduce the problem:
- boot an ubuntu gnome 17.04 beta 1 live cd
- before launching ubiquity, manually modify /usr/bin/ecryptfs-setup-swap like in the pacth I posted here
- launch ubiquity and select the encrytpted home folder option
- after installation, at boot the system hangs a couple of minutes because it cannot manage to activate swap
- log in, open a terminal and type "cat /etc/crypttab", you get:
cryptswap1 /target/swapfile /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

I guess that Ubiquity does not run ecryptfs-setup-swap as chroot as it should.
When dealing with swap partitions/UUIDs probably this is not a problem, but when using swap files it is.

Can confirm that Alberto Pianon's workaround of changing a line in /etc/crypttab fixes the problem (system no longer hangs on boot). Confirmed on Kubuntu and Ubuntu 17.04 on systems that had their home folders encrypted upon install.

I can confirm this bug on a fresh install of Ubuntu, Ubuntu MATE and Xubuntu.
The workaround of changing the crypttab to point to /target/swapfile fixes the problem.

I think this bug is quite severe, as new users may set the checkbox, then experience heavily delayed boot times.

I've been looking at this issue. The linked merge proposal for ecryptfs-utils almost gets us there. I've got a cleaned up version that I've been testing with. Unfortunately, I run into an issue in the systemd generated swap unit for the swapfile. It does something a little different for swap files than it does for swap partitions and my testing VM sometimes hangs (infinitely) during boot waiting on the swap unit to start. I still need to do more investigation to understand the problem and come up with the correct solution there.

Confirming that changing the cryptsetup line to:
cryptswap1 /swapfile /dev/urandom swap,offset=1024,cipher=aes-xts-plain64
solved the boot time.

The latest Artful daily (3108) also suffers from slow boot times after installation with an encrypted home folder. Please, if I can provide developers with any debug info about this, I'm happy to help - just tell me what to provide.

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

This bug was fixed in the package ecryptfs-utils - 111-0ubuntu5

---------------
ecryptfs-utils (111-0ubuntu5) artful; urgency=medium

  [ Alberto Pianon ]
  * debian/patches/swapfile-support.patch: Fix swapfile support. (LP: #1670336)
    - src/utils/ecryptfs-setup-swap: revise script for a world with swapfiles.
    - src/utils/ecryptfs-setup-swap: make sure we can restart ecryptfs with
      systemd.

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 25 Sep 2017 13:31:22 -0400

The fix works! :)

Problem still exists in17.10/Artful:

/etc/crypttab contains:

cryptswap1 /Target/swapfile /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

           ^^^^^^^

when it should be only:

cryptswap1 /swapfile /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

This is because Ubiquity has not been patched yet.
I had already pointed out the problem in this thread:

https://bugs.launchpad.net/ecryptfs/+bug/1670336/comments/12

But I do not know ubiquity well enough to patch it, it is better that the maintainer does it

Since ubiquity does not run ecryptfs-setup-swap as chroot, there is also another problem: unencrypted swapfile entry in /etc/fstab is not commented out as it should, so you get

/swapfile none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw 0 0

instead of

#/swapfile none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw 0 0

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