eth0の起動ジョブの実行中

Question

あなたが見ている問題は、[email protected]システムの構成に関連している可能性が最も高いです。だから私の提案はこれを無効にすることです。これは起動中のタイムアウトをなくすのに十分です。

$ sudo systemctl disable dhcpcd@eth0

私はこの主張を裏付ける証拠を詳しく見てみましょう。ここでより多くのトラブルシューティングが可能です。後でさらに詳しく学んだり、同様の問題を解決したい場合は、追加の手順を提案します。

問題の主な証拠は、systemctl status dhcpcd@eth0次の出力メッセージです。

Mar 05 09:42:42 brightprogrammer systemd[1]: [email protected]: Job [email protected]/start failed with result 'dependency'.

「依存関係」が失敗したという結果は、この場合失敗した他のものを待っていたという意味です。サービスはデバイスによって異なり、eth0.deviceデバイスが存在しないため、タイムアウトの原因になる可能性があります。systemctl status eth0.device他のものが表示されているかどうかを確認できます。おそらくそうです（しかしそうではないかもしれません）。

質問で述べたように、eth0実際のデバイス名とシステムの実際のデバイス名の間に混乱がある可能性があります。enp1s0f1systemd（より具体的にはudevd）は、ネットワークインタフェースの名前を変更して一貫した名前を与えます。これは通常ブート初期（時にはsystemdが起動する前）に発生するため、systemdは実際には名前を見ることができませんeth0。

後でこのインターフェイスでDHCPを有効にするには、dhcpcd@enp1s0f1代わりに有効にします。

の出力は、次の2つのステップで見られるsystemd-analyze critical-chainサービスタイムアウトという仮説を裏付けています。dhcpcd@eth0

└─network.target @1min 33.501s    
  └─wpa_supplicant.service @15.761s +638ms

それ以降の時間@は開始後の時計時間です。wpa_supplicantsystemdが開始して13秒後にサービスが開始されましたが、1network.target分33秒（おっしゃった通り約90秒）に達しました。

ここでより明確に見ることができますが、デバイスは実際には「失敗」ではなく「ロード済み」/「非アクティブ」状態になります。したがって、ここ（および内部）の列が強調表示されてdhcpcd@eth0いないのは、おそらくこのためです。systemd-analyze blameそれが犯人であることを指摘するのは役に立ちます。

最後に、システム起動の問題を解決するための最良のステップは、まず基本出力を調べることですsystemctl status。これにより、システムが起動プロセス中に問題が発生したことを示す「パフォーマンスの低下」状態であることがわかります。システムの状態が「実行中」であることを確認しようとしているため、これらのエラーを調べるとタイムアウトなどの問題が発生することがよくあります。

systemctlすべてのアクティブデバイスとそのステータスを一覧表示する出力を確認して、その時点から調べることができます。問題がある場合は、特定のデバイスを調査してさらに調査することができます（systemctl status <unit>または使用journalctl -u <unit>）。このコマンドをsystemctl --state=failed使用して、失敗したデバイス単位のみを表示することもできます。

最後に、ジャーナルを閲覧することは接続を作成するのに本当に役立ちます。このコマンドはjournalctl -bシステム起動後のログを表示するため、起動中の問題の確認に役立ちます。前述したように、journalctl -u <unit>単一ユニットのログを調べるのに便利です。

このヒントがシステムで何が起こっているのかをより深く掘り下げて理解するのに役立つことを願っています。また、この機能を無効にすると、dhcpcd@eth0現在発生している開始遅延の問題を解決するのに十分です。

Answer 1