編集する：
いくつかの特定の流れを絞り込んだ。形式は次のとおりです。
[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 でのブートパフォーマンスの問題のデバッグ
私のgrub設定に "debug = all"を追加しましたが、すべてのメッセージを印刷するのに約10分かかり、問題を追跡できません。 "debug = linux"はメッセージをまったく印刷しません。
この問題は非常に断続的に発生します。短時間で再起動するか、システムをシャットダウンして再起動すると、「良い」起動が可能であることがわかりました。一晩または昼間に数時間コンピュータの電源を切ると、「不良」起動が発生する可能性が高くなります。これは、デュアルブートWin 10オペレーティングシステムにも影響しません。起動フェーズ中は、BIOS/ブートローダ/カーネルエラーメッセージはありません。
SSD/Intel i5 第12世代/kubuntu 22.04/kernel 5.15.0-58-generic-win 10 デュアルブートに設定(クイックブート無効)
どんなアイデアがありますか？私は他の設定を好むので、ディストリビューションの使用を避けたいと思います。ありがとう