Swap partition not recognized (The disk drive with UUID=... is not ready yet or not present)

Solution 1:

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!

Solution 2:

Short Answer:

UUID issue:

You should have this in /etc/crypttab:

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

and this line at the end of /etc/fstab

/dev/mapper/cryptswap1 none swap sw 0 0

Make sure you do not use the uuid in the crypttab file.

Suspend issue:

Now let's use a trick to normalize the behavior of the swap right before reboot or shutdown:

Create a script /etc/init.d/cryptswap.sh with this inside:

#!/bin/bash
/etc/init.d/cryptdisks-early restart

Make it executable with:

sudo chmod +x /etc/init.d/cryptswap.sh

To do things properly, let's use links and numbers to make it execute in the right moment when going for either reboot or shutdown:

cd /etc/rc6.d
sudo ln -s ../init.d/cryptswap.sh S10cryptswap.sh
cd /etc/rc0.d
sudo ln -s ../init.d/cryptswap.sh S10cryptswap.sh

The important thing here is the number 10 in the name because the script should run before the S40 which begins taking down swap; even later, another script will take down the encrypted devices. The point is the original sequence fails and we need the restart to let it go through smoothly.

That's it!

Note: this is a dirty hack, and it may happen that the restart is not able to fix whatever is going on sometimes. Someone among the developers in charge of both swap and/or cryptsetup should go deep and see why, after suspending, the swap is left in a state that makes swapoff /dev/mapper/cryptswap1 and /etc/init.d/cryptdisks-early stop fail. If you run those commands you'll see swapoff complain about the header of the swapfile. Also, you'll see cryptdisks-early sending a "fail" when trying to stop /dev/mapper/cryptswap1.

Redundancy/history:

At first I thought his problem was connected to kernel behavior by libblk, probably a bug (not intended). It seems the problem is having a partition table edited by different "filesystems". The kernel refuses to populate /dev/disk/by-uuid/ because it detects several signatures of filesystems editing the partition table. This seemed important given that the script /usr/bin/ecryptfs-setup-swap uses UUID to reference entries it creates for /etc/crypttab.

The fix should be to recreate all partitions from the same filesystem by booting on some live media. See: http://forums.fedoraforum.org/showthread.php?t=288890

However, this doesn't work because ecryptfs/crypttab "reformats" the swap partition on every boot; you can not see an uuid for the swap partition after running ecryptfs-setup-swap and rebooting, because you are not supposed to. this means that upon boot, the partition wont be found by crypttab if referenced by uuid, as stated in the other answer.

Going on, a possible fix was to give up using uuids and just replace them in /etc/crypttab with a different notation: only /dev/sdXX works because the others are lost when mkswap is run in the crypttab scripts. This is the way the forums suggest to solve the issue. Doing this is required.

That did not work fully though. I speculated that there was some bug in crypttab (/etc/rcS.d/S26cryptdisks-early -> /etc/init.d/cryptdisks-early -> /lib/cryptsetup/cryptdisks.functions). So I went digging there and found nothing. Actually, running /etc/init.d/cryptdisks-early restart works well once booted, the /dev/mapper/cryptswap1 link is generated.

One possible fix I saw at that point, was to move the swap to a "file" which takes all of the space in the swap partition. This is dirty, requires a mount point, etc. The idea is that you would create a file of the size of the entire partition, which would be mounted as a regular ext4 at say /swap, and the use the encrypted file as swap. Something like this:

In GParted format as ext4; notice this will format the partition and generate a new UUID; do not use sudo mkswap /dev/sdXX since the partition will be auto mounted if flagged as swap
sudo mkdir /swap
ls -l /dev/disk/by-uuid/
sudo gedit /etc/fstab # add UUID=XXXXXXXXXXXXXXXXXXXXXXXXX /swap ext4 defaults 0 2
sudo mount /dev/sdXX /swap
sudo dd if=/dev/zero of=/swap/swapfile bs=1024 count=800000
sudo mkswap /swap/swapfile
sudo swapon /swap/swapfile
sudo ecryptfs-setup-swap

But I hated it, so I did not try it.

Another possible fix I saw was to set up manually giving up the automated random key generation, like this: http://wiki.drewhess.com/wiki/Creating_an_encrypted_filesystem_on_a_partition#External_links

After exploring a bit the manual venue, I somehow fixed things by doing what /usr/bin/ecryptfs-setup-swap does first (check it out to see how it works, it just edits /etc/crypttab and /etc/fstab) and then manually running the script that run on boot: /etc/init.d/cryptdisks-early restart; But it broke again. Rethinking about the resume issue, I found the pattern. It breaks on the reboot that follows a suspension, and stays broken. To refix it, one has to do:

sudo /etc/init.d/cryptdisks-early restart

After that, the swap is mounted successfully and without worning as long as you do not suspend. This is where the script proposed in the short answer comes from.

Solution 3:

I had the same problem and I found a solution that worked for me in this post.

Basically:

Open fstab:
```
sudo gedit /etc/fstab
```

Change this line:

/dev/mapper/cryptswap1 none swap sw 0 0

to this:

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

Then go to

sudo gedit /etc/rc.local

and immediately before

exit 0

add these two lines:

 sleep 5
 swapon /dev/mapper/cryptswap1

If you then want to check your SWAP is actually mounted and working open a lot of RAM-consuming applications and check it via terminal typing:

free -m