编辑：
我已经缩小了一些具体流程 - 格式是
[good boot
vs
bad boot]
[8.154559] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[8.335203] systemd[1]: Inserted module 'autofs4'
vs
[8.481411] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[10.642746] systemd[1]: Inserted module 'autofs4'
+2 seconds
Note: I've checked the UUIDs on fstab and they match
[8.398891] systemd[1]: Hostname set to <frink>.
[8.526727] systemd[1]: Queued start job for default target Graphical Interface.
vs
[10.991973] systemd[1]: Hostname set to <frink>.
[12.971349] systemd[1]: Queued start job for default target Graphical Interface.
+2 seconds
[8.595713] ppdev: user-space parallel port driver
[8.608930] systemd-journald[422]: Received client request to flush runtime journal.
vs
[13.136621] ppdev: user-space parallel port driver
[13.768849] input: Intel HID events as /devices/platform/INTC1070:00/input/input9
+0.5 seconds
No entry for name="man_groff"
vs
[14.765699] audit: type=1400 audit(1677744482.483:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=779 comm="apparmor_parser"
[15.630003] Bluetooth: hci0: Waiting for firmware download to complete
+1 second
[17.822488] r8169 0000:03:00.0: invalid VPD tag 0x00 (size 0) at offset 0; assume missing optional EEPROM
[22.643689] wlo1: authenticate with 20:47:ed:48:3d:13
vs
[11.254521] r8169 0000:03:00.0: invalid VPD tag 0x00 (size 0) at offset 0; assume missing optional EEPROM
[13.238764] Bluetooth: RFCOMM TTY layer initialized
+3 seconds
有什么想法创造了上述三角洲吗？
在某些情况下，我的启动时间为 20 秒，然后第二天就会是 25-30 秒，这并不是说时间很麻烦，而是事实上我的系统在每次启动时都会做不同的事情，特别是当额外的时间似乎来自引导加载程序。
'good' boot:
Startup finished in 10.387s (firmware) + 4.630s (loader) + 7.083s (kernel) + 2.650s (userspace) = 24.752s
graphical.target reached after 2.647s in userspace
'bad' boot:
Startup finished in 11.405s (firmware) + 14.686s (loader) + 8.116s (kernel) + 2.945s (userspace) = 37.153s
graphical.target reached after 2.942s in userspace
dmesg、systemd-blame、systemd-key-chain 等都非常相似。我怀疑这是因为延迟发生在内核加载之前。
我关注了这个线程： 在内核日志记录开始之前调试 grub 中的启动性能问题
并将“debug=all”添加到我的 grub 配置中，但打印所有消息大约需要 10 分钟，因此无法跟踪问题，“debug=linux”根本不打印任何消息
这个问题非常间歇性。我发现，如果我重新启动或关闭并在短时间内再次启动，我会得到“良好”的启动。如果我关闭计算机，比如整晚关闭，或者白天关闭几个小时，我更有可能看到“坏”启动。这还没有触及双引导的 win 10 操作系统。引导阶段没有 BIOS/引导加载程序/内核错误消息。
设置为 SSD/Intel i5 12th gen/ kubuntu 22.04 / kernel 5.15.0-58-generic- win 10 双启动（禁用快速启动）
有任何想法吗？我真的想避免使用发行版，因为我喜欢其他的设置。谢谢