swapon: stat of /dev/mapper/cryptswap1 failed: No such file or directory
Solution 1:
I had the same issue when trying to set up my encrypted swap space and think I've come to a solution. To get started here's a couple links that I used in my research:
- Simple How-To encrypt swap space with ecryptfs (when everything works right)
- Debugging Blog post that debugs a very similar problem in depth. I got a lot of my ideas from here, so I'd recommend giving it a read.
Problem Setup
When I ran ecryptfs-setup-swap the first time (note that I had already set up swap space when I installed, so I didn't need to do the mkswap , I got an error message saying the swap space could not be mounted properly.
$ sudo ecryptfs-setup-swap
[sudo] password for isaac:
WARNING:
An encrypted swap is required to help ensure that encrypted files are not leaked to disk in an unencrypted format.
HOWEVER, THE SWAP ENCRYPTION CONFIGURATION PRODUCED BY THIS PROGRAM WILL BREAK HIBERNATE/RESUME ON THIS SYSTEM!
NOTE: Your suspend/resume capabilities will not be affected.
Do you want to proceed with encrypting your swap? [y/N]: y
INFO: Setting up swap: [/dev/nvme0n1p5]
WARNING: Commented out your unencrypted swap from /etc/fstab
marking GPT swap partition /dev/nvme0n1p5 as no-auto...
swapon: stat of /dev/mapper/cryptswap1 failed: No such file or directory
I tried to run the command again and got a message stating that I no longer had any swap space.
$ sudo ecryptfs-setup-swap
INFO: You do not currently have any swap space defined.
You can create a swap file by doing:
$ sudo dd if=/dev/zero of=/swapfile count=130667600
$ sudo mkswap /swapfile
$ sudo swapon /swapfile
And then re-run /usr/bin/ecryptfs-setup-swap
Double checking the error message from the first run of the ecrypt command, it does appear that /dev/mapper/cryptswap1 does not exist.
$ ls /dev/mapper/
control
Investigating Relevant System Files
Based on the previously mentioned blog post, I decided to start hunting around in my system files for evidence as to why the swap space wasn't being identified. The blog mentions that the changed naming schemes of hard drive partitions causes issues for ecryptfs and that switching over to using a UUID based identifier is more consistent.
$ blkid
/dev/nvme0n1p5: UUID="aea96d7f-e091-460b-95fd-a34ab884d440" TYPE="swap" PARTUUID="0a7db4e0-17bf-40e3-8675-afec7891afc5"
/dev/nvme0n1p1: LABEL="ESP" UUID="C291-E533" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="63fc7fb9-2ca5-422b-90c7-0db698acdb3c"
/dev/nvme0n1p3: UUID="16F4C1EEF4C1D063" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="c04d0838-5570-4bfc-a961-4b9224b8cc0c"
/dev/nvme0n1p4: UUID="0EEE7736EE7714E5" TYPE="ntfs" PARTUUID="4dc6595f-cc9c-4d80-99ab-ffd9cbe3c1d7"
/dev/nvme0n1p6: UUID="8b2f5c94-db79-4c8d-b5c6-403d912bc0dd" TYPE="ext4" PARTUUID="e373c83f-f992-4e62-a235-1fdd01ac7cf0"
Notice that my swap space is /dev/nvme0n1p5 and has the UUID aea96d7f.... Now I'll take a look /etc/fstab and /etc/crypttab to see what the swap configuration looks like.
$ 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/nvme0n1p6 during installation
UUID=8b2f5c94-db79-4c8d-b5c6-403d912bc0dd / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=C291-E533 /boot/efi vfat umask=0077 0 1
# swap was on /dev/nvme0n1p5 during installation
#UUID=aea96d7f-e091-460b-95fd-a34ab884d440 none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw 0 0
$ cat /etc/crypttab
# <target name> <source device> <key file> <options>
cryptswap1 UUID=aea96d7f-e091-460b-95fd-a34ab884d440 /dev/urandom swap,offset=1024,cipher=aes-xts-plain64
There are a couple things worth noting here, so I'll go through them one at a time.
- ecryptfs seems to have properly modified my
fstabto disable my old swap space (commented out line with the swap UUID) and enable the encrypted one. - The crypttab is set up with the appropriate UUID to map to my swap space. This is a big deal, if your crypttab is set up with something besides a UUID (say, the name of the drive in /dev), it's possible that the kernel could rename the drive and cause issues (again, see the blog for details). In my case, ecryptfs seems to have set up the entry properly using a UUID (my guess is that it is patched on 16.04 as the blog mentions the problem on 14.04).
- The crypttab specifies an offset for the drive. Again, this is a subtle "gotcha" mentioned in the blog, but if the offset is not present, it can apparently cause your drive to lose it's UUID because it will get encrypted.
Finally, I checked swapon to see if it's finding any swap space.
$ swapon -s
Filename Type Size Used Priority
/dev/dm-0 partition 31248892 0 -1
Looks like it is pointing to a swap space (of the correct size) but that swap space is not being properly set up within /dev/mapper (as referenced by fstab).
Solution
Following the suggestions in the blog post, I decided to see if simply restarting the cryptdisks service would solve the issue.
$ swapoff -a
$ /etc/init.d/cryptdisks start
$ swapon -a
$ swapon -s
Filename Type Size Used Priority
/dev/dm-0 partition 31248892 0 -1
$ ls -l /dev/mapper/
total 0
crw------- 1 root root 10, 236 Jan 9 11:30 control
lrwxrwxrwx 1 root root 7 Jan 9 12:28 cryptswap1 -> ../dm-0
At this point it seems like my swap space is configured properly. Running htop shows the appropriate amount of swap space and the diagnostic commands that I was using above are all coming out positive, notably blkid now shows /dev/mapper/cryptswap1.
$ sudo blkid
/dev/nvme0n1p1: LABEL="ESP" UUID="C291-E533" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="63fc7fb9-2ca5-422b-90c7-0db698acdb3c"
/dev/nvme0n1p3: UUID="16F4C1EEF4C1D063" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="c04d0838-5570-4bfc-a961-4b9224b8cc0c"
/dev/nvme0n1p4: UUID="0EEE7736EE7714E5" TYPE="ntfs" PARTUUID="4dc6595f-cc9c-4d80-99ab-ffd9cbe3c1d7"
/dev/nvme0n1p5: UUID="aea96d7f-e091-460b-95fd-a34ab884d440" TYPE="swap" PARTUUID="0a7db4e0-17bf-40e3-8675-afec7891afc5"
/dev/nvme0n1p6: UUID="8b2f5c94-db79-4c8d-b5c6-403d912bc0dd" TYPE="ext4" PARTUUID="e373c83f-f992-4e62-a235-1fdd01ac7cf0"
/dev/mapper/cryptswap1: UUID="113abaa7-c122-4d47-a826-181ee6a29627" TYPE="swap"
The settings persisted through reboot and everything seems to be running ok, so as far as I can tell, this worked. Hopefully this helps.
Potential alternate solution
To make sure that my answer was working appropriately, I tried to replicate the problem on an EC2 instance. I had the same behavior where running sudo ecryptfs-setup-swap where it would error trying to run swappon. However, for some reason the device mapping /dev/dm-0 did not seem to be set up properly. The /etc files seemed to be ok, so I tried simply rebooting the instance. This appeared to work just fine; however, I'd recommend at least inspecting the appropriate config settings before rebooting to make sure that they are set up correctly so the kernel can mount the swap when you reboot.
Solution 2:
Simple reboot fixed this problem for me.