正在為 eth0 執行啟動作業
我正在使用新安裝的 Arch Linux，每當我啟動我的系統時，我都必須等待 90 秒，因為我的網路介面正在執行一個啟動作業。
我昨天安裝了 Arch，每當我這樣做時，
ip a我都會發現乙太網介面處於DOWN狀態。我使用有線 USB 繫繩來完成整個安裝。我只想在啟動時刪除該啟動作業過程。我在 Arch 社區的某個地方看到了一個解決方案，我必須使用以下方法禁用我的界面：# systemctl disable dhcpcd@interface_name我還沒有這樣做。我的問題是，如果我禁用該介面，將來會導致任何問題嗎？我現在沒有使用任何 LAN 連接。如果將來我想使用 LAN 或某種乙太網連接，這會導致任何問題嗎？
輸出
uname -a：[siddharth@brightprogrammer ~]$ uname -a Linux brightprogrammer 4.19.26-1-lts #1 SMP Wed Feb 27 16:06:52 CET 2019 x86_64 GNU/Linux輸出
ip a：[siddharth@brightprogrammer ~]$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp1s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether 80:fa:5b:5b:9e:47 brd ff:ff:ff:ff:ff:ff 3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 94:b8:6d:c9:57:89 brd ff:ff:ff:ff:ff:ff inet 192.168.43.201/24 brd 192.168.43.255 scope global dynamic noprefixroute wlp2s0 valid_lft 2153sec preferred_lft 2153sec inet6 2405:205:a061:4977:348c:2fe2:102:47ac/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 fe80::614a:460c:ff14:9caa/64 scope link noprefixroute valid_lft forever preferred_lft forever輸出
find /etc/systemd：[siddharth@brightprogrammer ~]$ find /etc/systemd /etc/systemd /etc/systemd/journald.conf /etc/systemd/coredump.conf /etc/systemd/sleep.conf[siddharth@brightprogrammer ~]$ systemd-analyze啟動在 5.369 秒（韌體）+ 1.785 秒（載入程序）+ 5.214 秒（核心）+ 1 分鐘 33.882 秒（使用者空間）= 1 分鐘 46.252 秒圖形完成。在使用者空間 1 分鐘 33.882 秒後達到目標
/etc/systemd/journal-remote.conf /etc/systemd/system.conf /etc/systemd/timesyncd.conf /etc/systemd/journal-upload.conf /etc/systemd/networkd.conf /etc/systemd/system /etc/systemd/system/getty.target.wants /etc/systemd/system/getty.target.wants/getty@tty1.service /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service /etc/systemd/system/bluetooth.target.wants /etc/systemd/system/bluetooth.target.wants/bluetooth.service /etc/systemd/system/multi-user.target.wants /etc/systemd/system/multi-user.target.wants/NetworkManager.service /etc/systemd/system/multi-user.target.wants/dhcpcd@eth0.service /etc/systemd/system/multi-user.target.wants/wicd.service /etc/systemd/system/multi-user.target.wants/dhcpcd@wlp2s0.service /etc/systemd/system/multi-user.target.wants/remote-fs.target /etc/systemd/system/network-online.target.wants /etc/systemd/system/network-online.target.wants/NetworkManager-wait-online.service /etc/systemd/system/dbus-org.bluez.service /etc/systemd/system/dbus-org.wicd.daemon.service /etc/systemd/system/display-manager.service /etc/systemd/system/dbus-org.freedesktop.NetworkManager.service /etc/systemd/logind.conf /etc/systemd/user /etc/systemd/user/sockets.target.wants /etc/systemd/user/sockets.target.wants/p11-kit-server.socket /etc/systemd/user/sockets.target.wants/pipewire.socket /etc/systemd/user/sockets.target.wants/gpg-agent.socket /etc/systemd/user/sockets.target.wants/dirmngr.socket /etc/systemd/user/sockets.target.wants/gpg-agent-extra.socket /etc/systemd/user/sockets.target.wants/gpg-agent-browser.socket /etc/systemd/user/sockets.target.wants/gpg-agent-ssh.socket /etc/systemd/user/sockets.target.wants/pulseaudio.socket /etc/systemd/user/default.target.wants /etc/systemd/user/default.target.wants/xdg-user-dirs-update.service /etc/systemd/user.conf /etc/systemd/network /etc/systemd/resolved.conf輸出
systemd-analyze：[siddharth@brightprogrammer ~]$ systemd-analyze Startup finished in 5.369s (firmware) + 1.785s (loader) + 5.214s (kernel) + 1min 33.882s (userspace) = 1min 46.252s graphical.target reached after 1min 33.882s in userspace輸出
systemd-analyze critical-analyze：[siddharth@brightprogrammer ~]$ systemd-analyze critical-chain The time after the unit is active or started is printed after the "@" character. graphical.target @1min 33.882s └─gdm.service @1min 33.615s +265ms └─systemd-user-sessions.service @1min 33.503s +110ms └─network.target @1min 33.501s └─wpa_supplicant.service @15.761s +638ms └─basic.target @11.036s └─sockets.target @11.036s └─dbus.socket @11.036s └─sysinit.target @11.028s └─systemd-backlight@backlight:intel_backlight.service @14.008s > └─system-systemd\x2dbacklight.slice @14.006s └─system.slice @2.915s └─-.slice @2.915s輸出
systemd-analyze blame：[siddharth@brightprogrammer ~]$ systemd-analyze blame 11.692s dhcpcd@wlp2s0.service 11.692s dhcpcd@wlp2s0.service 6.472s lvm2-monitor.service 4.616s wicd.service 3.222s systemd-journal-flush.service 3.188s NetworkManager.service 2.719s bluetooth.service 2.711s systemd-logind.service 1.395s systemd-sysusers.service 1.216s systemd-udevd.service 1.213s ldconfig.service 981ms udisks2.service 971ms polkit.service 649ms user@120.service 638ms wpa_supplicant.service 600ms systemd-modules-load.service 526ms systemd-tmpfiles-setup.service 501ms systemd-tmpfiles-setup-dev.service 493ms upower.service 487ms systemd-udev-trigger.service 464ms systemd-journald.service 371ms systemd-journal-catalog-update.service 338ms systemd-sysctl.service 268ms colord.service 265ms gdm.service 260ms kmod-static-nodes.service 238ms dev-sda2.swap 236ms accounts-daemon.service 142ms systemd-random-seed.service 135ms systemd-backlight@backlight:intel_backlight.service 110ms systemd-user-sessions.service 91ms user@1000.service 81ms systemd-update-utmp.service 54ms systemd-remount-fs.service 48ms sys-kernel-debug.mount 35ms systemd-tmpfiles-clean.service 28ms dev-hugepages.mount 26ms user-runtime-dir@120.service 25ms sys-kernel-config.mount 16ms user-runtime-dir@1000.service 15ms dev-mqueue.mount 9ms rtkit-daemon.service 6ms systemd-update-done.service 4ms systemd-rfkill.service 3ms sys-fs-fuse-connections.mount 2ms tmp.mount
systemctl status dhcpcd@eth0.service和 的輸出dhcpcd@enp1s0f1：[siddharth@brightprogrammer ~]$ sudo systemctl status dhcpcd@eth0.service ● dhcpcd@eth0.service - dhcpcd on eth0 Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; enabled; vendor pre> Active: inactive (dead) Mar 05 09:42:42 brightprogrammer systemd[1]: Dependency failed for dhcpcd on eth0. Mar 05 09:42:42 brightprogrammer systemd[1]: dhcpcd@eth0.service: Job dhcpcd@eth0.service/start failed with result 'dependency'. [siddharth@brightprogrammer ~]$ sudo systemctl status dhcpcd@enp1s0f1.service ● dhcpcd@enp1s0f1.service - dhcpcd on enp1s0f1 Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; disabled; vendor pr> Active: inactive (dead)我最近禁用了 enp1s0f1。這可能是它被禁用的原因。
我也可以提供輸出，
journalctl -xe但那是非常大的！我也懷疑這dhcpcd在某種程度上混淆了eth0我的enp1s0f1
我想說你看到的問題很可能是
dhcpcd@eth0.service你係統上配置的問題。所以我的建議是禁用它，希望這足以使啟動期間的超時消失：$ sudo systemctl disable dhcpcd@eth0我將審查證據以支持該主張。可以在這裡完成更多故障排除，我會建議更多步驟（以防您想進一步查看，或將來解決類似問題。）
該問題的主要證據是輸出消息
systemctl status dhcpcd@eth0：Mar 05 09:42:42 brightprogrammer systemd[1]: dhcpcd@eth0.service: Job dhcpcd@eth0.service/start failed with result 'dependency'.結果“依賴”失敗意味著，在這種情況下，它正在等待其他失敗的東西。此服務將具有依賴關係，
eth0.device並且不會出現此設備，因此這可能是超時的來源。你可以systemctl status eth0.device看看是否有其他東西出現，它可能會（但是，它可能不會。）就像您在問題中提到的那樣，系統中
eth0的實際設備名稱和實際設備名稱之間可能存在混淆enp1s0f1。systemd（更具體地說是 udevd）將重命名網路介面以賦予它們一致的名稱，這通常發生在啟動的早期（有時甚至在 systemd 出現之前），因此 systemd 將不再真正看到該eth0名稱。如果以後要在該介面上啟用 DHCP，請
dhcpcd@enp1s0f1改為啟用。的輸出
systemd-analyze critical-chain支持該服務超時的假設，dhcpcd@eth0您可以從這兩個步驟中看到：└─network.target @1min 33.501s └─wpa_supplicant.service @15.761s +638ms之後的時間是啟動後
@的時鐘時間。該wpa_supplicant服務在 systemd 啟動後 13 秒出現，但network.target僅在 1 分 33 秒達到（大約是您所說的 90 年代。）您可能會
dhcpcd@eth0更明確地看到這裡，但該單元實際上進入了“載入”/“非活動”狀態，而不是“失敗”，所以這可能是它沒有在此處（和systemd-analyze blame）突出顯示的原因，這將幫助指出它是罪魁禍首。最後，在解決 systemd 引導問題時，通常是一個很好的開始步驟是從查看裸
systemctl status輸出開始，這將告訴您系統是否處於“降級”狀態，這表明在引導過程中發生了故障。您希望確保系統狀態為“正在執行”，因此調查這些故障通常會發現諸如超時等問題。您可以通過查看 的輸出從該點開始調查
systemctl，這將列出所有活動單元及其狀態，如果您在那裡發現問題，請通過調查特定單元（使用systemctl status <unit>或journalctl -u <unit>）進一步查看。命令systemctl --state=failed也可用於僅顯示失敗的單位。最後，查一下期刊真的很好做相關性。命令
journalctl -b顯示自系統啟動以來的日誌，因此在啟動過程中查看問題非常有用。如前所述，journalctl -u <unit>對於調查單個單元的日誌很有用。希望這些提示將有助於您更深入地探勘和了解系統中正在發生的事情。還希望禁用它
dhcpcd@eth0足以解決您遇到的啟動延遲。