我知道这应该是可以修复的，因为在全新安装后，整个启动过程，从 GRUB 到最终桌面，可能需要 5-10 秒（这是合理的，因为这是一台非常快的台式电脑，AMD Ryzen 3900X、3600 MHz DDR4 RAM、三星 970 EVO Plus M.2 NVM）。
这是（K）Ubuntu 20.04。
做了一些更改后，启动时间突然变得更长（2 分钟左右）。
我该如何系统地调试为什么会出现这种情况？
我读到过bootchart，现在好像是systemd-bootchart。我安装了它，但我不确定是否需要设置任何东西来运行它。
然后我看到这里默认情况systemd-analyze下，已经存在类似功能。我创建了以下图表：
但是，我不太清楚该如何理解。这些都是按顺序运行还是并行运行？我假设是并行运行。我看到一些服务（apparmor 等）是在很晚的时候才启动的。但为什么呢？我怎么知道为什么它们启动得这么晚？我假设它们依赖于某物。但依赖于什么呢？我在这个图中真的没有看到任何准备好此时。服务也有浅红色和一些深红色。这些是什么意思？
输出结果为systemd-analyze critical-chain：
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @1min 37.068s
└─multi-user.target @1min 37.068s
└─kerneloops.service @1min 37.058s +10ms
└─network-online.target @1min 37.057s
└─NetworkManager-wait-online.service @1min 30.725s +6.331s
└─NetworkManager.service @1min 30.625s +99ms
└─dbus.service @1min 30.623s
└─basic.target @1min 30.606s
└─sockets.target @1min 30.606s
└─snapd.socket @1min 30.605s +359us
└─sysinit.target @1min 30.603s
└─systemd-timesyncd.service @1min 30.418s +185ms
└─systemd-tmpfiles-setup.service @1min 30.396s +18ms
└─systemd-journal-flush.service @493ms +49ms
└─systemd-journald.service @173ms +319ms
└─systemd-journald.socket @170ms
└─-.mount @168ms
└─system.slice @168ms
└─-.slice @168ms
systemd-tmpfiles-setup.service @1min 30.396s和之间有很大的差距systemd-journal-flush.service @493ms。但是为什么呢？
我认为这与我安装的较旧的（与系统无关的）硬盘有关。实际上，我希望它大多数时间处于待机状态，因为我很少使用它，或者大多数时候根本不使用它（可能每周一次或更少）。我已经将其配置为/etc/fstab（0 2在选项之后）。也许我应该改用0 0它？或者也许我应该将noauto选项设置为不自动挂载它？（编辑：我添加了noauto，它不再自动安装。但是，这似乎没有任何效果。仍然是完全相同的关键链输出。）
编辑：我刚刚检查了的输出journalctl --no-pager，它似乎对这个案例更有帮助：
...
Mai 03 13:03:33 az-Desktop2020 systemd[1]: Finished udev Wait for Complete Device Initialization.
Mai 03 13:03:33 az-Desktop2020 systemd[1]: Starting Install ZFS kernel module...
Mai 03 13:03:33 az-Desktop2020 systemd[1]: Finished Install ZFS kernel module.
Mai 03 13:03:33 az-Desktop2020 systemd[1]: Starting Import ZFS pools by cache file...
Mai 03 13:03:34 az-Desktop2020 systemd[1]: Finished Import ZFS pools by cache file.
Mai 03 13:03:34 az-Desktop2020 systemd[1]: Reached target ZFS pool import target.
Mai 03 13:03:34 az-Desktop2020 systemd[1]: Starting Mount ZFS filesystems...
Mai 03 13:03:34 az-Desktop2020 systemd[1]: Starting Wait for ZFS Volume (zvol) links in /dev...
Mai 03 13:03:34 az-Desktop2020 zvol_wait[1418]: No zvols found, nothing to do.
Mai 03 13:03:34 az-Desktop2020 systemd[1]: Finished Wait for ZFS Volume (zvol) links in /dev.
Mai 03 13:03:34 az-Desktop2020 systemd[1]: Reached target ZFS volumes are ready.
Mai 03 13:03:34 az-Desktop2020 systemd[1]: Finished Mount ZFS filesystems.
Mai 03 13:03:34 az-Desktop2020 systemd[1]: Starting Load/Save Random Seed...
Mai 03 13:03:34 az-Desktop2020 systemd[1]: Finished Load/Save Random Seed.
Mai 03 13:03:35 az-Desktop2020 systemd[1]: systemd-rfkill.service: Succeeded.
Mai 03 13:04:00 az-Desktop2020 systemd[1]: systemd-fsckd.service: Succeeded.
Mai 03 13:05:00 az-Desktop2020 systemd[1]: dev-disk-by\x2duuid-88eaaaf4\x2d2ccf\x2d43c2\x2daa6e\x2dcaea7fa32aef.device: Job dev-disk-by\x2duuid-88eaaaf4\x2d2ccf\x2d43c2\x2daa6e\x2dcaea7fa32aef.device/start timed out.
Mai 03 13:05:00 az-Desktop2020 systemd[1]: Timed out waiting for device /dev/disk/by-uuid/88eaaaf4-2ccf-43c2-aa6e-caea7fa32aef.
Mai 03 13:05:00 az-Desktop2020 systemd[1]: Dependency failed for File System Check on /dev/disk/by-uuid/88eaaaf4-2ccf-43c2-aa6e-caea7fa32aef.
Mai 03 13:05:00 az-Desktop2020 systemd[1]: Dependency failed for /mnt/ssd1.
Mai 03 13:05:00 az-Desktop2020 systemd[1]: Dependency failed for Local File Systems.
Mai 03 13:05:00 az-Desktop2020 systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'.
Mai 03 13:05:00 az-Desktop2020 systemd[1]: mnt-ssd1.mount: Job mnt-ssd1.mount/start failed with result 'dependency'.
Mai 03 13:05:00 az-Desktop2020 systemd[1]: systemd-fsck@dev-disk-by\x2duuid-88eaaaf4\x2d2ccf\x2d43c2\x2daa6e\x2dcaea7fa32aef.service: Job systemd-fsck@dev-disk-by\x2duuid-88eaaaf4\x2d2ccf\x2d43c2\x2daa6e\x2dcaea7fa32aef.service/start failed with result 'dependency'.
Mai 03 13:05:00 az-Desktop2020 systemd[1]: dev-disk-by\x2duuid-88eaaaf4\x2d2ccf\x2d43c2\x2daa6e\x2dcaea7fa32aef.device: Job dev-disk-by\x2duuid-88eaaaf4\x2d2ccf\x2d43c2\x2daa6e\x2dcaea7fa32aef.device/start failed with result 'timeout'.
...
已经有一个跳转到systemd-fsckd，这花了很长时间（25 秒）但跳转到 的时间更长dev-disk-by\x2duuid-88ea....device: Job dev-disk-by....device/start timed out。我想这是问题之一。
编辑：是的，这dev-disk-by ... device/start timed out就是问题所在。那是我/etc/fstab系统中甚至没有安装的磁盘中的另一个条目。添加后noauto，它就起作用了。但是我想知道，Ubuntu/systemd 是否真的是最好的策略，只是在那里闲置等待超时（1:30 分钟左右？）然后失败？它可以更聪明，对吧？
（无论如何我都会将这个问题保留开放状态，因为在此过程中仍有很多悬而未决的问题，我仍然对此感到好奇。例如，如何系统地调试这样的问题。为什么systemd-analyze这里没有那么有帮助，或者如何更好地阅读它。）