The disk drive for /dev/mapper/cryptswap1 is not ready yet or not present

I can confirm this on Xubuntu 13.04 x64 with latest updates..

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

For affected people looking for a workaround--this procedure might work, as it is for the same or a very similar problem:

http://punygeek.blogspot.com/2012/10/ubuntu-1204-how-to-solve-disk-drive-for.html
http://askubuntu.com/a/342002/22949

Confirming error message for Ubuntu 13.04, Xubuntu 13.04 & Xubuntu 13.10.

I've gotten to the bottom of this, and in the process figured out why I was never able to reproduce it in a VM.

Basically, because random-crypted swap (as set up by the ecryptfs helper in ubiquity) is a raw, randomly-keyed block device, there is no UUID on the container device - which means blkid will never return any useful information about the partition, so /etc/init/cryptsetup-udev.conf will never trigger for such a swap device.

As a result, the swap device is only set up once /etc/init/cryptsetup-enable.conf triggers, which only happens after all hardware has been probed and udev has settled. Depending on hardware this can easily take more than 3 seconds, which is long enough for mountall's "idle" trigger to fire and ask the user whether to keep waiting.

So the only way to fix this is to fix cryptsetup to create an actual container for random-crypted swap, so that this can be detected by udev sooner and we avoid the timeout.

This is arguably a good idea anyway, because there is a small but non-zero chance of a completely-random use of the space matching a signature for a real filesystem type and causing confusion. So it would be better for cryptsetup to use LUKS encapsulation even for random-encrypted devices, but this is currently not supported.

a temporary solution:

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1186811

This error is stored on ubuntu 14.04. More information can be found in the duplicate bug numbered Bug # 1305961

On Thu, Apr 10, 2014 at 05:11:38PM -0000, Tamir wrote:
> This error persists on ubuntu 14.04

We know. This issue has already been triaged, that's why your bug has been
marked as a duplicate.

Well, wait like everyone the fixes

On my Ubuntu 12.04 is the same bug.

And here when I press "Also affects project" it says:

"A bug may need fixing in more than one project. You may add another project for this bug here. (?)

Bug #1153661: The disk drive for /dev/mapper/cryptswap1 is not ready yet or not present"

It need some other project? Sorry, I don't understand.

Three comments:

* affects me on Ubuntu 14.04
* the Puny Geek workaround did not help in my case - did not persist across system reboot
* using the swap partition path (/dev/sdaX, as hinted in http://askubuntu.com/questions/289858/disk-drive-for-dev-mapper-cryptswap-1-is-not-ready?rq=1) instead of UUID did help

On 14.04 I tried all suggested solutions: Puny Geeks step-by-step (see http://punygeek.blogspot.com/2012/10/ubuntu-1204-how-to-solve-disk-drive-for.html), then again but using /dev/sda8 (swap partition in my case) instead of UUID, then the approach with noauto parameter in fstab and the 5 second delay in rc.local (both see http://askubuntu.com/questions/289858/disk-drive-for-dev-mapper-cryptswap-1-is-not-ready) but none worked cross reboots.

One thing I find striking is that now:

~$ sudo swapoff -a
~$ sudo swapon /dev/mapper/cryptswap1
swapon: /dev/mapper/cryptswap1: lezen van kop van wisselgeheugen is mislukt: Ongeldig argument

... which means something like "reading of swap header failed: Invalid argument"...

And it turns out after all this I cannot even reformat or recreate the swap partition in gparted. I get some kind of warning about being unable to inform the kernel of the changes made...

Starting to regret my choice to encrypt the home partition during install :(

I am too facing the problem on 14.04, worked fine in 12.04.2.
I reverted back to normal swap partition which works fine for me, but encrypted one doesn't work.

The issue arises from using UUID to identify encrypted swap space: that is not supported, as stated at section 2.3 of the cryptsetup FAQ (https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#2._Setup):

"Specifying it directly by UUID does not work, unfortunately, as the UUID is part of the swap signature and that is not visible from the outside due to the encryption and in addition changes on each reboot with this setup."

Just use disk IDs in /etc/crypttab and reboot,

$ more /etc/crypttab
cryptoswap /dev/sdaX /dev/urandom swap,cipher=aes-cbc-essiv:sha256

Bear in ming though the disk ID may change if you multiple disk in the system!

The workaround in #16 did not work for me.
However, using the swap that is not encrypted works.

I can confirm that #16 worked for me. I had the UUID in /etc/crypttab and the swap was not mounted on startup, but after replacing the UUID by /dev/sdXX swap is being mounted :)

I also want to confirm that the UUID for the swap partition is new every time, so I have a question: why the file /etc/initramfs-tools/conf.d/resume stores a nonexistent UUID value? What it is used for? May be it is for unencrypted swap with a persistent UUID?
cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=add26f99-1c00-43a1-bae5-f184754d242b

By the way, thank you Sm17H for the explanation!

Unfortunately, replacing UUID's by /dev/xxxx will not work if you boot from USB. Example: I boot external usb drives and usb sticks for testing etc. If I boot with one plugged in, the /dev/sdxx will change. See
 #953875 comments 10 & 11:

<https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/953875/comments/10>
<https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/953875/comments/11>

Workaround #16 worked for me after the first reboot, but mysteriously stopped working after a second reboot. Has anyone had the same?

Same here regarding Workaround #16, it worked only once. Weird.

Still there on clean 14.04 Ubuntu Server setup (auto partitioning with LVM and encryption)

Workaround #16 only worked the first reboot. Afterwards not any more. Since then I just do the following steps everytime I reboot (I know this can probably be automated, but I am really hoping this bug gets fixed soon).

  gparted -> reformat linux-swap

  sudo mkswap /dev/sdaX

  sudo swapon /dev/sdaX

  sudo ecryptfs-setup-swap

  test -> swapon -s

I'm using Xubuntu 14.04 LTS, installed via minimal install CD and booted from hard drive, not USB. I tried the workaround mentioned here https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1301383/comments/6 , one try adding offset=8 to the script, another replacing the UUID reference with my swap partition, /dev/sda5 (not both at once), and neither worked (even on first reboot), still get the message on startup. Both attempts had in common that fdisk -l showed this:

Disk /dev/mapper/cryptswap1 doesn't contain a valid partition table

and swapon -a showed this:

swapon: /dev/mapper/cryptswap1: read swap header failed: Invalid argument

Reverting to unencrypted swap worked.

More info, hope it helps:

With the default setup script with no changes, I get the error message on boot and gparted shows /dev/sda5 as "unknown", not "linux-swap". This is before reverting to unencrypted swap. After uncommenting the UUID line and removing the cryptswap1 line in /etc/fstab, removing the entry in /etc/crpyttab, and rebooting, I get a different error on boot saying the disk at UUID=..number.. can't be mounted, instead of the /dev/mapper/cryptswap1 error. Reformatting swap and rebooting fixes this.

With offset=8, I still get the /dev/mapper/cryptswap1 error on boot, but gparted shows /dev/sda5 as "linux-swap", not "unknown". Reverting /etc/fstab and /etc/crypttab as above and rebooting results in no error and a working unencrypted swap with no need to reformat it.

I tried offset=16 with the same results as offset=8. Also tried replacing UUID with $swap in the script, with no offset, offset=8 and offset=16, with no luck.

Hello.

I'm using Kubuntu 14.04.1 and I've got this message each time i'm booting :

« Le lecteur de disque de /dev/mapper/cryptswap1 n'est pas encore pret ou n'est pas présent

Continuer pour attendre; ou appuyer sur S pour passer ou M pour une récupération manuelle »

I'm crypting my home partition.

I have tried all of the posted attempts to work around this bug to no avail! It's affected me since early versions of 12.04 - I'm now using 14.04.

I note that the UUID of encrypted /swap is incorrectly identified in /etc/fstab as well as in /etc/crypttab.

On my system, installed from a thumb drive (seems to be a common thread), I see no "resume" file, i.e.,
    /etc/initramfs-tools/conf.d/resume

A pointer to how to rid myself of this nuisance and just live with a non-encrypted /swap would be very useful!

Better? A bug fix. I'm sure that many who do not look at bug reports must be afflicted by this annoying bug.

/Roger

You can manually fix both /etc/crypttab and /etc/fstab, either using the correct UUID or using the partion identifier (e.g. /dev/sda3). What I did to fix the mentioned error message is editing /etc/rc.conf and adding a `wait 1` before the return 0. This instructs the init demon to wait a second before resuming boot, this should give it enough time to initialise the cryptswap. You might want to increase the time, based on your system's io speed.

If you want to go to a plain (none-encrypted) swap, you can create it on the terminal with
    sudo mkswap <path to partion>
e.g.
    sudo mkswap /dev/sda3

Be aware this command destroys the content of that partition! The command will also display the UUID of the newly created swap partition, so you can update your fstab accordingly.

@linux-rog: Oh, yes. I could click the button "Yes, it affects me" a few times for all the other people who complain at me.

I have written a short shell script I run every time when I need to fix this issue:

     #!/usr/bin/env bash

     mkswap /dev/sda2 -U [UUID from /etc/crypttab] -L swap
     swapon /dev/sda2
     ecryptfs-setup-swap
     swapon -s

It works, but has the disadvantage that everytime it is called, a new entry is created in both /etc/fstab and /etc/crypttab. But they do not work anyway.

Re #28 - Jan:

I have no /etc/rc.conf. There is one in /etc/init but it does not end with a return 0.

Regarding a plain vanilla /swap: the suggested approach I like BUT would not some script somewhere attempt to create the encrypted swap and still cause an error message? How to avoid that?

Approach #29 seems less desirable if I can either correct the cryptswap problem or use clean approach w/ no errors creating an unencrypted /swap.

Thanks to Sebastian and Jan for thinking on this.

Sorry, my fault. The file you need is /etc/rc.local.

On 05/20/2015 02:52 AM, Jan Henke wrote:
> You can manually fix both /etc/crypttab and /etc/fstab, either using the
> correct UUID or using the partion identifier (e.g. /dev/sda3). What I
> did to fix the mentioned error message is editing /etc/rc.conf and
> adding a `wait 1` before the return 0. This instructs the init demon to
> wait a second before resuming boot, this should give it enough time to
> initialise the cryptswap. You might want to increase the time, based on
> your system's io speed.
>
> If you want to go to a plain (none-encrypted) swap, you can create it on the terminal with
> sudo mkswap <path to partion>
> e.g.
> sudo mkswap /dev/sda3
>
> Be aware this command destroys the content of that partition! The
> command will also display the UUID of the newly created swap partition,
> so you can update your fstab accordingly.
The wait did not do it for me. After trying many different methods, I trashed
the encryption of /swap and just use unencrypted swap - on two different laptops.

Thanks for your effort.

/Roger

Can't reproduce this bug now in VirtualBox with Ubuntu 16.04 x64

Can't reproduce it on real hardware with Ubuntu 16.04 x64 also