ステップ1: 起動プロセスのどこで時間がかかっているか分析する
Ubuntuには、起動プロセスを分析するための非常に便利なツール systemd-analyze が標準で入っています。まずはこれから試してみましょう。

起動時間全体の内訳を確認します。
以下のコマンドを実行すると、ファームウェア(BIOS/UEFI)、ブートローダー(GRUB)、カーネル、ユーザー空間のそれぞれにかかった時間が表示されます。これにより、どの段階で時間がかかっているのか、大まかに把握できます。
systemd-analyze time

各サービスの起動時間をリストアップします。
次のコマンドは、起動に時間がかかったサービスを降順（時間がかかった順）で表示します。リストの最初の方にあるサービスが、起動を遅くしている原因である可能性が高いです。
systemd-analyze blame

systemd-analyze time の結果:
Startup finished in ... + 1min 41.492s (userspace) = 1min 52.690s

これは、OSの心臓部であるカーネルの起動は1.5秒で終わっているものの、その後の**ユーザー空間のサービス起動に約1分41秒もかかっている**ことを示しています。これは典型的な「サービス起動の遅延」パターンです。

systemd-analyze blame の結果から、特に時間がかかっているサービスは以下の通りです。
1. `15.239s apt-daily-upgrade.service`: **約15秒**。バックグラウンドでパッケージのアップデートを確認・ダウンロードするサービスです。
2. `5.746s NetworkManager-wait-online.service`: **約6秒**。ネットワークが完全にオンラインになるのを待機するサービスです。

次の調査ステップ：ログから「時間の飛躍」を探す
systemd-analyze blameではこれ以上の特定は困難です。そこで、起動シーケンスを時系列で記録したジャーナルログを確認し、どこで時間が不自然に飛んでいる（=待ち時間が発生している）かを探します。
journalctl -b
-b は「現在の起動（boot）に関するログのみ」を表示するオプションです。

ログのご提供、誠にありがとうございます！
完璧な情報です。これにより、遅延の根本原因が完全に特定できました。

解析結果：犯人はTPM（セキュリティチップ）のタイムアウト
ご提供いただいたログの中に、問題の核心を示す決定的な行がありました。

6月 21 17:47:01 pakkakun systemd[1]: systemd-fsckd.service: Deactivated successfully.
6月 21 17:48:01 pakkakun systemd[1]: dev-tpmrm0.device: Job dev-tpmrm0.device/start timed out.
ご覧の通り、17:47:01 の次のログが 17:48:01 となっており、ここでちょうど1分30秒 (90秒) の待ち時間が発生しています。

そして、その待ち時間の直後のメッセージが原因を物語っています。
Timed out waiting for device dev-tpmrm0.device - /dev/tpmrm0.

これは、システムが TPM (Trusted Platform Module) 2.0 というセキュリティチップ用のデバイス (/dev/tpmrm0) が利用可能になるのを待っていたものの、90秒経っても応答がなかったため、諦めて（タイムアウトして）次の処理に進んだ、ということを示しています。

さらに、ログの少し前の部分には、このタイムアウトの伏線となるエラーも記録されていました。

6月 21 17:46:31 pakkakun kernel: tpm_crb MSFT0101:00: error -EBUSY: can't request region for resource ...
6月 21 17:46:31 pakkakun kernel: tpm_crb MSFT0101:00: probe with driver tpm_crb failed with error -16
6月 21 17:46:31 pakkakun kernel: ima: No TPM chip found, activating TPM-bypass!
これは、OSの起動直後にLinuxカーネルがTPMチップを初期化しようとしたものの、何らかの理由で失敗している（リソースがビジー、プローブに失敗）ことを示しています。カーネル自身は「TPMチップが見つからない」と判断して先に進んでいますが、その後のsystemdのプロセスが「TPMが使われるはずだ」と律儀に待ち続けていた、というのが遅延の全貌です。

解決策
このPCでは、現状LinuxからTPMが正常に利用できていないようです。幸い、TPMは一般的なデスクトップ利用で必須の機能ではないため、TPM関連のサービスを起動しないように設定することで、この90秒の無駄な待機時間を完全になくすことができます。

解決策：TPMターゲット自体を無効化する
この状況に対する最も直接的で効果的な解決策は、systemdに対して**「そもそも tpm2.target というターゲットは無視してください」**と指示することです。
これは、mask というコマンドで実現できます。mask は disable よりも強力で、そのサービスやターゲットが存在しないかのように振る舞わせることができます。これにより、sysinit.target は tpm2.target を待つことなく、スムーズに次の処理へ進むようになります。

以下のコマンドを一つだけ、ターミナルで実行してください。
sudo systemctl mask tpm2.target
実行すると、シンボリックリンクが /dev/null に対して作成された旨のメッセージが表示されます。
この操作は安全です。 もし万が一、この設定によって別の問題が発生した場合は、以下のコマンドでいつでも元に戻すことができます。
sudo systemctl unmask tpm2.target

やりましたね！完璧な結果です。解決おめでとうございます！

結果の分析
ご提供いただいた結果を見れば、問題が完全に解決したことが一目瞭然です。

起動時間
修正前: 1min 50.438s
修正後: 22.863s
userspaceにかかっていた時間が 1分39秒 から 11.7秒 へと、劇的に短縮されています。これにより、全体の起動時間も約1分半短縮され、非常に快適な速度になりました。