Xubuntu 18.04内核启动时间长。

Question

从17.10升级后，我发现启动时间变长了。起初需要超过5分钟。通过dmesg命令，我发现罪魁祸首是一个不存在的软盘驱动器，内核试图寻找它。

及时移除该驱动器后，启动时间缩短到约40秒，但我觉得比更新前还要长。再次运行dmesg显示挂载文件系统需要30秒（完整输出），并显示以下信息：

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

我正在使用SSD启动，还连接了两个其他的硬盘，其中一个格式为ext4，但没有存储系统数据。我猜这是SSD。在这30秒钟中，屏幕上没有显示任何文本，也没有闪屏，只是一个空白屏幕。

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

编辑1：

打开或关闭交换对速度没有任何影响。

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

[    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中那样。它似乎是...随机的。

- Jes Wanson

---

你能运行 systemd-analyze blame 命令并将其输出编辑到你的问题中吗？ - vidarlo

我之前已经运行过它，结果的总和在8-9秒之间，所以我认为这是无关紧要的。我已经添加了结果。 - Jes Wanson

Answer 1

我遇到了同样的问题。在启动消息中，它会显示超时等待恢复设备。检查 /etc/initramfs-tools/conf.d/resume 中是否有像 RESUME=some-uuid 这样的 UUID，将其删除并替换为 "none"，即 RESUME=none。然后运行 sudo update-initramfs -uk all，问题应该就解决了。

- Alex

---

终于！这解决了我花了无数小时研究的问题 - 现在我的启动时间减少了一半。关于这份简历的有用信息，请参考：https://askubuntu.com/questions/1057556/how-does-etc-initramfs-tools-conf-d-resume-work - Casperrw

这对我也有效，之前启动需要大约38秒，现在只需8秒。 - Pablo Pazos

问题在我进行从16.04升级到18.04的发行版升级后出现了 - 这种方法也使我摆脱了30秒的延迟。 - Bonlenfum

谢谢！几个月来，启动时间太长了，而且没有任何解决办法。根据您的建议，我发现我的RESUME=条目指向了我在/etc/fstab中注释掉的交换分区。将RESUME=none设置后，问题似乎得到了解决。这也可能解决了我的笔记本电脑“进入恢复状态”的问题（非常奇怪-刚启动后它又“关机”/恢复了）。 - Gerd

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$

正如您所见，在fstab中，我的/dev/sda7交换空间的UUID与blkid中的UUID不同。在我的情况下，这是由另一个Linux安装重新分区交换空间导致的，从而改变了UUID。启动延迟是系统尝试查找交换空间的新UUID所导致的。要修复它，只需将blkid中不匹配的UUID复制到fstab文件中，然后保存。

如果在重新启动后仍然出现启动错误，您还需要编辑initramfs.conf文件。

操作步骤如下：

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

然后，要么创建一个新文件，要么编辑当前的简历文件，在第一行写上 RESUME=UUID=<<交换的UUID>>

例如，我的看起来像这样

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

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

#sudo update-initramfs -u

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

- Andrew

---

我宁愿使用sudo update-initramfs -u -k all而不是sudo update-initramfs -u，以考虑到所有已安装的内核。 - DJCrashdummy

Answer 3

我在Ubuntu 19.04上删除交换分区并创建交换文件后，遇到了启动时间缓慢的问题。

dmesg的输出结果。

[    2.220963] hid-generic 0003:1B1C:1B0F.0003: input,hidraw2: USB HID v1.11 Device [Corsair Corsair M45 Gaming Mouse] on usb-0000:00:14.0-1/input2
[   33.321639] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)
[   33.407323] systemd[1]: RTC configured in localtime, applying delta of 120 minutes to system time.
[   33.417651] systemd[1]: Inserted module 'autofs4'

在/etc/fstab中没有交换文件。所有挂载的磁盘/uuid都是正确的。

我检查了/etc/initramfs-tools/conf.d/resume，但那个文件已经丢失了。

我刚刚运行了

sudo update-initramfs -uk all

现在它启动得非常快速。

- Vlastimil Sadílek

Answer 4

我遇到了类似的引导时间增长问题，经过使用"dmesg"和"systemd-analyze blame"进行调查后，罪魁祸首似乎是"random: crng init"。

问题似乎是由于SSD启动时初始化时的熵不足所致。这个假设似乎得到了确认，因为在启动过程中频繁晃动鼠标会将引导时间从大约2分钟缩短至几乎与之前相同的时间。

- Jay

Answer 5

开机时，内核会等待鼠标移动以初始化随机数生成器。 开机时的内核消息：
sudo dmesg | less

问题：
kernel: random: crng init done

解决方案：
sudo apt install haveged
sudo systemctl enable haveged

- virusmxa