Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.
  • I think I had an encrypted swap partition, because I chose to encrypt my home directory during the installation. I believe that's what the line with /dev/mapper/cryptswap1 ... in my /etc/fstab is all about.
  • I did something to bork my swap because on the next boot, I got a message (paraphrased):

    The disk drive for /dev/mapper/cryptswap1 is not ready yet or not present. Wait to continue. Press S to skip or M to manually recover.

    (As a side note, pressing S or M seemed to do nothing different from just waiting.)

  • Here's what I've tried:

    1. This tutorial on how to fix the swap partition not mounting. However, in the above, the mkswap command fails because the device is busy.
    2. So I booted from a live USB, ran GParted to reformat the swap partition (which showed up as an unknown fs type), and chrooted into the broken system to try that tutorial again. I also adjusted /etc/initramfs-tools/conf.d/resume and /etc/fstab to reflect the new UUID generated from formatting the partition as a swap. That still didn't work; instead of /dev/mapper/cryptswap1 not present, "The disk drive with UUID=[swap partition's UUID] is not ready yet or not present..."
    3. So I decided to start afresh as though I never had created a swap partition in the first place. From the Live USB, I deleted the swap partition altogether (which, again showed up in GParted as an unknown fs type), removed the swap and cryptswap entries in /etc/fstab as well as removed /etc/initramfs-tools/conf.d/resume and /etc/crypttab. At this point the main system shouldn't be considered broken because there is no swap partition and no instructions to mount one, right? I didn't get any errors during startup. I followed the same instructions to create and encrypt the swap partition, starting with creating a partition for the swap, though I think fdisk said a reboot was necessary to see changes.
  • I was confident the 3rd process above would work, but the problem yet persists.

  • Some relevant info (/dev/sda8 is the swap partition):

    • /etc/fstab file:

      # /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>
      proc            /proc           proc    nodev,noexec,nosuid 0       0
      # / was on /dev/sda6 during installation
      UUID=4c11e82c-5fe9-49d5-92d9-cdaa6865c991 /               ext4    errors=remount-ro 0       1
      # /boot was on /dev/sda5 during installation
      UUID=4031413e-e89f-49a9-b54c-e887286bb15e /boot           ext4    defaults        0       2
      # /home was on /dev/sda7 during installation
      UUID=d5bbfc6f-482a-464e-9f26-fd213230ae84 /home           ext4    defaults        0       2
      # swap was on /dev/sda8 during installation
      UUID=5da2c720-8787-4332-9317-7d96cf1e9b80 none            swap    sw              0       0
      /dev/mapper/cryptswap1 none swap sw 0 0
      
    • output of sudo mount:

      /dev/sda6 on / type ext4 (rw,errors=remount-ro)
      proc on /proc type proc (rw,noexec,nosuid,nodev)
      sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
      none on /sys/fs/fuse/connections type fusectl (rw)
      none on /sys/kernel/debug type debugfs (rw)
      none on /sys/kernel/security type securityfs (rw)
      udev on /dev type devtmpfs (rw,mode=0755)
      devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
      tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
      none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
      none on /run/shm type tmpfs (rw,nosuid,nodev)
      /dev/sda5 on /boot type ext4 (rw)
      /dev/sda7 on /home type ext4 (rw)
      /home/undisclosed/.Private on /home/undisclosed type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=cbae1771abd34009,ecryptfs_fnek_sig=7cefe2f59aab8e58)
      gvfs-fuse-daemon on /home/undisclosed/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=undisclosed)
      
    • output of sudo blkid (note that /dev/sda8 is missing):

      /dev/sda1: LABEL="SYSTEM" UUID="960490E80490CC9D" TYPE="ntfs" 
      /dev/sda2: UUID="D4043140043126C0" TYPE="ntfs" 
      /dev/sda3: LABEL="Shared" UUID="80F613E1F613D5EE" TYPE="ntfs" 
      /dev/sda5: UUID="4031413e-e89f-49a9-b54c-e887286bb15e" TYPE="ext4" 
      /dev/sda6: UUID="4c11e82c-5fe9-49d5-92d9-cdaa6865c991" TYPE="ext4" 
      /dev/sda7: UUID="d5bbfc6f-482a-464e-9f26-fd213230ae84" TYPE="ext4" 
      /dev/mapper/cryptswap1: UUID="41fa147a-3e2c-4e61-b29b-3f240fffbba0" TYPE="swap" 
      
    • output of sudo fdisk -l:

      Disk /dev/mapper/cryptswap1 doesn't contain a valid partition table
      
      Disk /dev/sda: 320.1 GB, 320072933376 bytes
      255 heads, 63 sectors/track, 38913 cylinders, total 625142448 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
      Disk identifier: 0xdec3fed2
      
         Device Boot      Start         End      Blocks   Id  System
      /dev/sda1   *        2048      409599      203776    7  HPFS/NTFS/exFAT
      /dev/sda2          409600   210135039   104862720    7  HPFS/NTFS/exFAT
      /dev/sda3       210135040   415422463   102643712    7  HPFS/NTFS/exFAT
      /dev/sda4       415424510   625141759   104858625    5  Extended
      /dev/sda5       415424512   415922175      248832   83  Linux
      /dev/sda6       415924224   515921919    49998848   83  Linux
      /dev/sda7       515923968   621389823    52732928   83  Linux
      /dev/sda8       621391872   625141759     1874944   82  Linux swap / Solaris
      
      Disk /dev/mapper/cryptswap1: 1919 MB, 1919942656 bytes
      255 heads, 63 sectors/track, 233 cylinders, total 3749888 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
      Disk identifier: 0xaf5321b5
      
    • /etc/initramfs-tools/conf.d/resume file:

      RESUME=UUID=5da2c720-8787-4332-9317-7d96cf1e9b80
      
    • /etc/crypttab file:

      cryptswap1 /dev/sda8 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
      
    • output of sudo swapon -as:

      Filename                Type        Size    Used    Priority
      /dev/mapper/cryptswap1                  partition   1874940 0   -1
      
    • output of sudo free -m:

                   total       used       free     shared    buffers     cached
      Mem:          1476       1296        179          0         35        671
      -/+ buffers/cache:        590        886
      Swap:         1830          0       1830
      

So, how can this be fixed?

share|improve this question
    
Did you find a solution? I have the same problem. By the way, your resume UUID and swap UUID do not mach, like mine. I tried matching them but the UUID of cryptswap1 keeps changing because the partition is randomly redone at boot. Also, it's perfectly normal to have gparted see the swap as unknown, that's because it's an encrypted partition made with a random key, unrecoverable after reboot. –  user824924 Nov 17 '13 at 2:58

2 Answers 2

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!

share|improve this answer

Short Answer:

1_ 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.

2_ 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 tryint 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 scrypt /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 especulated 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:

1_ 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

2_ sudo mkdir /swap

3_ ls -l /dev/disk/by-uuid/

4_ sudo gedit /etc/fstab # UUID=XXXXXXXXXXXXXXXXXXXXXXXXX /swap ext4 defaults 0 2

5_ sudo mount /dev/sdXX /swap

6_ sudo dd if=/dev/zero of=/swap/swapfile bs=1024 count=800000

7_ sudo mkswap /swap/swapfile

8_ sudo swapon /swap/swapfile

9_ 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.

share|improve this answer
    
What helped for me was, indeed, using the partition name (/dev/sda<n>), instead of the uuid, in /etc/crypttab and, also, add the noearly option in the same entry in /etc/crypttab. Since then, I still get the Wait, Skip, Manually message on boot, but the swap is always activated. –  Decent Dabbler Jul 14 at 23:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.