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

Bug #1670336 reported by Alberto Pianon on 2017-03-06
This bug affects 13 people
Affects Status Importance Assigned to Milestone
ecryptfs-utils (Ubuntu)
ubiquity (Ubuntu)
Dimitri John Ledkov
Dimitri John Ledkov

Bug Description

Description: Ubuntu Zesty Zapus (development branch)
Release: 17.04
  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)
 PATH=(custom, no user)
SourcePackage: ecryptfs-utils
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

description: updated
Alberto Pianon (alberto-o) wrote :

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

tags: added: patch
Brian Murray (brian-murray) wrote :

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

Changed in ubiquity (Ubuntu):
assignee: nobody → Dimitri John Ledkov (xnox)
Alberto Pianon (alberto-o) wrote :

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


description: updated
Changed in ubiquity (Ubuntu Zesty):
status: New → Triaged
importance: Undecided → High
milestone: none → ubuntu-17.03
Alberto Pianon (alberto-o) wrote :

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)

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

Launchpad Janitor (janitor) wrote :

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

Changed in ecryptfs-utils (Ubuntu):
status: New → Confirmed
Adam Dingle (adam-yorba) wrote :

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

Adam Dingle (adam-yorba) wrote :

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

Alberto Pianon (alberto-o) wrote :

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

Adam Dingle (adam-yorba) wrote :

Aha. Alberto, thanks for the helpful explanation!

Alberto Pianon (alberto-o) wrote :


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.

rahmadani (rahmadani) on 2017-03-31
Changed in ecryptfs-utils (Ubuntu Zesty):
assignee: nobody → rahmadani (rahmadani)
Jeremy Bicha (jbicha) on 2017-04-08
Changed in ecryptfs-utils (Ubuntu Zesty):
assignee: rahmadani (rahmadani) → nobody

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers