在全新安装的 Ubuntu 14.04 中，我在启动过程中收到此错误消息
/dev/mapper/cryptswap1 的磁盘驱动器尚未准备好或不存在
并且交换分区从未被激活。从我目前的搜索中我发现：
- 这是一个普遍存在的问题，可能影响每个激活了加密交换的 Ubuntu 14.04 安装。
- 部分问题是一个易于修复的错误，导致加密的交换头（在启动期间生成）覆盖未加密的交换头，这使得在下次启动时无法再次找到正确的分区。
- 所有建议的解决方案似乎都只是简单的变通方法，具体如下：1. 通过在 fstab 中将 swap 设置为 noauto 来禁用 swap。2. 创建一个 /etc/rc.local 文件（或定义要在启动期间激活的自己的服务），以激活 swap 分区。
不使用这种黑客手段，是否可以在 Ubuntu 14.04 上使用加密交换？我很乐意更新所有已安装的软件包并修复那些配置文件，这些文件由于安装脚本错误而被初始化为错误内容。我宁愿避免使用自己的脚本来激活交换，因为这种方法在软件包更新时容易失效。
这就是我的/etc/crypttab样子：
cryptswap1 /dev/sda6 /dev/urandom swap,cipher=aes-cbc-essiv:sha256,offset=16
我的相关内容/etc/fstab如下：
/dev/mapper/cryptswap1 none swap sw 0 0
到目前为止我已经尝试过：
我已经发现即使尝试了各种选项后，消息 /dev/mapper/cryptswap1 的磁盘驱动器仍未准备好或不存在询问可能出现相同情况的情况。
但唯一的答案是建议使用未加密的交换。
我已经发现http://ubuntuforums.org/showthread.php?t=2200995据称有一个解决方案，但这个解决方案对我来说毫无意义。
建议的解决方案的第一部分是使用 mkswap 重写加密的交换标头。但是，由于此标头使用密钥加密，因此在重新启动后不会持久，因此此步骤不会帮助交换在下次重新启动后正常工作。
它还建议更新 /etc/fstab，但看起来我的 fstab 已经正确了。
这篇文章假设使用 LVM，但我没有使用。我不知道有什么方法可以产生影响。
我已经发现https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1310058这帮助我理解了交换头被覆盖的问题，并且添加offset和crypttab重新生成未加密的交换头可以解决这个问题。
然而，覆盖的标题并不是唯一的问题，还有另一个问题，我还不完全了解。
我发现的有关该问题的其他信息：
通过阅读/lib/cryptsetup/cryptdisks.functions我了解到，在启动期间，应该使用名称创建设备，cryptswap1_unformatted然后写入加密的交换头，并将设备重命名为cryptswap1。在内核日志中，我发现此错误消息：
[ 39.419429] device-mapper: ioctl: Unable to change name on mapped device cryptswap1_unformatted to one that already exists: cryptswap1
令人困惑的是，结果是设备最终确实有名称cryptswap1，但swap标题从未被写入。
在执行文件系统检查的启动过程中，交换功能可以正常工作。只有当没有执行文件系统检查时，我才会遇到可怕的cryptswap1 is not ready yet错误。
我/var/log/upstart/cryptdisks.log发现错误信息
Device cryptswap1_unformatted already exists.
然而，通过向 添加一些额外的日志记录，我了解到和/lib/cryptsetup/cryptdisks.functions之间存在竞争。我添加到 的任何日志记录都会影响两个脚本的操作如何交错，有时，它最终会起作用。/etc/init.d/cryptdisks-early/etc/init/cryptdisks.confcryptdisks.functions
显然，这两个脚本不应该同时处理同一设备。如何才能将这两个脚本序列化，以便 swap 在每次启动时都能正常工作？
答案1
cryptswap1为了在 Ubuntu 14.04 中正常运行，必须解决两个独立的问题。
问题 1：交换头被覆盖
该分区最初已使用未加密的交换头格式化，用于在启动期间查找要使用的正确分区。由于加密密钥在每次启动时都会更改，因此加密的交换头将在每次启动时被重写。由于 生成过程中存在错误/etc/crypttab，加密的交换头会覆盖未加密的交换头。这将导致在以后的所有启动中都找不到交换分区。
问题 2：启动过程中的竞争条件
/etc/init.d/cryptdisks-early在和之间启动时，存在竞争条件/etc/init/cryptdisks.conf。两者都将同时尝试激活 中列出的所有设备crypttab。在加密交换的情况下，竞争条件的结果大多数情况下是它根本不起作用。某些健全性检查失败导致跳过加密交换标头的写入，以防止潜在的数据丢失。
修复并解决问题
第一个问题很容易解决。第二个问题可以解决。/etc/crypttab识别交换线。它应该看起来像这样（除了 UUID 会有所不同）：
cryptswap1 UUID=f9a0f20c-fac4-408c-a8b9-47300216f727 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
在我的情况下，这是 中的唯一一行/etc/crypttab。要修复交换标头的覆盖，必须添加偏移量。消息来源对使用什么是正确的值存在分歧，但使用太大的值不会有什么坏处。我使用 的偏移量让它工作了16。
另外，我添加了noearly导致/etc/init.d/cryptdisks-early忽略此行的内容，这样就可以解决竞争条件问题。
结果行如下所示：
cryptswap1 UUID=f9a0f20c-fac4-408c-a8b9-47300216f727 /dev/urandom swap,cipher=aes-cbc-essiv:sha256,offset=16,noearly
这将防止未加密的交换头再次被覆盖，但我们仍然需要在分区上重新创建它。在这一步，使用正确的分区至关重要，因为使用错误的分区将要导致数据丢失。我曾经fdisk -l找到正确的分区，在我的例子中是/dev/sda6。
现在用来mkswap重写未加密的交换头。
mkswap /dev/sda6 -U f9a0f20c-fac4-408c-a8b9-47300216f727
UUID 是交换分区被覆盖之前的 UUID（您仍可以在 中看到/etc/crypttab）。完成此操作后，需要重新启动，然后一切就应该正常了。
验证操作是否正确
我建议重新启动三次以验证它是否继续工作。
错误消息the disk drive for /dev/mapper/cryptswap1 is not ready yet or not present在启动过程中短暂显示。但这似乎不是问题，因为它在启动过程完成之前就准备好了。
登录并输入cat /proc/swaps以查看交换是否处于活动状态。您应该看到一个交换分区，其名称/dev/dm-0为，dm表示它确实在使用提供加密的设备映射器层。