28

Update 3:

I decided to reinstall the system from scratch to remove any old cruft lying around since I had been experiencing some other issues after the upgrade aswell. Howver, this issue persisted.

On a clean install, choosing to install using "encrypted home" leads to a broken encrypted swap configuration.

Update 2:

I fixed the partioning order that cfdisk complained about, but he issue persists. The swap is now on /dev/sda6, and I can get it up and running as follows:

~$ sudo mkswap /dev/sda6
Setting up swapspace version 1, size = 7998460 KiB
no label, UUID=18881d0f-d9ec-43be-a23f-0cbd78ea6d22

$sudo nano /etc/crypttab # Update crypttad with new UUID

$ sudo /etc/init.d/cryptdisks reload
 * Stopping remaining crypto disks...
 * cryptswap1 (stopped)...                                               [ OK ] 
 * Starting remaining crypto disks...                                        
 * cryptswap1 (starting)..
 * cryptswap1 (started)...                                               [ OK ] 
$ sudo swapon -a

$ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 May 11 09:04 08b07f88-6da5-4b40-b062-42b3bb1c5f00 -> ../../sda3
lrwxrwxrwx 1 root root 10 May 11 09:08 18881d0f-d9ec-43be-a23f-0cbd78ea6d22 -> ../../sda6
lrwxrwxrwx 1 root root 10 May 11 09:04 19aa372c-05c8-4226-8f09-c54e5566e816 -> ../../sda5
lrwxrwxrwx 1 root root 10 May 11 09:04 A800B16E00B143DA -> ../../sda1
lrwxrwxrwx 1 root root 10 May 11 09:04 D28230E68230D129 -> ../../sda2
lrwxrwxrwx 1 root root 10 May 11 09:08 fcc8c419-8fec-4d4d-b55e-9e4c3b04d21d -> ../../dm-0

But after a reboot swap fails to activate and it once again looks like this:

$ ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 May 11 09:12 08b07f88-6da5-4b40-b062-42b3bb1c5f00 -> ../../sda3
lrwxrwxrwx 1 root root 10 May 11 09:12 19aa372c-05c8-4226-8f09-c54e5566e816 -> ../../sda5
lrwxrwxrwx 1 root root 10 May 11 09:12 A800B16E00B143DA -> ../../sda1
lrwxrwxrwx 1 root root 10 May 11 09:12 D28230E68230D129 -> ../../sda2

My guess at the moment is that when setting up the disk as being encrypted linux no longer recognizes the partition type and therefore doesn't load it properly causing it to not register for it's UUID and therefore cryptswap can't find it causing the failure. But I don't know how to fix it..

Updated question:

Further testing revealed that I could get the swap up and running by running $ mkswap /dev/sda5

and then updating /etc/crypttab with the correct UUID and following the steps outlined here: How do I setup an encrypted swap file?

The problem however remains when I reboot the computer, the /dev/sda5 doesn't appear when I run

$ ls -l /dev/disk/by-uuid/

If I do:

$ cfdisk /dev/sda

I get the following error:

FATAL ERROR: Bad logical partition 6: enlarged logical partitions overlap
                      Press any key to exit cfdisk

The graphical "Disks" utility doesn't complain about any error when opening the disk using it.

$ sudo fdisk -l

Disk /dev/sda: 256.1 GB, 256060514304 bytes
255 heads, 63 sectors/track, 31130 cylinders, total 500118192 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: 0x619aebf1

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      206847      102400    7  HPFS/NTFS/exFAT
/dev/sda2          206848   100870143    50331648    7  HPFS/NTFS/exFAT
/dev/sda3       191397888   192397311      499712   83  Linux
/dev/sda4       192399358   500117503   153859073    5  Extended
/dev/sda5       484118528   500117503     7999488   82  Linux swap / Solaris
/dev/sda6       192399360   484118527   145859584   83  Linux

Partition table entries are not in disk order

Original question:

After upgrading to 14.04 (from 13.04) my computer has been experiencing severe slowdowns, when running top i noticed kswap0 taking up alot of cpu time. I also noticed that I didn't have any swap space!

$ sudo swapon -a
swapon: /dev/mapper/cryptswap1: stat failed: No such file or directory

There seems to be some problem with my encrypted swap setup (didn't even know that I had one)

$ cat /etc/crypttab 
cryptswap1 UUID=abe3c568-c8fd-4dfb-b8e9-0520d442dd61 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

$ ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 May  6 11:00 08b07f88-6da5-4b40-b062-42b3bb1c5f00 -> ../../sda3
lrwxrwxrwx 1 root root 10 May  6 11:00 19aa372c-05c8-4226-8f09-c54e5566e816 -> ../../sda6
lrwxrwxrwx 1 root root 10 May  6 11:00 A800B16E00B143DA -> ../../sda1
lrwxrwxrwx 1 root root 10 May  6 11:00 D28230E68230D129 -> ../../sda2

And looking at my fstab

$ cat /etc/fstab
# /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>
# / was on /dev/sda6 during installation
UUID=19aa372c-05c8-4226-8f09-c54e5566e816 /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda3 during installation
UUID=08b07f88-6da5-4b40-b062-42b3bb1c5f00 /boot           ext2    defaults        0       2
# swap was on /dev/sda5 during installation
#UUID=abe3c568-c8fd-4dfb-b8e9-0520d442dd61 none            swap    sw              0       0
/dev/mapper/cryptswap1 none swap sw 0 0

My guess is that there is something wrong the the setup of sda5, but I don't know how to fix it since it is setup up to be encrypted. Would appreciate some help as how to proceed.

Improve this question
7
  • I don't know anything about encrypted partitions, but that first error suggests that the swap partition hasn't been mounted. Also the mounting line for it in the /etc/fstab is commented out. I would try just uncommenting that line and restarting to check if that fixes it
    – Anake
    Commented May 8, 2014 at 10:38
  • I'm quite sure that it is supposed to be commented out and the cryptswap1 line is responsible for mounting it indirectly using the information in /etc/crypttab. Your suggestion would surely mount it in an unencrypted fashion?
    – ajn
    Commented May 8, 2014 at 10:47
  • 1
    Will this work? https://ubuntuforums.org/showthread.php?t=2224129 I am unsure about some of the commands and I don't want to screw up Ubuntu.
    – user282110
    Commented May 15, 2014 at 23:07
  • It looks similiar to what I tried, I would expect it to work for one reboot then stop working again once you've activated the encrypted swap for the first time.
    – ajn
    Commented May 16, 2014 at 6:10
  • For the moment I've just gone back to using regular swap. The main scenario I'm using encryption against is if someone steals my laptop and someone with moderate linux skills decided to poke around to see if they can find something interesting, i.e most likely just try to boot using usb and mount my home partition. I don't have anything that I believe someone would find valuable enough to try to start recovering fragments of it from the swap. It really should be an install option to use encrypted home + regular swap.
    – ajn
    Commented May 16, 2014 at 6:11

5 Answers 5

Reset to default
16

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

Improve this answer
5
  • 5
    I just want to note the bug is being tracked at bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/953875 as of a few days ago (mid March 2015) the status is "fixed released," though that fix only explicitly applies to 15.04. I'm looking to see whether it's being backported to 14.04 LTS... and what the "official" update procedure might be
    – Tommy Trussell
    Commented Mar 13, 2015 at 22:28
  • 1
    @TommyTrussell: Not backporting would be crazy for LTS. Bugs for crucial things like this still open almost a year after release is why even the biggist Linux distros will never be on par with OSX and Windows. Unfortunately.
    – Redsandro
    Commented Mar 14, 2015 at 9:42
  • I am not aware of public discussion of bugs as they are being fixed in OSX and Windows, so how can they be "on par"? In my experience with OSX, bugs get fixed or not; no public discussion, so they are "opaque." I merely mentioned the new bug number (because the one you linked had been marked duplicate) so you could update your reference. As you can see from the discussion at the forum posting mentioned in Bug 953875, the most stable fix might differ depending on the init system, which is changing in 15.04. SO the 14.04 fix may have technical challenges for forward compatibility.
    – Tommy Trussell
    Commented Mar 16, 2015 at 3:54
  • I'm merely saying you'll never see something like "Oh by the way, SWAP is broken" on a system like Windows or OSX. This is the kind of core functionality that would never get RTM before being tested and fixed. That's all. As for security, no public discussions but there's still statistics.
    – Redsandro
    Commented Mar 16, 2015 at 10:26
  • @Redsandro Well, it's a free operating system and stuff like this will only be fixed before release if people discover the bug when testing the release. After release, it's just too risky that making the bug fix will break something else on someone's configuration. It may be fixed in a more recent release however - so it may be worth using that - but interim releases are usually more unstable than LTS releases anyway since the focus is more on general updates. But you did identify why bug testing/fixing/Quality Assurance (QA) is so important and Ubuntu is getting better at that.
    – Ads20000
    Commented Nov 17, 2015 at 9:53
9

I was having the same exact problem in Ubuntu 14.04 and came across this thread; this link that mutant provided worked well for me. I used the /dev/disk/by-id reference rather than the /dev/sdXY, as that reference is not always pointing to the same physical partition. My /etc/crypttab ended up like: 

cryptswap1 /dev/disk/by-id/wwn-0x500...-part6 /dev/urandom swap, cipher=aes-cbc-essiv:sha256
Improve this answer
1
  • 3
    This is the proper & easy fix!
    – Serge Stroobandt
    Commented Apr 27, 2015 at 0:51
7

Just use an unencrypted swap

... and keep /home encrypted

I tried a couple of the other solutions suggested here. Even though they kept working 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 an encrypted 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.
Improve this answer
3
  • 1
    This is the only answer that worked for me, although I tried everything else.
    – fifaltra
    Commented Dec 9, 2015 at 3:14
  • In gparted my swap partition has the boot flag. Will this still work, or will I be left unable to boot up?
    – Christian Skjødt
    Commented Mar 22, 2016 at 14:22
  • @ChristianSkjødt Your swap partition should not have its boot flag set. Anyhow, above procedure would not affect any of that.
    – Serge Stroobandt
    Commented Aug 9, 2016 at 19:38
2

Have a look at this. I fixed this issue by simply replacing UUID=... with /dev/sda3 in /etc/crypttab.

Improve this answer
3
  • 1
    run "sudo fdisk -l" first to check what your swap partition is called, it may be "/etc/sda5" or other, then edit cryptab as described by mutant. This worked for me and survives a reboot. This is definitely a bug as I got this problem with a fresh install on a new SSD. I did go for the "encrypt home directory" option at install, much better to encrypt /home after installation, especially if you are copying over files from an old /home from a previous installation.
    – Paul Williams
    Commented Oct 20, 2014 at 11:19
  • The sudo fdisk -l was something nobody was telling. Thanks for this! :)
    – Aman Aalam
    Commented Dec 23, 2014 at 7:36
  • 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.
    – underscore_d
    Commented May 30, 2016 at 20:52
0

I have this problem, as did the people in question 332625. Some combination of suspend and reboot loses the UUID of your swap partition (as the comment in your /etc/fstab says, confirm this with sudo blkd), so the line in your /etc/crypttab to use that UUID as encrypted swap fails.

I'm having no luck switching /etc/crypttab to use the partition's /dev name (/dev/sda6 in your case) or dev/disk/by-id/ name instead of the vanishing UUID.

Abandoning encrypted swap is the easiest and so far best solution, sadly.

Improve this answer
1
  • this issue is very old i wonder why they didn't fixed it already, now i am facing the same problem with my desktop and can't get it running, fixed it on my laptop in the past but can't remember how :(
    – tomasb
    Commented Jul 18, 2014 at 19:28

You must log in to answer this question.

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