6
  • 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?

1
  • 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, 2013 at 2:58

4 Answers 4

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!

1

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:

  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 # add 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.

2
  • 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. Jul 14, 2014 at 23:33
  • You should at least warn people that /dev/sd* paths can change on a whim and lead to the wrong partition being destroyed by swap data. /dev/disk/by-id is superior. May 30, 2016 at 20:53
1

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

Basically:

  1. Open fstab:

    sudo gedit /etc/fstab
    
  2. Change this line:

    /dev/mapper/cryptswap1 none swap sw 0 0
    

    to this:

    /dev/mapper/cryptswap1 none swap sw,noauto 0 0
    
  3. 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
1

Just use an unencrypted swap

... and keep /home encrypted

I tried a couple of the other solutions suggested here. Even though they kept worked after a hot reboot, eventually they all failed after a shutdown and cold restart.

This tells us we are actually dealing with a double bug:

  1. The UUID of the swap drive gets overridden by the encryption system, and
  2. There is a timeout issue during booting.

These thoughts are also reflected in the comments to the pertaining bug filed at Launchpad. However, with the pending move from Upstart to systemd, little is done to resolve the bug on current LTS systems.

At this point, the following thoughts crossed my mind:

  1. During system installation, I asked to only encrypt my \home partition, nothing else.
  2. The risks involved with not having encrypted the swap partition are rather limited.
  3. It is up to Canonical to clean up their act. I will waste no more time with this.

So, here is my solution to restore the swap as a normal, unencrypted swap without having to reinstall the whole operating system.

  1. If you have not done so already, install blkid: $ sudo apt-get install blkid
  2. Edit /etc/crypttab and delete the whole cryptswap1 line: $ sudo nano /etc/crypttab
  3. Start GParted from the system Settings menu.
  4. You will see a partition with an exclamation mark. This should be the faulty swap partition. Carefully select it and reformat it to a linux-swap partition. After having applied this operation, you are informed about the new UUID of the restored normal swap partition. You are offered an opportunity to save this information. If you do not, know that you can always retrieve the new UUID from the command line with blkid: $ sudo blkid
  5. Now, it is time to restore /etc/fstab to its old glory: $ sudo nano /etc/fstab

    • Remove the entire line containing a reference to /dev/mapper/cryptswap1.
    • Uncomment the old swap line by removing the hash # in front of UUID=....
    • Now, replace the old UUID with the new one obtained earlier.
    • Write the file out by hitting Ctrl+O and exit nano with Ctrl+X.
  6. Once done all that, you can already start using the new unencrypted swap with: $ sudo swapon -a
  7. This solution survives both hot reboots and shutdown with cold restart.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .