I had the same problem when using an encrypted swap partition. Neither the general Swap FAQ, Puny Geek's solution to the "cryptswap1 is not ready yet or not present" message nor Braiam's answer to this question solved the problem for me - sometimes the swap was available, sometimes it wasn't. After many reboots and some poking around, I think I have found the underlying reason:
The path to the swap partition like /dev/sda3
is sometimes different, e.g. /dev/sdb3
. Since the file /etc/crypttab
by default seems to identify the swap partition through this path, sometimes it would find it (if that partition happens to get the same path at boot) or not (if the partition gets a different path assigned at boot).
Seems like I wasn't the only one with that problem becasue as described here, a better solution would be to bind the swap partition through it's drive ID instead of its /dev/sd*
path. This can be found by running
ls -l /dev/disk/by-id/
which lists the disk IDs for all partitions including the swap, which in my case was
ata-TOSHIBA_MQ01UBD100_73JATD5GT-part3 -> ../../sdb3
Double check in a program like Disk Utility that the -> ../../sdb*
part of this line is indeed the partition you intend to use for swapping, as this (as I said before) can sometimes change names. As always, keep this in mind:
Caution: fiddling with cryptsetup and disk devices is dangerous for
data and OS. I personally made a full backup on a separate disk and
then umplugged it to be sure it wouldn’t be involved in any mishap.
Then edit your /etc/crypttab
file by using the ID link instead of the "raw" path, in my case this line is
cryptswap1 /dev/disk/by-id/ata-TOSHIBA_MQ01UBD100_73JATD5GT-part3 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
I think this method should be the default for new installations, as one apparently can never be sure of the /dev/sd*
paths... which I find somewhat worrying as I have the feeling that there are way more scripts and software out there which still rely on these paths (instead of IDs, labels or UUIDs) to stay the same across reboots.
TODO:
I haven't checked if resuming out of hibernation still works with this setup, as this seems to rely on a UUID (which my swap partition didn't have), as stated on this page: https://altinukshini.wordpress.com/2012/10/15/devmappercryptswap1-is-not-ready-yet-or-not-present/
Update:
Hibernation seems to work fine so far. Hope this solves these problems for others as well!
Known Bug
There is a bug (see below) that overwrites the UUID
for the partition as soon as data is written to it. Therefore, you cannot use the UUID
to reference the partition to use for encrypted swap.
These days, swap space is hardly ever used. On my machine, swap is only used when I open my 40th tab. When I have no swap, suddenly my computer starts lagging and the browser closes itself. Or in the case of the Chromium
browser, a lot of tabs will suddenly 'die'.
For this reason, referencing /dev/disk/by-uuid/
in your /etc/crypttab
might seem to be working for a while, but as soon as your swap space is actually used, it will overwrite the UUID
because the entire partition is used for encrypted data storage.
Easy Fix
The easy fix is to reference the swap partition by device in your /etc/crypttab
, e.g.:
cryptswap1 /dev/sda5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
Warning: this is probably safe on a laptop (I use it like this), but if you are on a desktop with swappable drives or have other reasons for changing the drive/partition layout, you don't want to do this, as a normal storage partition might suddenly be used for swap.
Note: You need to reboot for this change to take effect, because only when booting will /dev/mapper/cryptswap1
be created.
Proper Fix
The proper way to fix this is to make sure the part of the raw partition that stores the UUID
is not overwritten by encrypted swap data, so it will still be there on reboot. However, I'm not sure where the UUID
is written and how much bytes it takes up. You could, at your own risk, test it like so:
cryptswap1 UUID=abe3c568-c8fd-4dfb-b8e9-0520d442dd61 /dev/urandom swap,offset=36,cipher=aes-cbc-essiv:sha256
Note the offset=36
.
Please if you have an Ubuntu One account log in and go to Bug #1310058 on Launchpad and choose (or click here): "This bug affects me too" so the bug will gain 'popularity' and is more prone to get fixed.
Update 2014-10-27
I also stumbled upon this. Not verified by me. It looks like offset
trick with more verbosity and comments about rebuilding a broken swap.
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1310058/comments/22
Best Answer
Solution: the problem was in
/etc/initramfs-tools/conf.d/resume
where was still some wierd old UUID. After replacing with the new one and invokingsudo update-initramfs -u
it works now!Maybe if I just did these steps, it would work:
/dev/mapper/cryptswap1
in/etc/fstab
and enable the line with UUID under the# swap was on /dev/sda5 during installation line
(= enabling swap with no encryption)/etc/crypttab
/etc/initramfs-tools/conf.d/resume
in order to contain the swap's UUID from/etc/fstab
sudo update-initramfs -u