You are not logged in.
Dear People,
Can someone advise please.
Problem: System is slow to boot due to time-out delay.
System: A stand-alone Arch-Linux installation on a USB external
Hard drive. Installation (December 2020) inspired by plan
laid down by C. Magyar <https://archive.ph/7FFiQ> but with
different partitioning arrangement. Should boot from EFI or
legacy firmaware.
Net interface is NetworkManager.
Host hardware: Tabletop PC, ASUS motherboard Intel chipset.
Symptoms: Boot seems to run well, but a time-out delay related to
network interface eth0 (reported on the monitor) slows
the boot process down. Afterwards the system works normally,
including internet access.
An abridged version of the boot-log is reproduced below.
Note that:
a) at T+00:07 secs the system renames eth0 to eno1; Why?
b) at T+1min30sec the daemon dhcpcd@eth0.service times out
presumably because it can't find eth0.
Note: Putting a 'dhcp' script in /etc/NetworkManager/conf.d as
described in Arch Wiki "NetworkManager" section 4.6 did not
cure the problem.
Note also that dhcpcd.service was not enabled.
Question: Where do I find the software that initiates dhcpcd@eth0.service
and how can/should I rename that call to dhcpcd@eno1.service?
Or is there a better way to speed up the boot process?
Thanks in advance to anyone who can help.
Regards,
Dynosaw
APPENDIX: ABRIDGED BOOT-LOG WITH TIMES RESET TO BOOT STARTED at T=0.
---------------------------------------------------------------------
T+00:00 arch kernel: Linux version 6.12.47-1-lts
T+00:00 arch kernel: Command line: BOOT_IMAGE=/vmlinuz-linux-lts root=UUID=XXXXXXXX-etc
T+00:01 arch systemd[1]: Expecting device /sys/subsystem/net/devices/eth0..
T+00:07 arch kernel: e1000e 0000:00:1f.6 eth0: (PCI Express:2.5GT/s:Width x1) aa:bb:cc:dd:ee:ff
T+00:07 arch kernel: e1000e 0000:00:1f.6 eth0: Intel(R) PRO/1000 Network Connection
T+00:07 arch kernel: e1000e 0000:00:1f.6 eth0: MAC: 14, PHY: 12, PBA No: FFFFFF-0FF
T+00:07 arch kernel: e1000e 0000:00:1f.6 eno1: renamed from eth0
T+01:30 arch systemd[1]: sys-subsystem-net-devices-eth0.device:
Job sys-subsystem-net-devices-eth0.device/start timed out.
T+01:30 arch systemd[1]: Timed out waiting for device /sys/subsystem/net/devices/eth0.
T+01:30 arch systemd[1]: Dependency failed for DHCP/ IPv4LL/ IPv6RA/ DHCPv6 client on eth0.
T+01:30 arch systemd[1]: dhcpcd@eth0.service: Job dhcpcd@eth0.service/start failed with result 'dependency'.
T+01:30 arch systemd[1]: sys-subsystem-net-devices-eth0.device:
Job sys-subsystem-net-devices-eth0.device/start failed with result 'timeout'.
Last edited by dynosaw (2025-10-24 13:58:32)
Offline
Please use [ code ] [ /code ] tags for such output, see https://bbs.archlinux.org/help.php#bbcode
a) at T+00:07 secs the system renames eth0 to eno1; Why?
https://wiki.archlinux.org/title/Networ … interfaces
Question: Where do I find the software that initiates dhcpcd@eth0.service
and how can/should I rename that call to dhcpcd@eno1.service?
Or is there a better way to speed up the boot process?
A possible cause is conflicting network services. please post the output of
$ find /etc/systemd -type l -exec test -f {} \; -print | sortDisliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Lone Wolf,
Thanks for responding to my plea for help.
> a) at T+00:07 secs the system renames eth0 to eno1; Why?
Frankly, I do no know why the system does this. What I do know
is that eno1 is the "workhorse" network interface used by NetworkManager.
If you run ipconfig, you get eno1. My understanding is that NetworkManager
is the main interface software and it calls dhcpcd when needed as a helper.
b) I ran the 'find' command and the result is here:
LISTING: $ find /etc/systemd -type l -exec test -f {} \; -print | sort
/etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service
/etc/systemd/system/dbus-org.freedesktop.timesync1.service
/etc/systemd/system/display-manager.service
/etc/systemd/system/getty.target.wants/getty@tty1.service
/etc/systemd/system/multi-user.target.wants/apparmor.service
/etc/systemd/system/multi-user.target.wants/dhcpcd@eth0.service
/etc/systemd/system/multi-user.target.wants/ip6tables.service
/etc/systemd/system/multi-user.target.wants/iptables.service
/etc/systemd/system/multi-user.target.wants/NetworkManager.service
/etc/systemd/system/multi-user.target.wants/remote-fs.target
/etc/systemd/system/network-online.target.wants/NetworkManager-wait-online.service
/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service
/etc/systemd/user/sockets.target.wants/gcr-ssh-agent.socket
/etc/systemd/user/sockets.target.wants/gnome-keyring-daemon.socket
/etc/systemd/user/sockets.target.wants/p11-kit-server.socket
/etc/systemd/user/sockets.target.wants/pipewire.socket
/etc/systemd/user/sockets.target.wants/pulseaudio.socket
-------------------------
Thanks for your help.
Dynosaw
--
Offline
My understanding is that NetworkManager
is the main interface software and it calls dhcpcd when needed as a helper.
Only if you configure it to, and even then, it starts it itself. You should NOT have it enabled like you do.
Offline
For clarity
/etc/systemd/system/multi-user.target.wants/dhcpcd@eth0.serviceThat line tells us dhcpcd is enabled for eth0 by something, you need to disable it.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Thank you for your response Scimmia.
(This was written before Lone Wolf replied for a second time)
Your remarks are somewhat ambiguous but I assume by "it" you
mean dhcpcd and not NetworkManager. The ArchWiki on NetworkManager
mentions the risk of a collision with dhcpcd.service and suggests
that the latter should be disabled. Unfortunately the Arch Wiki
makes no mention of dhcpcd@.service, which in this case seems to
have been the cause of the problem.
Furthermore, running systemctl can give confusing results (see below).
1. CHECK STATUS
$ systemctl list-unit-files | grep dhcpcd
dhcpcd.service disabled disabled
dhcpcd@.service indirect disabled
This result gives the impression that dhcpcd.service and dhcpcd@.service
are disabled and not active.
2. YET ANOTHER STATUS CHECK
$ systemctl status dhcpcd.service
dhcpcd.service - DHCP/ IPv4LL/ IPv6RA/ DHCPv6 client on all interfaces
Loaded: loaded (/usr/lib/systemd/system/dhcpcd.service; disabled; preset: disabled)
Active: inactive (dead)
$ systemctl status dhcpcd@.service
Failed to get properties: Unit name dhcpcd@.service is neither a valid invocation ID nor unit name.
This result gives the impression that dhcpcd@.service does not exist at all!
Maybe one should have queried dhcpcd@eth0.service; but then, running ifconfig
only reveals eno1; eth0 is not shown in the configuration listing
3. YET ONE MORE STATUS CHECK
$ systemctl list-units --all | grep dhcpcd
dhcpcd@eth0.service loaded inactive dead DHCP/ IPv4LL/ IPv6RA/DHCPv6 client on eth0 loaded inactive dead DHCP/ IPv4LL/ IPv6RA/ DHCPv6 client on eth0
system-dhcpcd.slice loaded active active Slice /system/dhcpcd
Finally, the truth has emerged! system-dhcpcd.slice appears to be active.
But what is that?? Neither the NetworkManager Wiki not the dhcpcd Wiki makes
any mention of a dhcpcd.slice.
So much for RTFM!
Thus to you, Scimmia and Lone Wolf my thanks for your comments which prompted me to 'dig deeper'
and with useful results. Some corrective actions were attempted and seem to work:
4. SO NOW WE TRY TO STOP/DISABLE dhcpcd.service and dhcpcd@.service
$ sudo systemctl stop dhcpcd.service
[sudo] password for xxxxxxxx:
$
$ sudo systemctl stop dhcpcd@.service
Failed to stop dhcpcd@.service: Unit name dhcpcd@.service is missing the instance name.
See system logs and 'systemctl status dhcpcd@.service' for details.
$ sudo systemctl disable dhcpcd.service
$
$ sudo systemctl disable dhcpcd@.service
Removed '/etc/systemd/system/multi-user.target.wants/dhcpcd@eth0.service'.
5. POWER-OFF / REBOOT
Boot up is faster, now 60 seconds; and the wired internet connection works.
6. SO FOR "BELT-and-BRACES" ("SUSPENDERS" in the US) SAFETY mask it:
$ sudo systemctl mask dhcpcd@.service
[sudo] password for xxxxxxxxx:
Created symlink '/etc/systemd/system/dhcpcd@.service' → '/dev/null'.
CONCLUSIONS
I suggest that the Arch Wiki's for NetworkManager and dhcpcd both need a critical
review and appropriate updates but that job is not for the 'unwashed'.
The boot time having been significantly shortened, the posting can be
marked "Solved"
Again thanks.
Dynosaw.
--
Offline
Furthermore, running systemctl can give confusing results (see below).
That's why I asked you to run the command in #2 .
See https://bbs.archlinux.org/viewtopic.php?id=256156 if you want to know where that comes from .
If you feel the NM & dhcpcd wiki pages need changes, start a discussion on their talk pages.
Last edited by Lone_Wolf (2025-10-25 12:30:39)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline