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

Bug Description

Description: Ubuntu Zesty Zapus (development branch)
Release: 17.04
ecryptfs-utils:
Installato: 111-0ubuntu4
Candidato: 111-0ubuntu4
Tabella versione:
*** 111-0ubuntu4 500
500 http://it.archive.ubuntu.com/ubuntu zesty/main amd64 Packages
100 /var/lib/dpkg/status

Ubuntu 17.04 uses swapfiles by default.

If you select the "encrypt home folder" option when creating the main user during Ubuntu 17.04 beta1 installation (which makes Ubiquity run also the ecryptfs-setup-swap command), after installation the system hangs a lot during boot, because it fails to activate swap (output of "systemctl status swapfile.swap" says "failed to activate swap /swapfile").

If you install Ubuntu 17.04 beta1 without selecting "encrypt home folder", and only after installation you run the ecryptfs-migrate-home utility, everything works. But as soon as you try to manually setup encrypyted swap (by running ecryptfs-setup-swap), you get the same problem as above.

In particular, you get the following error when running ecryptfs-setup-swap:

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

This is due to an ecryptfs-utils bug.
In particular, ecryptfs-setup-swap puts in /etc/crypttab a line like this:

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

(like there were a swap partition with UID=XXXXXXXX) while with a swapfile it should put the following line:

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

If you manually change that line and reboot, you get rid of the problem - before rebooting, check also that your /etc/fstab file ends with:
#/swapfile none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw 0 0

This bug indirectly affects also Ubiquity, because when you choose the "encrypt home folder" option during installation, ubiquity runs also ecryptfs-setup-swap; since Ubuntu 17.04 uses swapfiles by default, and ecryptfs-setup-swap does not work with swapfiles, after installation you get the system hanging a lot at boot (and when it finally starts it has no swap).

I tried both with Ubuntu Budgie and with Ubuntu Gnome, the problem is the same.

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: ecryptfs-utils 111-0ubuntu4
ProcVersionSignature: Ubuntu 4.10.0-9.11-generic 4.10.0
Uname: Linux 4.10.0-9-generic x86_64
ApportVersion: 2.20.4-0ubuntu2
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Mar 6 12:47:39 2017
EcryptfsInUse: Yes
InstallationDate: Installed on 2017年03月05日 (0 days ago)
InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Alpha amd64 (20170219)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=it_IT.UTF-8
SHELL=/bin/bash
SourcePackage: ecryptfs-utils
UpgradeStatus: No upgrade log present (probably fresh install)

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> 2017年9月25日 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.

Thank you for taking the time to submit this bug report. Ubiquity is now unmaintained, and is replaced by either the Ubuntu Desktop Inser or Calamares starting with Ubuntu 24.04 LTS. Therefore, this bug is being closed as Won't Fix. If you believe this was done in error, feel free to re-open the bug. If yave any general questions about Ubuntu, please open a topic on the Ubuntu Discourse instance: https://discourse.ubuntu.com/