ecryptfs-setup-swap hints after reboot

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

A possible workaround inside the script "/usr/bin/ecryptfs-setup-swap" could be:

*******
# Add crypttab entry

 echo "cryptswap$i UUID=$uuid /dev/urandom swap,offset=8,cipher=aes-cbc-essiv:sha256" >> /etc/crypttab
*******

Please test the supplement "offset=8" as a sufficient space to avoid the UUID will be overwritten.

Alternativily it should be tested to use the Option "skip" instead.

I had the same problem after installing Kubuntu 14.04 64bit. During the installation process I mounted an existing home partition encrypted with ecryptfs. Result: The swap partition was not available/mounted. After manually implementing syscon-hh's solution in the first post, all is well.

I should have added that sudo blkid reported a different UUID for the swap partition than the one used in /etc/crypttab. Replacing that one with the UUID reported by blkid did not solve the problem.

This bug also affected me with Ubuntu 14.04 and encrypted home-directory. The swap partition existed but was not mounted as a crypted swap.

My workaround:

Changing /etc/crypttab in (e.g.):

#cryptswap1 UUID=a81fe18e-0f2a-4571-adeb-a80d57015549 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
cryptswap1 /dev/sda6 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

was successfull.

"free" gives:

             Gesamt Belegt Frei Gemeinsam Puffer Cached
Speicher: 7966568 1840508 6126060 180132 84148 814660
-/+ Puffer/Cache: 941700 7024868
Auslagerungsdatei: 15624188 0 15624188

and suspend to disk is possible.

On Trusty, blkid is also unable to read the UUID of a swap partition of a Raring system, while that swap is working fine on Raring.
I will check tomorrow what blkid does on Raring.

@syscon-hh: I hope to be able to test your 'skip' option tomorrow.

Turns out Raring does not use UUID's here but /dev/sdXY names. That explains why it used to work (and silently the mint 16 system on sdb here has been using the swap of the hot-pluggable sda drive with trusty-based mint 17 on it...)

@ syscon-hh: offset=8 appears to work, skip=8 does not help to preserve the UUID after a reboot (skip without a value is ignored by cryptdisks_start).

@ syscon-hh: or did you mean offset=8,skip=0? I will test that too.

@ syscon-hh: I do not see any difference using it with offset=8 or offset=8,skip=0.

@ Albert - both options should be used alternatively only:
 * offset=8
or
 * skip=8
never both in one line.

for further Informations see "man cryptsetup" -> "options"

@ syscon-hh: in that case, offset=8 works, skip=8 does not. So offset=8 it is.

Hello everyone, I reached here from bug Bug #1301383.
I'd like to know if this issue is gonna be adressed by the time 14.04.1 comes out, since installing it as is today doesn't enable the SWAP partition...

Alberts hint in #9 is correct. I've just fixed this issue on my system:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/953875/comments/17

Most verbose and explanatory comment:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1301383/comments/6

I followed through all the comments, but I've still run into problems after rebooting.

Comment #3 by syscon-hh <https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1310058/comments/3> and Albert's detailed instructions <https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1301383/comments/6> have been extremely helpful.

After this process is completed (as explained by Albert)...

"Then you can convert your unencrypted swap into an encrypted one, using sudo ecryptfs-setup-swap. That will now work fine, because you have patched the file to include "offset=8" in the /etc/crypttab file.
Again, use swapon -s to verify that the swap is enabled; but now it should display /dev/mapper/cryptswap1 as device."

...swap is not activated after a reboot. I confirmed that the latest changes to /etc/fstab and /etc/crypttab made by ecryptfs-setup-swap have remained intact.

So I tried manually enabling swap:

$ sudo swapon -a -v

Which resulted in the following error:

read swap header failed: Invalid argument

So I tried doing this:

$ sudo mkswap /dev/mapper/cryptswap1
$ sudo swapon -a -v

And swap was up and running again!

But does swap work after rebooting? It sure does, albeit with the following errors in dmesg:

device-mapper: ioctl: Unable to change name on mapped device cryptswap1_unformatted to one that already exists: cryptswap1

The only hint I can find so far is in /var/log/upstart/cryptdisks.log:

* cryptswap1 (starting)...
Device cryptswap1_unformatted already exists.
...done.

Any suggestions on what's happening here?

@ syscon-hh

I can confirm your workaround #3.
UUID alongside offset=8 is working well in my case.

Ouch. This was painful to resolve.

The workarounds proposed do not work "out of the box" when encountered after a "default" installation of 14.04.01 using encrypted fs and home directory. Under those conditions, the encrypted swap is named ubuntu--vg-swap_1. Following the instrucions in post 3, 9, and 17 leave the system in a slightly odd state as the ubuntu--vg-swap_1 is properly setup, but the /etc/crypttab has an entry for "cryptswap1" (which is why Ryokenau was having trouble).

Wish I had time to detail proper fix, but I needed to manually adjust /etc/crypttab to point to proper ubuntu--vg-swap_1, and adjusting /etc/fstab with appropriate UUID for the swap file.

Well, I've seen a similar bug in Precise for quite a long time:

https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/571682
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/798086
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/953875
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1061190
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1153661
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1186811
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1305961
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1303002

and any proposed solution to clear the infamous message 'The disk drive for /dev/mapper/cryptswap1 is not ready yet or not present" was useless. But it was not a major problem, at least on my systems, because at the end the swap partition was mounted and was working despite the message. Now, the situation on Trusty is bad, because the cryptswap partition just doesn't work. That's why I don't believe this error should be flagged again as a duplicate of bug #953875.

Ubuntu Trusty 14.04.1

$ free --human
             total
Mem: 15.7G
-/+ buffers/cache: 985M
Swap: 0.0B

$ swapon --summary
Filename Type Size Used Priority

https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1310058/comments/3 should have solved the problem, but no. After modifying /etc/cryptswap from:

cryptswap1 UUID=01234567-89ab-cdef-0123-456789abcdef /dev/urandom swap,cipher=aes-cbc-essiv:sha256

to

cryptswap1 UUID=01234567-89ab-cdef-0123-456789abcdef /dev/urandom swap,offset=8,cipher=aes-cbc-essiv:sha256

the problem persists. The same with the line:

cryptswap1 /dev/sdaX /dev/urandom swap,cipher=aes-cbc-essiv:sha256

after formating the swap partition with the old UUID:

sudo mkswap --label Ubuntu\ Swap --uuid 01234567-89ab-cdef-0123-456789abcdef /dev/sdaX

and rebooting the system. So I guess the problem is due to a race condition of the /etc/init.d/cryptdisks-early script. If I disable it the swap partition is mounted automatically on every reboot.

My final solution to this problem:

DON'T DISABLE /etc/init.d/cryptdisks-early !

1. DEACTIVATE AUTOMATIC MOUNTING OF CRYPTSWAP1:

Modify /etc/fstab changing the line:

/dev/mapper/cryptswap1 none swap sw 0 0

to

/dev/mapper/cryptswap1 none swap noauto,sw 0 0

and modify /etc/crypttab changing the line from:

cryptswap1 UUID=01234567-89ab-cdef-0123-456789abcdef /dev/urandom swap,cipher=aes-cbc-essiv:sha256

to

cryptswap1 UUID=01234567-89ab-cdef-0123-456789abcdef /dev/urandom noauto,offset=6,swap,cipher=aes-cbc-essiv:sha256

Don't forget to replace my sample UUID with the correct for your system. On my system offset=6 was sufficient, because cryptsetup already skips the two first sectors of the swap partition.

2. REBUILD YOUR SWAP PARTITION

CAUTION: you must replace /dev/sdaX with the correct swap partition for your system!

sudo mkswap --label Ubuntu\ Swap --uuid 01234567-89ab-cdef-0123-456789abcdef /dev/sdaX

Don't forget to replace my sample UUID with the correct for your system. The label is optional (I like swap partition labels :D)

3. CREATE AN UPSTART SCRIPT ( /etc/init/cryptswap1.conf )

start on started mountall
script
 /sbin/cryptdisks_start cryptswap1
 /sbin/swapon /dev/mapper/cryptswap1
end script

4. REBOOT AND VERIFY YOUR SYSTEM

$ free --human

             total used free shared buffers cached
Mem: 15.7G ...
-/+ buffers/cache: ...
Swap: 16.0G ...

$ swapon --summary
Filename Type Size Used Priority
/dev/mapper/cryptswap1 ...

What happened on Trusty was that cryptswap started using UUID instead of /dev/sdXY names, and the encryption with a random key overwrites the partition's UUID unless an offset in crypttab is used. So I wouldn't tag it as a duplicate of a Precise bug, a whole new problem was created by switching to UUID in Trusty.

Yes, Albert, you are right. My last precise/cryptab backup says:

cryptswap1 /dev/sdaX /dev/urandom swap,cipher=aes-cbc-essiv:sha256

My problem with trusty seems to be two different bugs happening at the same time. The first, the UUID problem, that is solved with offset = 6 & mkswap, and the second, the hateful message 'The disk drive for /dev/mapper/cryptswap1 is not ready yet or not present' and the recurrent issue on some systems preventing ubuntu to mount the swap partition on some configurations. Using noauto to ignore the disk at boot an mounting it automatically using an alternative way solves it in precise & trusty. The message is so recurrent in various editions that I think ubiquity must implement some solution similar to my noauto solution when only encrypts the home user directory and the swap partition.

I would keep the two problems in separate bugs, since they do not have the same cause. This is the bug for the problems with the partition UUID and the crypttab file.

A note of warning:

Without swap, you are used to your laptop suspending to RAM when closing the lid.

@Wetware Random Number Generator (tnrng)

> wrote on 2014-10-10: #22
> My final solution to this problem:

This causes laptops to try to hibernate when you close the lid. Failing. Losing all unsaved changes. Even though in Power Management settings are set to suspend (not hibernate).

Got any clue on how to get closed laptops to suspend again in stead of hibernate?

About power management settings being ignored, please ask on the forum of Ubuntu (or the distro you are using) or open a new bug. It should be unrelated to this bug, you just never saw this problem because you were never able to hibernate at all.

That hibernate fails, is yet another different problem. It is by design that the encrypted swap created by ecryptfs-setup-swap won't work with hibernate. I think it has been discussed at length in other bug reports or on forums already, with other encryption methods (such as encryption with a password instead of a random key) being suggested as solutions. Not encrypting your swap would of course allow you to hibernate as well.

In short, you already fixed the problem which this bug describes, the other problems which are left to fix are beyond the scope of this bug.

As for #17, in my experience swap was activated sometimes, but not always, during reboot.

I'm in the same situation as Ryokenau.

Back to Dekker500's comment #19, does this only occur when you check the installer options for encrypted filesystem and encrypted home?
In other words, if you run the installer and select "Erase disk and install Ubuntu" and check "Encrypt the new Ubuntu installation" and "Use LVM" but *not* "Encrypt my home folder", would that work around this bug?

If the entire disk is encrypted, it's redundant to encrypt /home too, correct? At least, for a single-user machine.

As shown here:
https://www.computersnyou.com/3193/install-ubuntu-14-04-desktop-encrypted-lvm/
https://www.computersnyou.com/wp-content/uploads/2014/04/Screen-Shot-2014-04-18-at-11.04.19-pm.png
https://www.computersnyou.com/wp-content/uploads/2014/04/Screen-Shot-2014-04-18-at-11.06.27-pm-2-e1397847694424.png

Hey.

I have a way to work around this in 14.04, 14.10, and 15.04:

COMPLETE FIX -- Ubuntu Utopic Unicorn 14.10 -- The disk drive dev/mapper/cryptoswap1 is notready yet or not present (Also works for 14.04 and 15.04)

https://gist.github.com/v6/42a46943d1a50aa4fd66

Hi there, I believe I patched the issue in ecryptfs-setup-swap which causes this problem in the first place.
This program now sets the swap's fstab to noauto, crypttab offset to 6, and creates a file in /etc/init which mounts the swap partition automatically as soon as it's ready.

I beleve there are 2 problems with the current setup. The first one is caused by the cryptswap changing the uuid of the drive. This is fixed by using an offset of 6 (* 512 bits) to skip the portion where the uuid is apparently stored. The second one is caused by fstab trying to mount the swap before cryptab has encrypted the partition. This is fixed by mounting the partition with the /etc/init file.

This program will still find multiple swap partitions on the harddrive, encrypt them, and mount them automatically at boot.

You can also use it to fix your current system by doing the following:
Delete all mention to the swap partitions in your /etc/fstab and /etc/crypttab.
Restart your computer.
Reformat your swap partitions.
Enable your swap partitions and make sure they are running working properly.
Finally in the directory containing my patched verson run:
chmod +x ecryptfs-setup-swap
sudo ./ecryptfs-setup-swap
and restart your computer .

Now your swaps should all be encrypted and working!
If this doesn't work for you please let me know.

I would also like to add that this attachment is basically just automating #22's solution to the problem.

The attachment "ecryptfs-setup-swap (patched)" 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.]

Yes that is a patch for the ecryptfs-setup-swap script. If ubuntu were to use it to replace the current ecryptfs-setup-swap in the installation iso we would no longer have this bug.

Yes this patch is working - but under *upstart* only.

Using the coming up systemd feature this patch will destroy more than the patch helps.

Well that's too bad. I'll try to find a way that doesn't use upstart then. Thanks for the information! I'll keep you guys posted.

So, from what I can tell, this is the only way to do it while working with an init upstart system. I suppose that when ubuntu makes that change, I'll just have to write another patch. I do believe archlinux had was having a similar problem with crypttab and uuid's. They use systemd but, they just assume you set it up yourself, using /dev/disk/by-id (wich is unique for every disk) (or apply an offset of 6). I also don't remember there being a problem after that, so maybe since they use systemd the issue is avoided (maybe).

Okay, so I believe that I fixed the issue without using upstart. This version instead uses sysvinit instead. Please let me know what you think. This would fix the issue for the installer if it was added to the iso.

You can also use it to fix your current system by doing the following:
Delete all mention to the swap partitions in your /etc/fstab and /etc/crypttab.
Restart your computer.
Reformat your swap partitions.
Enable your swap partitions and make sure they are working properly.
Finally in the directory containing my patched verson, run:
chmod +x ecryptfs-setup-swap
sudo ./ecryptfs-setup-swap
and restart your computer.

Should I create a ppa for this?

Stay with script for upstart version as provided with #32

Due to *systemd* will work no longer with *init.d* anyway.

The version #39 makes nothing else then to provide the *crysetup* in background only.

Now our solution -> provided for *systemd* computers:

*/etc/fstab*

# LABEL=COMMON-SWAP none swap sw 0 0

uncomment swap-volume only!

*/etc/crypttab*

# <target name> <source device> <key file> <options>
cryptswap1 LABEL=COMMON-SWAP /dev/urandom swap,cipher=aes-cbc-essiv:sha256,offset=8,noauto

Required are *offset=8* - otherwise the given basis (swap-volume) will be destroid! For testing purpose only the *LABEL* definition has been used.

*/etc/rc.local* (extension modul)

/sbin/cryptdisks_start cryptswap1
/bin/sleep 5
/sbin/swapon /dev/mapper/cryptswap1

Comments: -> */bin/sleep 5* -> t.b.d. - depends on volume / GiB to be crypted.

*/etc/rc.local* -> will be started from */lib/systemd/system/rc.local.service* and provides:

root@USB-GNOME:~# blkid | grep COMMON-SWAP
/dev/sdb1: LABEL="COMMON-SWAP" UUID="c939105e-bae2-437e-9d0c-affac8e959ea" TYPE="swap"
   PARTUUID="2f299a37-e690-447e-91a3-917d2c0161c9"
root@USB-GNOME:~# swapon -s
Filename Type Size Used Priority
/dev/dm-0 partition 8519672 0 -1

I can confirm that *offset=8* in the line in */etc/crypttab* makes cryptswap survive reboots. I have tested it in Lubuntu Vivid 32-bit.

I used the simple method described in comment #3.

Don't get me wrong. I read this bug report, and I see that there are many comments that point forward to squashing the bug.

The previous post (#42) describes a work-around method that works today with Lubuntu Vivid. It does not contain what will be used to squash the bug. See the following link

http://ubuntuforums.org/showthread.php?t=2266912&page=3&p=13240893#post13240893

I was confronted with this bug simply because I checked "Encrypt home folders" during a fresh installation of Ubuntu LTS 14.04 .
There seems to be a certain amount of unwillingness to resolve this issue because we are moving from Upstart to systemd.
This I understand.

However, why not leave users then with at least a working unencrypted swap, instead of a non-functional encrypted swap?
After all, during installation I checked for encrypting /home, not swap. Furthermore, the risks involved with a plain, unencrypted swap are very limited.

Here is how I recovered from the disfunctional swap without reinstalling, nor rebooting, whilst keeping /home encrypted:
http://askubuntu.com/a/617255/164341

*** This bug is a duplicate of bug 953875 ***
    https://bugs.launchpad.net/bugs/953875

which is actually squashed now. The working version of cryptswap is available when you install 15.04.

For example, the following iso test case for Lubuntu works (I have tested it)

http://iso.qa.ubuntu.com/qatracker/milestones/338/builds/92394/testcases/1439/results