引导卡住：“启动作业正在运行/dev/mapper/cryptswap1 1”

Question

我在Dell 13 (9360)上使用Ubuntu 19.04，Ubuntu引导被困在以下步骤：

A start job is running for /dev/mapper/cryptswap1

我必须重新启动1或2次，然后才能摆脱它。但是在下面的引导过程中，这种情况一直在发生。

这个问题大概是在将linux内核从5.0.0-16更新到5.0.0-17之后开始的。所以我认为它可能是链接的，所以我尝试用以前的内核版本(5.0.0.0-*，甚至4.15)重新启动，但是我仍然遇到了同样的问题。

自第一次安装(2年前)以来，fstab和crypttab都是未修改的:/etc/

UUID=e15636da-994d-47db-a074-cfccedf6a740 /               ext4    noatime,errors=remount-ro 0       1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=222E-0C93  /boot/efi       vfat    umask=0077      0       1
# swap was on /dev/nvme0n1p4 during installation
#UUID=10aaab21-f2ae-4e25-8f0b-55f444620108 none            swap    sw              0       0
/dev/mapper/cryptswap1 none swap sw 0 0

/etc/crypttab

cryptswap1 UUID=10aaab21-f2ae-4e25-8f0b-55f444620108 /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

我没有主意了。有什么想法吗？

Answer 1

问题不再发生，因为我升级了Ubuntu19.10 (Eoan)到20.04.1 (焦点)。我不知道升级的哪一部分修复了它，但很明显它已经修好了。

Answer 2

在黑暗中刺了两刀。

您能否尝试将/etc/fstab中的交换描述修改为

/dev/mapper/cryptswap1 none swap defaults 0 0

以及在/etc/cryptab中

cryptswap1 UUID=10aaab21-f2ae-4e25-8f0b-55f444620108 /dev/urandom swap,offset=1024,cipher=aes-xts-plain64,size=512

列表的想法是按路径而不是通过UUID引用交换卷，结果如下

cryptswap1 /dev/mapper/whatever--vg0-whatever /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

请不要说它不会是crypt /dev/mapper/cryptswap1 1，因为这是dm-crypt提交加密交换后的设备名。

Answer 3

对我来说很管用

步骤1:创建新的交换分区

步骤2:打开/etc/crypttab文件并将文件中的UUID更改为新交换分区的UUID