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

Bug #1670336 reported by Alberto Pianon
172
This bug affects 37 people
Affects Status Importance Assigned to Milestone
eCryptfs
Triaged
High
Tyler Hicks
ecryptfs-utils (Ubuntu)
Fix Released
Critical
Mathieu Trudel-Lapierre
Zesty
Confirmed
Undecided
Unassigned
Artful
Fix Released
Critical
Mathieu Trudel-Lapierre
ubiquity (Ubuntu)
Confirmed
Undecided
Unassigned

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)

Related branches

description: updated
Revision history for this message
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"

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

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
Revision history for this message
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)
Revision history for this message
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.
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)

description: updated
Changed in ubiquity (Ubuntu Zesty):
status: New → Triaged
importance: Undecided → High
milestone: none → ubuntu-17.03
Revision history for this message
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)
           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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in ecryptfs-utils (Ubuntu):
status: New → Confirmed
Revision history for this message
Adam Dingle (adam-yorba) wrote :

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

Revision history for this message
Adam Dingle (adam-yorba) wrote :

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

Revision history for this message
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

Revision history for this message
Adam Dingle (adam-yorba) wrote :

Aha. Alberto, thanks for the helpful explanation!

Revision history for this message
Alberto Pianon (alberto-o) wrote :

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.

rahmadani (rahmadani)
Changed in ecryptfs-utils (Ubuntu Zesty):
assignee: nobody → rahmadani (rahmadani)
Jeremy Bícha (jbicha)
Changed in ecryptfs-utils (Ubuntu Zesty):
assignee: rahmadani (rahmadani) → nobody
Revision history for this message
Øystein Steffensen-Alværvik (oystein-alver) wrote :

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.

Revision history for this message
Lesik (lesik) wrote :

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.

Revision history for this message
Tyler Hicks (tyhicks) wrote :

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.

Changed in ecryptfs:
status: New → Triaged
importance: Undecided → High
assignee: nobody → Tyler Hicks (tyhicks)
Revision history for this message
Alex Moldovan (alexmoldovan) wrote :

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

Revision history for this message
Øystein Steffensen-Alværvik (oystein-alver) wrote :

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.

tags: added: artful
tags: added: rls-aa-incoming
Changed in ubiquity (Ubuntu):
milestone: ubuntu-17.03 → ubuntu-17.10
importance: High → Critical
affects: ecryptfs-utils (Ubuntu) → cryptsetup (Ubuntu)
Changed in ubiquity (Ubuntu Zesty):
milestone: ubuntu-17.03 → zesty-updates
Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1670336

tags: added: iso-testing
Changed in ubiquity (Ubuntu Zesty):
assignee: Dimitri John Ledkov (xnox) → nobody
Changed in ubiquity (Ubuntu):
assignee: Dimitri John Ledkov (xnox) → nobody
assignee: nobody → Iain Lane (laney)
Changed in ubiquity (Ubuntu):
assignee: Iain Lane (laney) → Mathieu Trudel-Lapierre (cyphermox)
Changed in ecryptfs-utils (Ubuntu):
status: New → In Progress
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
importance: Undecided → Critical
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in ecryptfs-utils (Ubuntu):
status: In Progress → Fix Released
Changed in ubiquity (Ubuntu Artful):
status: Triaged → Fix Released
no longer affects: ubiquity (Ubuntu)
no longer affects: cryptsetup (Ubuntu)
Changed in ubiquity (Ubuntu Zesty):
status: Triaged → Invalid
Changed in ubiquity (Ubuntu Artful):
status: Fix Released → Invalid
no longer affects: ubiquity (Ubuntu Zesty)
no longer affects: ubiquity (Ubuntu Artful)
no longer affects: cryptsetup (Ubuntu Artful)
no longer affects: cryptsetup (Ubuntu Zesty)
Revision history for this message
Øystein Steffensen-Alværvik (oystein-alver) wrote :

The fix works! :)

Revision history for this message
Chris Rainey (ckrzen) wrote :

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

Revision history for this message
Alberto Pianon (alberto-o) wrote :

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

Revision history for this message
Alberto Pianon (alberto-o) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in ecryptfs-utils (Ubuntu Zesty):
status: New → Confirmed
Changed in ubiquity (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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