Does not use encrypted swap when using GPT partitioning + encrypted home directory (ecryptfs)

[Jason Gerard DeRose]

CVE Request: http://openwall.com/lists/oss-security/2016/07/13/2

I'm still sorting out the details and eliminating variables, but as far as I can tell:

Steps to reproduce
===============

1) Install Ubuntu using GPT partitioning for the OS drive[*]

2) Choose "require my password to login", and check "encrypt my home directory"

Expected behavior
===============

No special user interaction should be required to initialized the crytposwap other than normally logging in

Actual behavior
============

Prior to lightdm coming up, you will be prompted to enter your passphrase to unlock the cryptoswap, similar to how you would be prompted to unlock the OS drive when using full disk encryption (see attached photo).

When lightdm comes up, you have to enter your password/passphrase again to login.

Work-arounds
===========

1) This only seems to happen when using GTP partitioning, not MBR... so use MBR if you can

2) Even with GTP partitioning, booting with init=/sbin/upstart seems to reliably fix the problem, so it certainly seems systemd related

Notes
=====

* As far as I can tell, there isn't a way to force Ubiquity to create a GPT partition table when the OS drive is < 2TB, but it will automatically use GPT partitioning when the OS drive is >= 2TB. My particular test was done using the System76 imaging server, which by default uses GPT partitioning even when the OS drive is < 2TB.

SRU INFORMATION
================
Regression potential:
This is delicate as we need to fix existing installations with a post-install script. This needs to happen as defensively as possible, but errors in this can still potentially completely break your partition information. Apart from testing that in the above scenario the unencrypted swap partition is marked as "no-auto" and thus after a new boot you are actually using the cryptswap1 one, we also need to verify that it does not destroy working systems.

Test case:
(1) Install an EFI system with "encrypt my home directory" (You can do this in QEMU with -bios OVMF.fd); after booting the first time you will be asked to enter a passprase for the swap partition, just press enter. "sudo swapon -s" will say something like /dev/sda3, i. e. using unencrypted swap. After installing this update and rebooting, the bogus passphrase prompt on boot should be gone, and "sudo swapon -s" should say /dev/dm-0, i. e. using encrypted swap.

In all these other cases the update should not do anything and booting continues to work:
(2) In the above system, "sudo apt-get install --reinstall ecryptfs-utils" should not change partitions again, but say something like "is already marked as no-auto".
(3) Install an EFI system without home dir encryption
(4) Install an MBR system with home dir encryption
(5) Install an MBR system without home dir encryption

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: systemd 219-7ubuntu3
ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
Uname: Linux 3.19.0-15-generic x86_64
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Apr 22 11:40:29 2015
EcryptfsInUse: Yes
MachineType: System76, Inc. Kudu Professional
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic root=UUID=e6c5aea5-d57c-410d-abce-66e96175e946 ro quiet splash vt.handoff=7
SourcePackage: systemd
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/15/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1.03.03RS76
dmi.board.asset.tag: Tag 12345
dmi.board.name: Kudu Professional
dmi.board.vendor: System76, Inc.
dmi.board.version: kudp1
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 9
dmi.chassis.vendor: System76, Inc.
dmi.chassis.version: kudp1
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.03.03RS76:bd01/15/2014:svnSystem76,Inc.:pnKuduProfessional:pvrkudp1:rvnSystem76,Inc.:rnKuduProfessional:rvrkudp1:cvnSystem76,Inc.:ct9:cvrkudp1:
dmi.product.name: Kudu Professional
dmi.product.version: kudp1
dmi.sys.vendor: System76, Inc.

[Jason Gerard DeRose (jderose)]

Info from fstab, crypttab, and journalctl:

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

# /dev/sda2
UUID=e6c5aea5-d57c-410d-abce-66e96175e946 / ext4 noatime,errors=remount-ro 0 1

# /dev/sda3
#UUID=8fcddb3d-a96d-4230-9844-cf08107d73f0 none swap sw 0 0

$ cat /etc/crypttab
cryptswap1 UUID=8fcddb3d-a96d-4230-9844-cf08107d73f0 /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

$ journalctl | grep -i swap
Apr 22 11:34:38 jason-Kudu-Professional systemd[1]: Activating swap Swap Partition...
Apr 22 11:34:38 jason-Kudu-Professional systemd[1]: Activated swap Swap Partition.
Apr 22 11:34:38 jason-Kudu-Professional kernel: Adding 4194300k swap on /dev/sda3. Priority:-1 extents:1 across:4194300k SSFS
Apr 22 11:34:38 jason-Kudu-Professional systemd[1]: Starting Cryptography Setup for cryptswap1...
Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: <email address hidden>: main process exited, code=exited, status=1/FAILURE
Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: Failed to start Cryptography Setup for cryptswap1.
Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: Dependency failed for dev-mapper-cryptswap1.device.
Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: Dependency failed for /dev/mapper/cryptswap1.
Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: Dependency failed for Swap.
Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: Job swap.target/start failed with result 'dependency'.
Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: Job dev-mapper-cryptswap1.swap/start failed with result 'dependency'.
Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: Job dev-mapper-cryptswap1.device/start failed with result 'dependency'.
Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: Unit <email address hidden> entered failed state.
Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: <email address hidden> failed.
Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: Starting Cryptography Setup for cryptswap1...

[Jason Gerard DeRose (jderose)]

Oops, when I copy+pasted my fstab earlier, I accidentally left out the final line, but the cryptswap1 line is actually there.

This is from a different install, so the UUIDs are different. Also, I forgot that Martin Pitt asked me to include the output from blkid:

$ 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>
# /dev/sda2
UUID=fa390f66-d7ad-4ed2-903d-481e2b3c27f6 / ext4 noatime,errors=remount-ro 0 1
# /dev/sda3
#UUID=230f371f-75b2-4264-ab46-9ff792f692a2 none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw 0 0

$ cat /etc/crypttab
cryptswap1 UUID=230f371f-75b2-4264-ab46-9ff792f692a2 /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

$ sudo blkid /dev/sda1
/dev/sda1: PARTLABEL="primary" PARTUUID="8de16314-f8a2-44f5-8e30-926810f9fd45"
$ sudo blkid /dev/sda2
/dev/sda2: LABEL="Ubuntu" UUID="fa390f66-d7ad-4ed2-903d-481e2b3c27f6" TYPE="ext4" PARTLABEL="primary" PARTUUID="3424f5de-bef2-4c54-b0ca-21c4ef701d0c"
$ sudo blkid /dev/sda3
/dev/sda3: UUID="230f371f-75b2-4264-ab46-9ff792f692a2" TYPE="swap" PARTLABEL="primary" PARTUUID="b82baf7e-c2eb-4b42-aea6-145947e8ee0b"

[Martin Pitt (pitti)]

Thanks Jason. Just to make sure my suspicion is correct, can you please give me the output of "systemctl --all|grep swap" and give me all files that turn up in "find /run/systemd/generator* | grep swap"?

I figure the

Apr 22 11:34:38 jason-Kudu-Professional kernel: Adding 4194300k swap on /dev/sda3. Priority:-1 extents:1 across:4194300k SSFS

comes from systemd-gpt-generator that picks up the raw/bogus /dev/sda3 partition, and as it's slightly faster it's causing this:

Apr 22 11:38:31 username-Kudu-Professional systemd-cryptsetup[645]: Loading of cryptographic parameters failed: Invalid argument

which makes cryptsetup fail.

FTR, GPT will be used (by default) if you install on an EFI system.

[Jason Gerard DeRose (jderose)]

Martin,

Another interesting tidbit is that this pre-lightdm passphrase prompt isn't actually doing anything... you can enter a blank passphrase or the wrong passphrase, and it will still happily proceed to lightdm.

Here's the output you asked for:

$ systemctl --all | grep -i swap
  dev-mapper-cryptswap1.device loaded inactive dead start dev-mapper-cryptswap1.device
  <email address hidden> loaded activating start start Cryptography Setup for cryptswap1
  dev-disk-by\x2did-ata\x2dCrucial_CT120M500SSD3_14260C6F95F9\x2dpart3.swap loaded active active /dev/disk/by-id/ata-Crucial_CT120M500SSD3_14260C6F95F9-part3
  dev-disk-by\x2did-wwn\x2d0x10806682451855888394x\x2dpart3.swap loaded active active /dev/disk/by-id/wwn-0x10806682451855888394x-part3
  dev-disk-by\x2dpartlabel-primary.swap loaded active active /dev/disk/by-partlabel/primary
  dev-disk-by\x2dpartuuid-54ce1181\x2d8e2b\x2d456d\x2db679\x2d6a22d25fd361.swap loaded active active /dev/disk/by-partuuid/54ce1181-8e2b-456d-b679-6a22d25fd361
  dev-disk-by\x2duuid-92a5e233\x2dc249\x2d42df\x2d8425\x2d3d6e8ac3af41.swap loaded active active /dev/disk/by-uuid/92a5e233-c249-42df-8425-3d6e8ac3af41
  dev-mapper-cryptswap1.swap loaded inactive dead start /dev/mapper/cryptswap1
  dev-sda3.swap loaded active active Swap Partition
  swap.target loaded inactive dead Swap

$ find /run/systemd/generator* | grep -i swap
/run/systemd/generator/dev-mapper-cryptswap1.device.d
/run/systemd/generator/dev-mapper-cryptswap1.device.d/90-device-timeout.conf
/run/systemd/generator/dev-mapper-cryptswap1.device.requires
/run/systemd/generator<email address hidden>
/run<email address hidden>
/run/systemd/generator/dev-disk-by\x2duuid-92a5e233\x2dc249\x2d42df\x2d8425\<email address hidden>
/<email address hidden>
/run/systemd/generator/swap.target.requires
/run/systemd/generator/swap.target.requires/dev-mapper-cryptswap1.swap
/run/systemd/generator/dev-mapper-cryptswap1.swap
/run/systemd/generator.late/swap.target.wants
/run/systemd/generator.late/swap.target.wants/dev-sda3.swap
/run/systemd/generator.late/dev-sda3.swap

[Jason Gerard DeRose (jderose)]

One more interesting tidbit: it seems that when booting with systemd, it's never enabling encrypted swap, it's just enabling normal swap using the underlying physical swap partition.

After booting with systemd:

$ sudo swapon --summary
Filename Type Size Used Priority
/dev/sda3 partition 4194300 0 -1

After booting with Upstart on the same install:

$ sudo swapon --summary
Filename Type Size Used Priority
/dev/mapper/cryptswap1 partition 4193788 0 -1

[Martin Pitt (pitti)]

can you please give me the contents of /run/systemd/generator.late/dev-sda3.swap ?

> One more interesting tidbit: it seems that when booting with systemd, it's never enabling encrypted swap, it's just enabling normal swap using the underlying physical swap partition.

Yes, that's expected after the log above. upstart doesn't do auto-discovery of swap partitions, systemd-gpt-generator does. I figure /run/systemd/generator.late/dev-sda3.swap comes from s-gpt-generator.

[Jason Gerard DeRose (jderose)]

Yesterday I didn't have access to a UEFI system or a >2TiB drive to test with... but I just did a normal install on a UEFI system, and I'm experiencing this same bug.

As before, booting with init=/sbin/upstart fixes it.

I just wanted to rule out this being a problem introduced by the System76 imaging system :)

[Jason Gerard DeRose (jderose)]

I attached a tarball will everything from generator.late/, just in case any other files are useful.

[Jason Gerard DeRose (jderose)]

Also attached a tarball with everything from generator/

[Martin Pitt (pitti)]

Thanks Jason!

[Martin Pitt (pitti)]

So it is as I suspected:

 * ecryptfs-setup-swap creates cryptswap1 at 512KiB offset of the former real swap partition (vda3), and adds that to /etc/crypttab; as we need/want the UUID, we keep the original swap header
 * During boot, systemd-gpt-generator sees the apparent unencrypted swap partition on vda3 and creates a .swap unit for this. This doesn't happen on classic MBR partitions, as there are no partition type UUIDs and no auto-discovery
 * The "real" encrypted swap partition (cryptswap1) gets enabled later, and that fails with "busy" as the unencrypted partition is already active.

[Martin Pitt (pitti)]

Two ideas how to fix that:

 * ecryptfs-setup-swap should change the partition type UUID to not be "swap" any more so that we don't try and auto-activate it. This is my preferred solution if it works.
 * ecryptfs-setup-swap creates an override .swap unit which disables the auto-mounting. But as we would again have to refer to real device names, we lose the entire point of keeping the underlying unencrypted swap partition, i. e. so that we can refer to it by UUID.

[Martin Pitt (pitti)]

For w-series and upstream we need to fix this in ecryptfs-setup-swap directly -- either mark the partition as such, or better yet, stop having a swap partition in the first place. This has created an inordinate amount of pain and breakage so far :-(

[Martin Pitt (pitti)]

This is the debdiff I uploaded to the vivid-proposed review queue. WARNING: the code will make your eyes pop out :-(

I tested this under various scenarios to make sure it doesn't destroy anything unrelated, and it does fix this issue.

[Martin Pitt (pitti)]

For the record, this horrible echo | fstab construction is apparently the only thing (apart from dd) which can change GPT partition flags. I talked to upstream util-linux, and Karel will work on adding support for GPT to sfdisk, so that this will look less hideous.

[Jason Gerard DeRose (jderose)]

Martin,

I just built ecryptfs-utils with your patch, and it fixed the problem! I'll beat up on it more through the day, see if I come across any corner cases where there are still issues.

And you're right... that's some seriously scary looking shell scripting in there. But it works :D

Thanks!

[Martin Pitt (pitti)]

Fixed debdiff which drops the erroneous sudo (debugging leftover) and uses printf instead of /bin/echo.

[Jason Gerard DeRose (jderose)]

Martin,

I just built ecryptfs-utils with your updated patch, and it seem solid, no issues found. FYI, I tested in OEM mode where the customer chooses encrypted home directory during the first-run-user-config, as that's the scenario that's most important for System76.

Thanks!

[Chris J Arges (arges)]

Hello Jason, or anyone else affected,

Accepted ecryptfs-utils into vivid-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/ecryptfs-utils/107-0ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Jason Gerard DeRose (jderose)]

The ecryptfs-utils update itself seems fine. However, the systemd update in proposed seems to have problems when encrypted home directory is being used, whether or not you've installed the ecryptfs-utils update first (and even rebooted) prior to installing the other packages in proposed.

I need to experiment a bit more with this...

[Gaele Strootman (gaele)]

I just updated ecryptfs-utils to 107-0ubuntu1.1, without the other updates in proposed. This seems to be working fine.

[Jason Gerard DeRose (jderose)]

Some more details: I tested 3 scenarios, all starting with an OEM mode install. The first 2 worked fine, the 3rd seems to have some issues:

1) Install all current updates in proposed from the OEM account, then prepare for shipping to user, then create a user account with an encrypted home directory. No issues.

2) Prepare for shipping to user, then create a user account with an encrypted home directory, then install *only* ecryptfs-utils, libecryptfs0 from proposed. No issues.

3) Prepare for shipping to user, then create a user account with an encrypted home directory, then install *all* updates from proposed. The systemd update is prompts for the encrypted swap passphrase twice and results in a package error (an indicator pops up with the error), although after a reboot things seem to probably be fine.

I ran scenario (3) from a terminal, still need to see what happens when I run it from the update-manager. Also, if you don't enter your passphrase (or at least press enter, the passphrase seems to be ignored anyway), the prompt will hit a timeout and the update will fail. So my biggest concern in running this from the update manager, will try that now...

[Jason Gerard DeRose (jderose)]

Okay, if you apply all the updates currently in proposed using update-manger (when you have an encrypted home directory setup), update-manager will hang while configuring udev.

The only way to tell that's it's prompting for your cryptoswap passphrase (which gets ignored anyway) is to expand the update-manger details (see attached screenshot).

So in total there are still some issues with what's currently sitting in proposed. Whether or not this is enough of a problem to block these SRUs, I don't know... on the one hand, I'm keen to see the ecryptfs-utils SRU land as soon as possible. On the other hand, these updates currently need some hand-holding by the user (when encrypted home directory is being used anyway).

[Jason Gerard DeRose (jderose)]

I suppose one work-around is to just land the ecryptfs-utils SRU first, then wait on the systemd SRU for a few days to minimize the number of users effecting by updating both at the same time. Actually, I'll test that scenario now just to double check.

[Martin Pitt (pitti)]

Jason Gerard DeRose [2015-04-29 19:23 -0000]:
> I suppose one work-around is to just land the ecryptfs-utils SRU first,
> then wait on the systemd SRU for a few days to minimize the number of
> users effecting by updating both at the same time. Actually, I'll test
> that scenario now just to double check.

Yes, I agree. My concern is that this bug here will cause the udev
prompt for pretty much any package update (from -proposed or
-security) that runs the udev package trigger. So we should get
ecryptfs in ASAP, and postpone the others.

ubiquity can also install updates during installation, so that at
least some new installs will get the correct partitions
right away.

Thanks for your extensive tests!

Martin

[Jason Gerard DeRose (jderose)]

Okay, if you update ecryptfs-utils, libecryptfs0 first *and* reboot prior to installing the other updates currently in proposed, then there are no issues.

I'm removing the "verification-needed" tag as from the perspective of this ecryptfs-utils SRU itself, things are all good in my book. But folks should keep in mind the gotchas involved with the systemd SRU combined with encrypted home directory.

[Alistair Grant (akgrant0710)]

Just in case anyone else comes across this before the fix is released:

Booting without the normal splash screen, i.e. /etc/default/grub contains:

GRUB_CMDLINE_LINUX_DEFAULT=""

and not:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

can result in the boot hanging waiting for input without a prompt.

[Jason Gerard DeRose (jderose)]

@akgrant0710 - I haven't been able to reproduce your issues.

I started with an OEM mode install, installed all the updates currently in Vivid proposed, created a user account with encrypted home directory, confirmed that encrypted swap was working as expected.

Then I changed the /etc/default/grub line to:

GRUB_CMDLINE_LINUX_DEFAULT=""

And then ran `sudo update-grub`.

But for me, I wasn't prompted erroneously for the ecrypted swap passphrase, and the swap was correctly initialized, confirmed with:

$ swapon --summary

When you tested, did you have all the updates from proposed installed? The new ecryptfs-utils package hasn't yet hit Vivid updates.

[Jason Gerard DeRose (jderose)]

@akgrant0710 - oops, never mind, you were talking about the pre-fix scenario, sorry for the confusion :D

[Steve Langasek (vorlon)]

Martin, you've marked bug #1449555 as a duplicate of this bug, but this bug is assigned to ecryptfs-utils. The problem described in bug #1449555 does *not* require ecryptfs-utils to be installed in order to reproduce. All that's required is to configure a line in /etc/crypttab for /dev/urandom encryption - it doesn't even have to be enabled in /etc/fstab.

This is a bug in systemd's handling of /etc/crypttab lines with keyfile=/dev/urandom, and has *nothing* to do with ecryptfs-utils setup of partitions. I'm marking this bug as verification-failed.

[Martin Pitt (pitti)]

Steve, given that the original reporter here confirmed that the fix works, I'm marking this back as v-done. Bug 1449555 has a description which is exactly the same as here: "where the user selects to encrypt their home directory, they will get a password prompt during boot and at other times on the command-line requesting a password for cryptswap1.". This is due to the insufficient ecryptfs-setup-swap script, which is the bug here.

Can you please file a new bug about your specific setup? Thanks!

[Alistair Grant (akgrant0710)]

@jderose :-) Thanks for the follow-up.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ecryptfs-utils - 107-0ubuntu1.1

---------------
ecryptfs-utils (107-0ubuntu1.1) vivid; urgency=medium

  * Add setup-swap-mark-gpt-noauto.patch: In ecryptfs-setup-swap, mark the
    "fake" underlying unencrypted swap partition as no-auto Without that, the
    swap partition gets auto-activated under systemd as it cannot be told
    apart from a real unencrypted swap partition.
  * debian/ecryptfs-utils.postinst: Fix existing GPT installations with
    cryptswap1 and an offset= for the above issue. (LP: #1447282)

 -- Martin Pitt <email address hidden> Fri, 24 Apr 2015 12:15:12 +0100

[Scott Kitterman (kitterman)]

The verification of the Stable Release Update for ecryptfs-utils has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ecryptfs-utils - 107-0ubuntu1.1

---------------
ecryptfs-utils (107-0ubuntu1.1) vivid; urgency=medium

  * Add setup-swap-mark-gpt-noauto.patch: In ecryptfs-setup-swap, mark the
    "fake" underlying unencrypted swap partition as no-auto Without that, the
    swap partition gets auto-activated under systemd as it cannot be told
    apart from a real unencrypted swap partition.
  * debian/ecryptfs-utils.postinst: Fix existing GPT installations with
    cryptswap1 and an offset= for the above issue. (LP: #1447282)

 -- Martin Pitt <email address hidden> Fri, 24 Apr 2015 12:15:12 +0100

[JunYang Pink (jun-yang)]

Hey guys,

I'm still having trouble with this bug. Perhaps because I'm still fairly new (~1 year) to linux.

I first noticed the "please enter passphase" error after the initial install however, I didn't pay it any mind. Fast forward a few hours and I decided to run the system updater because I did my install of 'vivid' while offline. It was here when I ran into this cryptoswap1 error again (I got the same screen as Jason in post #24).

Thats when I found this thread. Since then I've tried two things, first was:
$apt-get install --only-upgrade ecryptfs-utils

Every thing seemed to load fine however, when I tried the system update it eventually did the same thing as above. Next after more digging I tired : $bzr branch lp:ubuntu/vivid/ecryptfs-utils. This time after it had finished I restarted my machine and was greeted with the same "please enter passphase" error. However, I was able to successfully run the system updater with the cryptoswap1 error.

Any clue on what steps I should take to get rid of this error when starting up my computer?

[JunYang Pink (jun-yang)]

One more thing.

After just now rebooting my system again I've come to realize that my "please enter passphase" message is slightly different from the one Jason pictured (IMG_7979_01.jpg) in post #1.

Jason's message says: 'please enter passphrase for disk primary(cryptswap1) on none!'

Mines on the other had says: 'please enter passphrase for disk ubuntu--vg-swap_1(cryptswap1) on none!'

I don't know if it matters much, just thought I should mention it. Again, any help will be appreciated as I'd like to go about setting up the rest of my environment.

[Jason Gerard DeRose (jderose)]

@jun-yang - I haven't been able to reproduce your issue. I tried:

1) OEM mode install on an Intel-GPU system
2) OEM mode install on an Nvidia-GPU system

In all cases, encrypted home directory seemed to work fine for me and I was never prompted for a passphrase to unlock the cryptoswap (note that I had installed all the updates prior to running "Prepare for shipping to user").

Is your 15.04 install completely up-to-date? Also, now that the ecryptfs-utils/libecryptfs1 update has landed in vivid-updates, you only need do to this to make sure you have a fully up-to-date system:

sudo apt-get update
sudo apt-get -y dist-upgrade
sudo reboot

Please let us know if you're still having issues after running the above 3 commands.

[JunYang Pink (jun-yang)]

Thanks for the help Jason but that didn't work either.

Upon reboot it still gave the 'please enter passphrase for disk ubuntu--vg-swap_1(cryptswap1) on none!' message.

Since this was a fresh install I don't have much on my computer yet so I wont mind redoing it. I want to try again using MBR instead of GPT. However, just wondering what your thoughts are on MBR vs GPT as far as security? From what I've read the main difference is that GPT is much newer. Anything else I should be concerned about before the switch?

Thanks again for the help, I truly appreciate it.

[Martin (w-martin-h)]

I have the same touble, fresh install of 15.04, encrypted home dir, and the message every time I reboot: "please enter passphrase for disk ubuntu--vg-swap_1(cryptswap1) on none!"

$ sudo apt-cache policy ecryptfs-utils
ecryptfs-utils:
  Installed: 107-0ubuntu1.1
  Candidate: 107-0ubuntu1.1
  Version table:
 *** 107-0ubuntu1.1 0
        500 http://archive.ubuntu.com/ubuntu/ vivid-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     107-0ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages

[JunYang Pink (jun-yang)]

@w-martin-h

Yeah, I get the same message as you after running that command.

Must admit, this bug is very frustrating for a newbie like me. I guess I should just get a good Linux book and dive in so things like this are more intuitive.

Until then I hope using MBR will work. I'll be back to let you guys know.

[Martin (w-martin-h)]

Oh no, stay away from the Linux books. You'll just get cranky.
I am quite new myself; roughly 15 years now.

I fixed it by removing the swap partition everywhere ... swapoff -a; cryptsetup remove everything that looks strange to you!

gut out: /etc/fstab

rm everything with crypt here /dev/mapper/

I think it maybe down to me fixing the partition table somewhat after wrestling with UEFI.

Anyway, what's important is that when it comes to Linux, less is more!

[Martin Pitt (pitti)]

JuanYang, Martin, etc.: Your situation seems different, as you use LVM. I don't know yet whether you also use GPT, but as it's a sufficiently different case, please file a new bug about this. Please include the following:

 - output of "sudo blkid"
 - attach /etc/fstab and /etc/crypttab
 - run "sudo journalctl -b > /tmp/journal.txt" and attach /tmp/journal.txt.

Thanks!

[Denny (denny-klessens)]

Martin: see Bug #1453738

[Launchpad Janitor (janitor)]

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

[Ralph (ralph-bariz)]

I didn't read the whole thing now, me it affected affected after I activated the swap (not mapper) entry in fstab. I've done because I thought, what the f***, I ran without swap all the time?

Then this entry appeared before lightdm and swapon --summary showed me /dev/sdXX. Disabling the classic swap line gave me a /dev/dm-0 device mapper reference... Jupiee problem solved.
I think cryptswap doesn't need a classic entry in fstab, but if there is one systemd gets confused, tries to access the cryptswap, asks for password, gets the wrong and activates classic swap... ouch

Best Regards

[Christopher Armstrong (radix)]

I think there may be a regression on this issue: I just got this same exact behavior (asking for a cryptswap passphrase during boot) on a brand new Ubuntu 15.10 system76 laptop with updates applied. I've contacted System76 support to let them know.

I'm also having some problems with LXC that may be related to this problem, but I haven't figured that out yet.

[dusoft (dusoft-staznosti)]

I confirm, brand new laptop installation of Ubuntu 15.10, happens repeatedly during apt-get upgrade etc.

[dusoft (dusoft-staznosti)]

Also, affects installation in GUI, when basically nothing indicates a password (or just pressing Enter key) is required ans system waits and waits until user opens console details and see what's happening. Quite annoying for users unaware of this as package installation waits for user interaction *without indicating so*.

[Avi (ikes73)]

Same bug on fully updated 15.10 on HP laptop. Are there any good work-arounds?

[david6 (andrew-dowden)]

This issue is present for current daily ISO for 16.04 LTS (Xenial Xerus).

Will test further ..

[david6 (andrew-dowden)]

Re-tested with latest daily (07-Mar), and still occurring.

Also issue at command line, doing update, with halt for 'enter password' occurs several times.

[Martin Pitt (pitti)]

I just did an installation with today's xenial amd64 desktop image with EFI, and things come out alright. I have an encrypted swap partition and the unencrypted fake/stub swap partition is not touched.

Please be more specific how exactly you installed, and give me the output of the following commands:

  sudo blkid
  swapon -s
  printf "x\np\n" | sudo fdisk /dev/sda
  ls -l /run/systemd/generator/

Thanks!

[Dirk Thomas (dthomas-b)]

I just installed todays daily build of Xenial with EFI and ran into the same problem.

$ sudo blkid
/dev/nvme0n1: PTUUID="7b6240b1-61b5-4fc7-939a-6a78708bdaad" PTTYPE="gpt"
/dev/nvme0n1p1: UUID="30E3-3A90" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="f92f5e37-7518-4e1e-91e2-f6a39b4b32c1"
/dev/nvme0n1p2: UUID="544fb035-9adf-433d-a291-47180b257560" TYPE="ext4" PARTUUID="429cab6f-729e-4055-903d-dced0f6b6529"
/dev/nvme0n1p3: UUID="f11492fb-f9bf-4699-80a9-8df106f1ed0c" TYPE="swap" PARTUUID="05a0be8e-8a2e-4e94-b74a-f3c620534f1a"

$ swapon -s
Filename Type Size Used Priority
/dev/nvme0n1p3 partition 33417212 0 -1

$ printf "x\np\n" | sudo fdisk /dev/nvme0n1

Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help):
Expert command (m for help): Disk /dev/nvme0n1: 477 GiB, 512110190592 bytes, 1000215216 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: gpt
Disk identifier: 7B6240B1-61B5-4FC7-939A-6A78708BDAAD
First LBA: 34
Last LBA: 1000215182
Alternative LBA: 1000215215
Partition entries LBA: 2
Allocated partition entries: 128

Device Start End Sectors Type-UUID UUID Name Attrs
/dev/nvme0n1p1 2048 1050623 1048576 C12A7328-F81F-11D2-BA4B-00A0C93EC93B F92F5E37-7518-4E1E-91E2-F6A39B4B32C1 EFI System Partition

/dev/nvme0n1p2 1050624 933380095 932329472 0FC63DAF-8483-4772-8E79-3D69D8477DE4 429CAB6F-729E-4055-903D-DCED0F6B6529
/dev/nvme0n1p3 933380096 1000214527 66834432 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F 05A0BE8E-8A2E-4E94-B74A-F3C620534F1A

$ ls -l /run/systemd/generator/
total 16
-rw-r--r-- 1 root root 374 Mar 18 16:17 boot-efi.mount
drwxr-xr-x 2 root root 60 Mar 18 16:17 cryptsetup.target.requires
drwxr-xr-x 2 root root 60 Mar 18 16:17 dev-disk-by\x2duuid-f11492fb\x2df9bf\x2d4699\x2d80a9\x2d8df106f1ed0c.device.wants
drwxr-xr-x 2 root root 60 Mar 18 16:17 dev-mapper-cryptswap1.device.d
drwxr-xr-x 2 root root 60 Mar 18 16:17 dev-mapper-cryptswap1.device.requires
-rw-r--r-- 1 root root 188 Mar 18 16:17 dev-mapper-cryptswap1.swap
drwxr-xr-x 2 root root 60 Mar 18 16:17 hwclock.service.d
drwxr-xr-x 2 root root 80 Mar 18 16:17 local-fs.target.requires
drwxr-xr-x 2 root root 60 Mar 18 16:17 local-fs.target.wants
-rw-r--r-- 1 root root 277 Mar 18 16:17 -.mount
drwxr-xr-x 2 root root 60 Mar 18 16:17 multi-user.target.wants
drwxr-xr-x 2 root root 60 Mar 18 16:17 networking.service.d
drwxr-xr-x 2 root root 60 Mar 18 16:17 remote-fs.target.d
drwxr-xr-x 2 root root 60 Mar 18 16:17 sendsigs.service.d
drwxr-xr-x 2 root root 60 Mar 18 16:17 swap.target.requires
-rw-r--r-- 1 root root 947 Mar 18 16:17 <email address hidden>
drwxr-xr-x 2 root root 60 Mar 18 16:17 umountfs.service.d
drwxr-xr-x 2 root root 60 Mar 18 16...

[Dirk Thomas (dthomas-b)]

The solution describe here (http://zeroset.mnim.org/2015/05/10/ubuntu-15-04-vivid-vervet-please-enter-passphrase-for-disk-cryptswap1-on-none/) which uses the device path instead of the UUID made it work for me.

[Martin Pitt (pitti)]

@Dirk: What's your /etc/fstab and /etc/crypttab?

[Dirk Thomas (dthomas-b)]

I tried it again today with the Beta 2 of Xenial. These are the steps I did:

* Downloaded Beta 2 of Xenial and created bootable USB stick
* Select: Try Ubuntu without installing
  * (I tried the option to install directly but that always hangs after selecting "Erase disk and install Ubuntu" and clicking "install")
* Check: Download updates during installation
* Select: Erase disk and install Ubuntu
* Check: Encrypt my home folder
* After installation finished and a restart it asks for: Please enter passphrase for disk cryptswap1 on none!
  * I hit enter without entering anything (same result when entering the password of the user)

The relevant content of the requested files:

* /etc/fstab:

    /dev/mapper/cryptswap1 none swap sw 0 0

    (This looks good using the device name instead of the UUID as before.)

* /etc/crypttab

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

But the swap is still not enabled. `swapon -s` reports the following:

    /dev/nvme0n1p3 partition 33427212 0 -1

Any help to get this working is highly appreciated.

[Martin Pitt (pitti)]

@Dirk: In comment 61, what's the output of "blkid"? Is there any actual partition with UUID=xxx that /etc/crypttab takes as source? I suppose /dev/nvme0n1p3 is the physical swap partition on which the installer was meant to put the encrypted partition. Does that appear in /etc/fstab? Which /run/systemd/generator/*.swap files exist?

[Martin Pitt (pitti)]

FTR, in comment 57 I pretty much did the same steps as Thomas in comment 61, but it worked for me. :(

[Dirk Thomas (dthomas-b)]

I had to move forward on this topic and went for a reinstallation using full disk encryption so sadly I can't provide the requested information anymore. Hopefully it will be reproducible within a VM by anyone.

[david6 (andrew-dowden)]

Sorry, been busy with work.

--

Re-tested today, with 16.04 LTS beta2, and still occurring. Also repeatedly stop for <Enter> at command line, doing update/upgrade.

I have an HP notebook with 64GB eMMC (SSD) storage, and existing partitions were already deleted.

[david6 (andrew-dowden)]

Output from following commands:

  sudo blkid
  swapon -s
  printf "x\np\n" | sudo fdisk /dev/sda
  ls -l /run/systemd/generator/

--

Welcome to Ubuntu Xenial Xerus (development branch) (GNU/Linux 4.4.0-16-generic x86_64)

$ sudo blkid
/dev/mmcblk0: PTUUID="964e28b5-d6c2-47c6-badd-de7725281f53" PTTYPE="gpt"
/dev/mmcblk0p1: UUID="8F05-DBA1" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="f13ded99-6623-4642-9319-5c7da84f93b4"
/dev/mmcblk0p2: UUID="040427a5-f2c1-481a-8cfc-6e9667f94855" TYPE="ext4" PARTUUID="3b78057b-58b5-449f-9607-ba173cd7f438"
/dev/mmcblk0p3: UUID="5d1798c3-4e4a-4c3c-842e-e929fbeceb85" TYPE="swap" PARTUUID="ae598300-c995-4ffb-a8f6-48a7758015ae"

$ swapon -s
Filename Type Size Used Priority
/dev/mmcblk0p3 partition 4046844 0 -1

$ printf "x\np\n" | sudo fdisk /dev/sda
fdisk: cannot open /dev/sda: No such file or directory

$ printf "x\np\n" | sudo fdisk /dev/sdb
fdisk: cannot open /dev/sdb: No such file or directory

$ printf "x\np\n" | sudo fdisk /dev/sdc
fdisk: cannot open /dev/sdc: No such file or directory

$ ls -l /run/systemd/generator/
total 16
-rw-r--r-- 1 root root 374 Mar 31 13:47 boot-efi.mount
drwxr-xr-x 2 root root 60 Mar 31 13:47 cryptsetup.target.requires
drwxr-xr-x 2 root root 60 Mar 31 13:47 dev-disk-by\x2duuid-5d1798c3\x2d4e4a\x2d4c3c\x2d842e\x2de929fbeceb85.device.wants
drwxr-xr-x 2 root root 60 Mar 31 13:47 dev-mapper-cryptswap1.device.d
drwxr-xr-x 2 root root 60 Mar 31 13:47 dev-mapper-cryptswap1.device.requires
-rw-r--r-- 1 root root 188 Mar 31 13:47 dev-mapper-cryptswap1.swap
drwxr-xr-x 2 root root 60 Mar 31 13:47 hwclock.service.d
drwxr-xr-x 2 root root 80 Mar 31 13:47 local-fs.target.requires
drwxr-xr-x 2 root root 60 Mar 31 13:47 local-fs.target.wants
-rw-r--r-- 1 root root 277 Mar 31 13:47 -.mount
drwxr-xr-x 2 root root 60 Mar 31 13:47 multi-user.target.wants
drwxr-xr-x 2 root root 60 Mar 31 13:47 networking.service.d
drwxr-xr-x 2 root root 60 Mar 31 13:47 remote-fs.target.d
drwxr-xr-x 2 root root 60 Mar 31 13:47 sendsigs.service.d
drwxr-xr-x 2 root root 60 Mar 31 13:47 swap.target.requires
-rw-r--r-- 1 root root 947 Mar 31 13:47 <email address hidden>
drwxr-xr-x 2 root root 60 Mar 31 13:47 umountfs.service.d
drwxr-xr-x 2 root root 60 Mar 31 13:47 umountnfs.service.d

$ printf "x\np\n" | sudo fdisk /dev/mmcblk0

Disk /dev/mmcblk0: 58.2 GiB, 62537072640 bytes, 122142720 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: gpt
Disk identifier: 964E28B5-D6C2-47C6-BADD-DE7725281F53
First LBA: 34
Last LBA: 122142686
Alternative LBA: 122142719
Partition entries LBA: 2
Allocated partition entries: 128

Device Start End Sectors Type-UUID UUID Name Attrs
/dev/mmcblk0p1 2048 1050623 1048576 C12A7328-F81F-11D2-BA4B-00A0C93EC93B F13DED99-6623-4642-9319-5C7DA84F93B4 EFI System Partition
                                                                                                      ...

[david6 (andrew-dowden)]

Details from /etc/fstab and /etc/crypttab ::

$ 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/mmcblk0p2 during installation
UUID=040427a5-f2c1-481a-8cfc-6e9667f94855 / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/mmcblk0p1 during installation
UUID=8F05-DBA1 /boot/efi vfat umask=0077 0 1
# swap was on /dev/mmcblk0p3 during installation
#UUID=5d1798c3-4e4a-4c3c-842e-e929fbeceb85 none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw 0 0

$ cat /etc/crypttab
cryptswap1 UUID=5d1798c3-4e4a-4c3c-842e-e929fbeceb85 /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

[lino (alvaro-aguirre)]

Same behavior here with 16.04. On boot and on upgrades the systems ask me for the password. If I use solution from #59 the system don't ask for the password anymore but the system takes 2 minutes to boot.

lino@pioneer:~$ sudo blkid
/dev/nvme0n1p6: UUID="d987f11f-51ab-446c-9cad-65f27200bd1f" TYPE="swap" PARTUUID="26ba4f5f-272f-4b52-8c95-fb32a025bada"
/dev/nvme0n1p1: LABEL="ESP" UUID="BC3B-4E24" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="423cce4f-51be-4c8f-a38c-7f35c4f25ad6"
/dev/nvme0n1p3: LABEL="OS" UUID="01D1865215EBF300" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="82f7b959-5b3d-4979-9ed9-275e7aa27135"
/dev/nvme0n1p4: LABEL="WINRETOOLS" UUID="44B2596EB2596608" TYPE="ntfs" PARTUUID="bd62ca2b-7eb9-47e9-a6dd-d7546be31a08"
/dev/nvme0n1p5: LABEL="Image" UUID="EA9459D89459A7B9" TYPE="ntfs" PARTUUID="814b3f7f-53f7-41aa-8b1f-bdef9ac64932"
/dev/nvme0n1p7: UUID="3c2d5db4-6381-4f81-9599-5d29942c917a" TYPE="ext4" PARTUUID="7b96edbd-a17d-4481-8cf7-ec31d165e182"
/dev/sda1: LABEL="CODEMETER" UUID="002B-D004" TYPE="vfat" PARTUUID="002bd004-01"
/dev/sdb1: SEC_TYPE="msdos" LABEL="DellUtility" UUID="3030-3030" TYPE="vfat" PARTUUID="07f2837e-01"
/dev/sdb2: LABEL="RECOVERY" UUID="92D03605D035EFD9" TYPE="ntfs" PARTUUID="07f2837e-02"
/dev/sdb3: UUID="defefa91-e453-4f67-85e2-8402447ef8fb" TYPE="crypto_LUKS" PARTUUID="07f2837e-03"
/dev/mapper/luks-defefa91-e453-4f67-85e2-8402447ef8fb: LABEL="Disco_Externo" UUID="597f766f-7dee-478c-a512-b49ecdf57843" TYPE="ext4"
/dev/nvme0n1: PTUUID="195d2663-e6e9-424d-ab66-31ec8f1d10a7" PTTYPE="gpt"
/dev/nvme0n1p2: PARTLABEL="Microsoft reserved partition" PARTUUID="ea83be62-bd92-4e6c-a98a-d652a9a003b1"
lino@pioneer:~$ swapon -s
Filename Type Size Used Priority
/dev/nvme0n1p6 partition 15999996 0 -1
lino@pioneer:~$ printf "x\np\n" | sudo fdisk /dev/sda

Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help):
Expert command (m for help): Disk /dev/sda: 39.3 MiB, 41156608 bytes, 80384 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: 0x002bd004

Device Boot Start End Sectors Id Type Start-C/H/S End-C/H/S Attrs
/dev/sda1 * 63 80324 80262 b W95 FAT32 0/1/1 4/63/254 80

lino@pioneer:~$ ls -l /run/systemd/generator/
total 16
-rw-r--r-- 1 root root 374 Apr 1 07:21 boot-efi.mount
drwxr-xr-x 2 root root 60 Apr 1 07:21 cryptsetup.target.requires
drwxr-xr-x 2 root root 60 Apr 1 07:21 dev-disk-by\x2duuid-d987f11f\x2d51ab\x2d446c\x2d9cad\x2d65f27200bd1f.device.wants
drwxr-xr-x 2 root root 60 Apr 1 07:21 dev-mapper-cryptswap1.device.d
drwxr-xr-x 2 root root 60 Apr 1 07:21 dev-mapper-cryptswap1.device.requires
-rw-r--r-- 1 root root 188 Apr 1 07:21 dev-mapper-cryptswap1.swap
drwxr-xr-x 2 root root 60 Apr 1 07:21 hwclock.service.d
drwxr-xr-x 2 root root 80 Apr 1 07:21 local-fs.target.requires
drwxr-xr-x 2 root root 60 Apr 1 07:21 local-fs.target.wants
-rw-r--r-- 1 root root 277 Apr 1 07:21 -....

[Tyler Hicks (tyhicks)]

I just did a fresh install, using the 07-Apr-2016 amd64 Desktop ISO, and have an encrypted swap.

$ sudo blkid /dev/sda
/dev/sda: PTUUID="ecd421a6-9bf6-40d5-a94e-c87ac47a479d" PTTYPE="gpt"
$ sudo blkid
/dev/sda1: UUID="50D0-7B1F" TYPE="vfat" PARTUUID="b2e2fef6-36c8-4d66-a57f-231672b9d5bb"
/dev/sda2: UUID="4d9e731b-bc43-45fc-b78e-a62a6fd51e37" TYPE="ext2" PARTUUID="c8e4875d-aa7e-4ae1-9417-97f821303627"
/dev/sda3: UUID="4hQqQp-MKTj-hPkE-DGIZ-2cgy-qkwB-PEoM6H" TYPE="LVM2_member" PARTUUID="624e3ff6-303f-4499-a5df-38459dd1f406"
/dev/sdb1: LABEL="OSDisk" UUID="CA30085930084EBF" TYPE="ntfs" PARTUUID="82da00cb-01"
/dev/sdb2: LABEL="Recovery" UUID="B8300A3C300A025C" TYPE="ntfs" PARTUUID="82da00cb-02"
/dev/mapper/ubuntu--vg-root: UUID="91ad536a-7427-4271-bb61-a9c8bb485316" TYPE="ext4"
/dev/mapper/ubuntu--vg-swap_1: UUID="8a06175f-5e69-48ed-948a-393fd127b955" TYPE="swap"
/dev/mapper/cryptswap1: UUID="0b1804c2-fb76-430b-93d1-63a6729fea6d" TYPE="swap"
$ swapon -s
Filename Type Size Used Priority
/dev/dm-2 partition 16698876 0 -1
$ ls -al /dev/mapper/cryptswap1
lrwxrwxrwx 1 root root 7 Apr 7 12:50 /dev/mapper/cryptswap1 -> ../dm-2
$ printf "x\np\n" | sudo fdisk /dev/sda

Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help):
Expert command (m for help): Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 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: gpt
Disk identifier: ECD421A6-9BF6-40D5-A94E-C87AC47A479D
First LBA: 34
Last LBA: 976773134
Alternative LBA: 976773167
Partition entries LBA: 2
Allocated partition entries: 128

Device Start End Sectors Type-UUID UUID Name Attrs
/dev/sda1 2048 1050623 1048576 C12A7328-F81F-11D2-BA4B-00A0C93EC93B B2E2FEF6-36C8-4D66-A57F-231672B9D5BB
/dev/sda2 1050624 2050047 999424 0FC63DAF-8483-4772-8E79-3D69D8477DE4 C8E4875D-AA7E-4AE1-9417-97F821303627
/dev/sda3 2050048 976771071 974721024 E6D6D379-F507-44C2-A23C-238F2A3DF928 624E3FF6-303F-4499-A5DF-38459DD1F406

Expert command (m for help):
$ ls -l /run/systemd/generator/
total 20
-rw-r--r-- 1 root root 374 Apr 7 15:11 boot-efi.mount
-rw-r--r-- 1 root root 450 Apr 7 15:11 boot.mount
drwxr-xr-x 2 root root 60 Apr 7 15:11 cryptsetup.target.requires
drwxr-xr-x 2 root root 60 Apr 7 15:11 dev-disk-by\x2duuid-8a06175f\x2d5e69\x2d48ed\x2d948a\x2d393fd127b955.device.wants
drwxr-xr-x 2 root root 60 Apr 7 15:11 dev-mapper-cryptswap1.device.d
drwxr-xr-x 2 root root 60 Apr 7 15:11 dev-mapper-cryptswap1.device.requires
-rw-r--r-- 1 root root 188 Apr 7 15:11 dev-mapper-cryptswap1.swap
drwxr-xr-x 2 root root 60 Apr 7 15:11 hwclock.service.d
drwxr-xr-x 2 root root 100 Apr 7 15:11 local-fs.target.requires
drwxr-xr-x 2 root root 60 Apr 7 15:11 local-fs.target.wants
-rw-r--r-- 1 root root 250 Apr 7 15:11 -.mount
drwxr-xr-x 2 root root 60 Apr 7 15:11 multi-user.target.wants
drwxr-xr-x 2 root root 60...

[david6 (andrew-dowden)]

Re-tested today with 16.04 LTS (xenial-desktop-amd64, daily-build, 07-Apr), and still occurring.

I have an HP Stream 11 Pro G2 notebook with 64GB eMMC (SSD) storage, and existing partitions were deleted.

Minor issue: Notebook stalled with 'sda' (USB used for install) cache/pass-thru error, after it prompted that install was complete. This error may have previously occurred (earlier attempts, and during install/load), but did not stop for me to read wording.

This did NOT pause (for <Enter> at command line) doing update/upgrade. However, only a limited number of updates were available.

--

I think this specifically relates to 'NVMe' and 'eMMC' SSD media, as this appear to be common feature for those reporting recent issues.

[david6 (andrew-dowden)]

Output from following commands:

  sudo blkid
  swapon -s
  printf "x\np\n" | sudo fdisk /dev/mmcblk0
  ls -l /run/systemd/generator/

  cat /etc/fstab
  cat /etc/crypttab

--

Welcome to Ubuntu Xenial Xerus (development branch) (GNU/Linux 4.4.0-17-generic x86_64)

$ sudo blkid
/dev/mmcblk0: PTUUID="ed15471e-2ed3-4d17-82f0-2b21b0922606" PTTYPE="gpt"
/dev/mmcblk0p1: UUID="8F05-DBA1" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="3f71d0e0-4bd1-4c17-9828-63a992fc1727"
/dev/mmcblk0p2: UUID="4fb05929-3546-4b7c-b4f0-34c4a721c3c3" TYPE="ext4" PARTUUID="ecd9e622-8db1-45a1-9b7e-0ac5d93a9a96"
/dev/mmcblk0p3: UUID="5d1798c3-4e4a-4c3c-842e-e929fbeceb85" TYPE="swap" PARTUUID="0df8044d-7755-47fd-8a80-be2bbc7c87ef"

$ swapon -s
Filename Type Size Used Priority
/dev/mmcblk0p3 partition 4046844 0 -1

$ printf "x\np\n" | sudo fdisk /dev/mmcblk0

Disk /dev/mmcblk0: 58.2 GiB, 62537072640 bytes, 122142720 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: gpt
Disk identifier: ED15471E-2ED3-4D17-82F0-2B21B0922606
First LBA: 34
Last LBA: 122142686
Alternative LBA: 122142719
Partition entries LBA: 2
Allocated partition entries: 128

Device Start End Sectors Type-UUID UUID Name Attrs
/dev/mmcblk0p1 2048 1050623 1048576 C12A7328-F81F-11D2-BA4B-00A0C93EC93B 3F71D0E0-4BD1-4C17-9828-63A992FC1727 EFI System Partition

/dev/mmcblk0p2 1050624 114046975 112996352 0FC63DAF-8483-4772-8E79-3D69D8477DE4 ECD9E622-8DB1-45A1-9B7E-0AC5D93A9A96
/dev/mmcblk0p3 114046976 122140671 8093696 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F 0DF8044D-7755-47FD-8A80-BE2BBC7C87EF

$ ls -l /run/systemd/generator/
total 16
-rw-r--r-- 1 root root 374 Apr 8 08:21 boot-efi.mount
drwxr-xr-x 2 root root 60 Apr 8 08:21 cryptsetup.target.requires
drwxr-xr-x 2 root root 60 Apr 8 08:21 dev-disk-by\x2duuid-5d1798c3\x2d4e4a\x2d4c3c\x2d842e\x2de929fbeceb85.device.wants
drwxr-xr-x 2 root root 60 Apr 8 08:21 dev-mapper-cryptswap1.device.d
drwxr-xr-x 2 root root 60 Apr 8 08:21 dev-mapper-cryptswap1.device.requires
-rw-r--r-- 1 root root 188 Apr 8 08:21 dev-mapper-cryptswap1.swap
drwxr-xr-x 2 root root 60 Apr 8 08:21 hwclock.service.d
drwxr-xr-x 2 root root 80 Apr 8 08:21 local-fs.target.requires
drwxr-xr-x 2 root root 60 Apr 8 08:21 local-fs.target.wants
-rw-r--r-- 1 root root 277 Apr 8 08:21 -.mount
drwxr-xr-x 2 root root 60 Apr 8 08:21 multi-user.target.wants
drwxr-xr-x 2 root root 60 Apr 8 08:21 networking.service.d
drwxr-xr-x 2 root root 60 Apr 8 08:21 remote-fs.target.d
drwxr-xr-x 2 root root 60 Apr 8 08:21 sendsigs.service.d
drwxr-xr-x 2 root root 60 Apr 8 08:21 swap.target.requires
-rw-r--r-- 1 root root 947 Apr 8 08:21 <email address hidden>
drwxr-xr-x 2 root root 60 Apr 8 08:21 umountfs.service.d
...

[david6 (andrew-dowden)]

Re-tested today/yesterday with 16.04 LTS (xenial-desktop-amd64, daily-build, 11-Apr), with existing partitions deleted, or SSD secure erased.

(a.) HP ProDesk 600 G2 SFF (Skylake, Core i5), with 256GB SSD (SATA 3 interface) storage.

No issue occurred.

(b.) HP Stream 11 Pro G2 notebook (Braswell SoC, Celeron N3050), with 64GB eMMC (SSD) storage.

Issue still occurs, with prompt (black box) on startup. Also has multiple pauses (for <Enter> at command line) doing update/upgrade.

--

This could still be specific to 'NVMe' and 'eMMC' SSD media (which use the simple /sda /sdb /sdc for path), as this appear to be a common feature.

[david6 (andrew-dowden)]

Correction:

This could still be specific to 'NVMe' and 'eMMC' SSD media (which do NOT use the simple /sda /sdb /sdc for path), as this appear to be a common feature.

[Zakatell Kanda (zakatellkanda)]

I just installed 16.04 and this issue still persists.

I have NVMe for some info.

[Ben Whitten (benwhitten)]

I believe the issue lies in the line;
drive="${phys_dev%[0-9]*}"

This matches fine for /dev/sda* type partitions but not /dev/nvme*n*p* or /dev/mmcblk*p* resulting in a device that fdisk doesn't know about and cant proceed to set the no-auto flag.

This is what I did to set the flag after installation and stop the prompts, use at your own risk double check your partitions and devices!!
Find out what partition your swap is on, look in /etc/fstab and it says where it was during installation, for me this was /dev/nvme0n1p7.
Set the no-auto flag on this partition with: fsdisk --part-attrs /dev/nvme0n1 7 "63"
Reboot to no prompt.
Check with: swapon -s
I get /dev/dm-0

[Ben Whitten (benwhitten)]

I meant sfdisk in the above message, whoops.

[david6 (andrew-dowden)]

Re-tested today/yesterday with 16.04 LTS (official release), with existing partitions deleted.

HP Stream 11 Pro G2 notebook (Braswell SoC, Celeron N3050), with 64GB eMMC (SSD) storage.

Issue still occurs, with prompt (black box) on startup. No pauses (for <Enter> at command line) doing update/upgrade, but also no updates available (at present).

Corrected (per Comment #75, #76), with:

$ cat /etc/fstab
--
# swap was on /dev/mmcblk0p3 during installation
--

$ sudo sfdisk --part-attrs /dev/mmcblk0 3 "63"

(after reboot)
$ swapon -s
--
Filename Type Size Used Priority
/dev/dm-0 partition 4046332 0 -1
--

[Martin Pitt (pitti)]

Nicely spotted, Ben! Thanks, will prepare an update on Monday.

[landsraad (tengasiaiuticonquesto)]

Thank you Ben, your solution worked like a charm...

[grosso (grossogrossum)]

I'm experiencing this bug too, and my partitions are /dev/sda* type, so the workaround in comment #74 has no effect. With the other issues in boot and upgrade I have notice that my boot last until I stop or restart any service

XX-laptop:~$ systemd-analyze
Bootup is not yet finished. Please try again later.
XX-laptop:~$ systemd-analyze
Bootup is not yet finished. Please try again later.
XX-laptop:~$ systemd-analyze
Bootup is not yet finished. Please try again later.
XX-laptop:~$ systemd-analyze
Bootup is not yet finished. Please try again later.
XX-laptop:~$ systemd-analyze
Bootup is not yet finished. Please try again later.
XX-laptop:~$ sudo systemctl restart bluetooth.service
[sudo] password for XX:
Please enter passphrase for disk XXXXXXXXXXXXXXXXXX (cryptswap1) on none!
XX-laptop:~$ systemd-analyze
Startup finished in 4.593s (firmware) + 6.599s (loader) + 8.935s (kernel) + 1h 2min 54.118s (userspace) = 1h 3min 14.247s

I think it's not related with de partition name type.

[Jason Gerard DeRose (jderose)]

Any chance this can get fixed in Xenial in time for 16.04.1?

[thijs van severen (thijsvanseveren)]

still present in 16.04

[David Henningsson (diwic)]

Just in case it helps someone:

This symptom seems to have more than one root cause. For me, I had more than one entry in /etc/crypttab, one being completely wrong. It was probably a left-over from me switching hard drives a while ago, but then the symptom only started to appear after a 14.04 -> 16.04 upgrade.

[Jason Gerard DeRose (jderose)]

@diwic - I agree, there have been problems in multiple places causing this.

Yesterday I sorted out one of them. If you have swap on a GPT partitioned NVMe or MMC drive, ecryptfs-setup-swap isn't correctly marking the partition as non-auto-mounting, which leads the the user erroneously being prompted to enter a passphrase to unlock the swap partition.

I filed a bug about this and have a merge proposal ready for review:
https://bugs.launchpad.net/ecryptfs/+bug/1597154

This bug has been present in ecryptfs-utils since the original GPT auto mounting issues was fixed, but not that long ago in 16.04 it didn't result in being erroneously being prompted to enter a passphrase to unlock the swap partition. Some some recent-ish behavior change elsewhere has re-exposed this (I'm guessing a change in systemd).

[Launchpad Janitor (janitor)]

This bug was fixed in the package ecryptfs-utils - 111-0ubuntu1.1

---------------
ecryptfs-utils (111-0ubuntu1.1) xenial-security; urgency=medium

  * SECURITY UPDATE: Information exposure via unencrypted swap partitions. The
    swap partition was not configured to use encryption when GPT partitioning
    was in use on NVMe and MMC drives.
    - debian/patches/set-up-encrypted-swap-on-nvme-and-mmc.patch: Properly
      handle the formatting of the path to swap partitions on NVMe and MMC
      drives so that they're correctly marked as not to be automatically
      mounted by systemd. Based on upstream patch from Jason Gerard DeRose.
      (LP: #1597154)
    - debian/ecryptfs-utils.postinst: Fix any unencrypted GPT swap partitions
      that have mistakenly remained marked as auto mount. This should only
      modify the swap partitions on systems that ecryptfs-setup-swap has been
      used on. (LP: #1447282, LP: #1597154)
    - CVE not yet assigned

 -- Tyler Hicks <email address hidden> Wed, 13 Jul 2016 00:36:59 -0500

[Launchpad Janitor (janitor)]

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

---------------
ecryptfs-utils (111-0ubuntu2) yakkety; urgency=medium

  * SECURITY UPDATE: Information exposure via unencrypted swap partitions. The
    swap partition was not configured to use encryption when GPT partitioning
    was in use on NVMe and MMC drives.
    - debian/patches/CVE-2016-6224.patch: Properly handle the formatting of
      the path to swap partitions on NVMe and MMC drives so that they're
      correctly marked as not to be automatically mounted by systemd. Based on
      upstream patch from Jason Gerard DeRose. (LP: #1597154)
    - debian/ecryptfs-utils.postinst: Fix any unencrypted GPT swap partitions
      that have mistakenly remained marked as auto mount. This should only
      modify the swap partitions on systems that ecryptfs-setup-swap has been
      used on. (LP: #1447282, LP: #1597154)
    - CVE-2016-6224

 -- Tyler Hicks <email address hidden> Thu, 14 Jul 2016 18:48:53 -0500

[grosso (grossogrossum)]

This don't solve the issue for me, it asks for
Please enter passphrase for disk XXXXXXXXXXXXXXXXXX (cryptswap1) on none!
on boot.

[Tyler Hicks (tyhicks)]

Grosso - can you open a new bug and include the following information:

  Attach /etc/fstab and /etc/crypttab

  Run the following commands and include their output:
  $ sudo blkid
  $ swapon -s
  $ printf "x\np\n" | sudo fdisk /dev/sda
  $ ls -l /run/systemd/generator/

[grosso (grossogrossum)]

I rebuild my swap and now the 'passphrase' message is gone; i'm sorry for the wrong comment.

[Helge Jordan (helge-jordan)]

Bug doesn't seem to be fixed. I upgraded to ecryptfs-utils - 111-0ubuntu1 (see post by Launchpad Janitor (janitor) of 2016-07-14 - marking it as fixed).
However, the system keeps asking for a password for cryptswap1.
I rebuilt my swap as grosso did; however no success.

[Shaform (shaform)]

I encountered the same issue as well on Ubuntu 16.04.
In particular, this seems to occur only after I create a LUKS Encrypted partition by the disk util.

[Daniel Jenkins (jeukel)]

GPT partition with encrypted /home.

Same error occurs if / gets a label or /home gets resized.

[Daniel López Azaña (daniloaz)]

I renamed a partition other than swap partition from a gpt disk with "parted name 9 xxxx" and in the next reboot I started to be asked to enter a passprase for the swap partition. So this is another way to reproduce this thread's issue that I think was not mentioned.

My version of ecryptfs-utils is 111-0ubuntu1.1 (Ubuntu 16.04.2 LTS).

[Boyd (boyd-dyob)]

Same experience as daniloaz using 111-0ubuntu1.1 (Ubuntu 16.04.2 LTS) and I have the same thing on another laptop running 17.04