Xubuntu 18.04 内核需要很长时间才能启动

Question

从 17.10 升级后，我经历了更长的启动时间。一开始需要5分多钟。dmesg揭示罪魁祸首是内核试图找到的不存在的软盘驱动器。

及时删除它，5分钟减少到大约40秒，我觉得这仍然比更新前要长。dmesg再次运行显示挂载文件系统需要 30 秒（完整输出），并显示以下消息：

[   36.362834] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

我从 SSD 启动，插入了另外两个硬盘驱动器，其中一个已格式化为 ext4，但不保存系统数据。我认为这是SSD。在这 30 秒内，没有显示任何文本，也没有飞溅，只是一个空白屏幕。

现在，我说感觉比更新之前慢，因为我没有之前的确切时间，所以我的第一个问题是，挂载文件系统需要30秒是否正常，如果不是，如何找到更多关于什么可能导致延迟？

编辑 1：

打开或关闭交换没有任何影响

同时我还在我的电脑上安装了另一个硬盘。它似乎将我的启动时间进一步延长了大约 10 秒，dmesg在前面提到的 30 秒延迟之前，输出中出现了另一行：

[    3.312351] hid-generic 0003:09DA:F613.0005: input,hiddev0,hidraw4: USB HID v1.11 Keyboard [COMPANY USB Device] on usb-0000:00:12.1-1/input2
[   17.169519] random: crng init done
[   51.611617] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

编辑2：

systemd-analyze blame结果在这里

与此同时，经过几次重新启动后，dmesg我上面指责的线路因此改变了它们的时代：

[    3.348384] hid-generic 0003:09DA:F613.0005: input,hiddev0,hidraw4: USB HID v1.11 Keyboard [COMPANY USB Device] on usb-0000:00:12.1-1/input2
[   34.091886] random: crng init done
[   36.488321] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

我将进行几次重新启动，以查明这是随机更改还是保持不变（第一次编辑中的代码块来自插入额外硬盘后的第一次启动）。

编辑 2.5：random: crng init done通常出现在编辑 1 中所示的时间，很少出现在编辑 2 中。它似乎是......随机的。

Answer 1

我有同样的问题。在启动消息期间，它会说等待恢复设备超时。检查其中/etc/initramfs-tools/conf.d/resume是否有 UUID，例如RESUME=some-uuid删除 uuid 并替换为“none” RESUME=none。在那之后运行sudo update-initramfs -uk all，它应该很好去。

Answer 2

我多次遇到这个问题，我的解决方案适用于所有情况。

运行 dsmeg 时，错误显示为：

[    6.382044] random: crng init done
[    6.382048] random: 7 urandom warning(s) missed due to ratelimiting
[   32.162934] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)

解决办法是：

首先比较你的 fstab 和 blkid：

$ blkid
/dev/sda1: UUID="C0C0-7641" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="1085d848-f8b9-45e2-a6be-087acb32a820"
/dev/sda3: LABEL="Windows" UUID="8662302C623022FB" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="de399a3e-c832-4dca-a09d-f65789425b89"
/dev/sda4: LABEL="Windows RE tools" UUID="2262513962511341" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="18feb4e1-5770-4e13-92b8-bb8ba8005536"
/dev/sda5: UUID="81a474ab-98bf-4d40-b03e-e5e647163d7e" TYPE="ext4" PARTLABEL="Arco Linux" PARTUUID="3759200f-6317-4487-8b10-3a0140c67bd5"
/dev/sda6: LABEL="rootMX17" UUID="7bae9e4d-61fa-4187-b11f-517c799f7c94" TYPE="ext4" PARTLABEL="MX Linux" PARTUUID="417c8cbd-11b7-4fe6-9b15-ac9082d74460"
/dev/sda7: UUID="d9539219-1c29-468f-bbd0-106663fdef59" TYPE="swap" PARTLABEL="Swap" PARTUUID="fefe3061-bf7b-4a26-8c20-08e209acc28e"



$ sudo nano /etc/fstab


# /etc/fstab: static file system information
#
# Created by make-fstab on Mon Nov 19 17:10:30 EST 2018

# <file system>                            <mount point>                               <type>     <$

#-> /dev/sda6  label=rootMX17
UUID=7bae9e4d-61fa-4187-b11f-517c799f7c94  /                                           ext4       d$
#-> /dev/sda1
UUID=C0C0-7641                             /boot/efi                                   vfat       d$
#-> /dev/sda7
UUID=42e5a9cd-b6e1-4d57-9a3a-2ad910862579  swap                                        swap       d$

正如您所看到的，我在 /dev/sda7 中的交换在 fstab 中与在 blkid 中具有不同的 UUID。就我而言，这是由另一个 linux 安装重新分区交换并导致 UUID 更改引起的。引导延迟是由系统尝试查找交换的新 UUID 引起的。要修复它，只需复制 blkid 中与 fstab 文件不匹配的 UUID，然后保存。

如果重启后启动错误仍然存​​在，您需要另外编辑您的 initramfs.conf 文件。

这样做：

$ sudo nano  /etc/initramfs-tools/conf.d/resume

然后通过创建一个新文件，或编辑当前恢复文件，在第一行写上 RESUME=UUID=<< UUID of swap>>

例如，我的看起来像

RESUME=UUID=d9539219-1c29-468f-bbd0-106663fdef59

然后运行以下命令来更新您的 initramfs 文件。

#sudo update-initramfs -u

然后重新启动。错误将消失。