结果

Question 1

我遇到了同样的问题，基本上，在禁用和删除虚拟盒内的交换后，UUID 变得混乱。这会导致超时问题和依赖项失败，并强制在每次启动时检查文件系统。我必须相应地更新我的 UUID。

如果交换分区被删除（例如，从 HD 迁移到 SSD 时故意删除），则该文件/etc/initramfs-tools/conf.d/resume应该完全为空或读取RESUME=。删除任何 UUID 编号。RESUME=NONE无效。无论您是否使用交换，修复方法如下：

对于故障排除（可选）：

sudo cat /var/log/boot.log

列出正确的分区 UUIDS：

sudo blkid -c /dev/null -o list

确保以下三个文件具有 blkid 列出的正确 UUID 设置，并使用正确的 UUID 覆盖它们：

/etc/fstab                                      [for me swap was incorrect]
/etc/default/grub                               [for me RESUME=UUID was incorrect]
/boot/grub/grub.cfg                             [for me RESUME=UUID was incorrect]

然后更新初始 Ram 文件系统：

update-initramfs -u

编辑上面的三个文件也永久解决了我cryptsetup: error: couldn't resolve device运行 update-initramfs 时的错误

这应该可以避免将 UUID 添加到的需要/etc/initramfs-tools/conf.d/resume，但是，如果您仍然遇到问题，请考虑添加 UUID，例如：RESUME=UUID=c0198c37-f28b-41f5-bb0f-37d575e86896，或者RESUME=如果您不使用交换文件，则进行设置。

然后运行：

update-initramfs -u

还要确保/etc/default/grub已设置为GRUB_TIMEOUT=0, 以加快启动过程。在我在这里描述的所有内容之后，它在启动时执行了最后一次文件系统检查，但之后它在 10 秒内启动，而不是 1 分 30 秒。

Answer

我遇到了同样的问题，基本上，在禁用和删除虚拟盒内的交换后，UUID 变得混乱。这会导致超时问题和依赖项失败，并强制在每次启动时检查文件系统。我必须相应地更新我的 UUID。

如果交换分区被删除（例如，从 HD 迁移到 SSD 时故意删除），则该文件/etc/initramfs-tools/conf.d/resume应该完全为空或读取RESUME=。删除任何 UUID 编号。RESUME=NONE无效。无论您是否使用交换，修复方法如下：

对于故障排除（可选）：

sudo cat /var/log/boot.log

列出正确的分区 UUIDS：

sudo blkid -c /dev/null -o list

确保以下三个文件具有 blkid 列出的正确 UUID 设置，并使用正确的 UUID 覆盖它们：

/etc/fstab                                      [for me swap was incorrect]
/etc/default/grub                               [for me RESUME=UUID was incorrect]
/boot/grub/grub.cfg                             [for me RESUME=UUID was incorrect]

然后更新初始 Ram 文件系统：

update-initramfs -u

编辑上面的三个文件也永久解决了我cryptsetup: error: couldn't resolve device运行 update-initramfs 时的错误

这应该可以避免将 UUID 添加到的需要/etc/initramfs-tools/conf.d/resume，但是，如果您仍然遇到问题，请考虑添加 UUID，例如：RESUME=UUID=c0198c37-f28b-41f5-bb0f-37d575e86896，或者RESUME=如果您不使用交换文件，则进行设置。

然后运行：

update-initramfs -u

还要确保/etc/default/grub已设置为GRUB_TIMEOUT=0, 以加快启动过程。在我在这里描述的所有内容之后，它在启动时执行了最后一次文件系统检查，但之后它在 10 秒内启动，而不是 1 分 30 秒。

Question 2

mercurial@providence:~$ systemd-analyze
Startup finished in 7.913s (kernel) + 20.621s (userspace) = 28.534s 
graphical.target reached after 20.605s in userspace

这是我纠正了一些问题后所取得的成果。正如您所看到的，启动时间逐渐从 1 分 5 秒减少到 28 秒。

1. sudo update-initramfs -u -k all ：内核时间

这是在大声尖叫，我正试图从一个找不到的设备恢复，即我的系统中有一个恢复块。grub.cfg

cryptsetup: ERROR: Couldn't resolve device 
    UUID=fee92c6d-7b60-4014-a66b-c48cd9094162

这只是一个错误，

cryptsetup: WARNING: The initramfs image may not contain cryptsetup binaries 
    nor crypto modules. If that's on purpose, you may want to uninstall the 
    'cryptsetup-initramfs' package in order to disable the cryptsetup initramfs 
    integration and avoid this warning.

这行漂亮的代码要求我声明新的交换分区，以便我的系统可以从中恢复，

I: The initramfs will attempt to resume from /dev/sda7
I: (UUID=c0198c37-f28b-41f5-bb0f-37d575e86896)
I: Set the RESUME variable to override this.

于是我就这么做了，

mercurial@providence:~$ cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=c0198c37-f28b-41f5-bb0f-37d575e86896

2. systemd-analyze 问题：用户空间时间

我的网络管理员需要一些时间才能上线，所以我所要做的就是屏蔽它。

sudo systemctl mask NetworkManager-wait-online.service

结果

现在我的启动时间已降至 28 秒，以下是我的责任和关键链，

mercurial@providence:~$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @20.605s
└─udisks2.service @9.969s +10.636s
  └─basic.target @9.515s
    └─sockets.target @9.515s
      └─dbus.socket @9.515s
        └─sysinit.target @9.333s
          └─swap.target @9.333s
            └─dev-disk-by\x2duuid-c0198c37\x2df28b\x2d41f5\x2dbb0f\x2d37d575e86896.swap @8.843s +490ms
              └─dev-disk-by\x2duuid-c0198c37\x2df28b\x2d41f5\x2dbb0f\x2d37d575e86896.device @8.841s
mercurial@providence:~$ systemd-analyze blame
         10.636s udisks2.service
          6.628s dev-sda6.device
          5.486s ModemManager.service
          4.935s accounts-daemon.service
          4.346s exim4.service
          4.156s NetworkManager.service
          3.211s bluetooth.service
          3.203s atd.service
          3.174s apt-daily.service
          3.132s pppd-dns.service
          3.128s alsa-restore.service
          2.765s systemd-logind.service
          2.762s avahi-daemon.service
          2.751s rsyslog.service
          2.750s wpa_supplicant.service
          2.594s networking.service
          2.168s lightdm.service
          2.148s plymouth-quit-wait.service
          2.024s upower.service
          1.975s systemd-udevd.service
          1.955s apparmor.service
          1.718s polkit.service
          1.412s systemd-tmpfiles-setup.service
          1.161s colord.service
          1.000s systemd-rfkill.service

我相信还有很大的改进空间，所以我将等待一些核心系统管理员来阐明。谢谢。

Answer

mercurial@providence:~$ systemd-analyze
Startup finished in 7.913s (kernel) + 20.621s (userspace) = 28.534s 
graphical.target reached after 20.605s in userspace