Hey guys! Just updated dhcpcd and performed a reboot. Now my network connection is not working. Any ideas? I use runit.
I just had similar experience - tried to figure out the reason it does not work for about 20 minutes, downgraded back to 9.2.0-1, and now am writing this.
Thanks for report.
Any error log or more detailed specification of problems is welcome. I didn't have anyone else (archlinux) reporting any problems.
"Connecting is not working" say us nothing
It works here connecting manually: dhcpcd -4 -t 0 -K wlpXsY
After upgrading to dhcpcd 9.3.1-1 and rebooting:
$ ping -c 3 8.8.8.8
ping: connect: Network is unreachable
I noticed (in htop) that processes:
dhcpcd: [control proxy]
dhcpcd: [network proxy]
dhcpcd: [privileged actioneer]
in dhcpcd 9.2.0-1 are childs of
dhcpcd: [master] [ip4] [ip6]
but in dhcpcd 9.3.1-1
dhcpcd: [network proxy]
dhcpcd: [privileged actioneer]
are orphans, and
dhcpcd: [control proxy]
does not exist.
furhermore, process
dhcpcd: [privileged actioneer]
in dhcpcd 9.3.1-1 does not spawn process
dhcpcd: [BPF ARP] wlp0s18f2u5 192.168.100.4
as it does in dhcpcd 9.2.0-1
# sv status dhcpcd
run: dhcpcd: (pid 1324) 12s
# sv stop dhcpcd
ok: down: dhcpcd: 0s, normally up
but processes
dhcpcd: [network proxy]
dhcpcd: [privileged actioneer]
remain.
# kill -9 999 ;# dhcpcd: [network proxy]
# kill -9 998 ;# dhcpcd: [privileged actioneer]
# dhcpcd -B -M wlp0s18f2u5
main: control_open: Connection refused
dhcpcd-9.3.1 starting
dev: loaded udev
DUID 00:04:00:c8:00:1e:8c:00:00:29:12:80:00:26:18:df:a7:ac
wlp0s18f2u5: connected to Access Point: Net2
ps_ctl_listen: read: Success
wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant.conf -iwlp0s18f2u5
is still running
$ ping -c 3 8.8.8.8
ping: connect: Network is unreachable
downgrading back to dhcpcd 9.2.0-1:
$ cd /var/cache/pacman/pkg/
$ yay -U dhcpcd-9.2.0-1-x86_64.pkg.tar.zst
loading packages...
warning: downgrading package dhcpcd (9.3.1-1 => 9.2.0-1)
... skipped ...
warning: directory permissions differ on /var/lib/dhcpcd/
filesystem: 750 package: 755
after reboot:
$ ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=108 time=68.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=108 time=68.0 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=108 time=69.3 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 68.010/68.732/69.259/0.528 ms
I also get the "main: control_open: Connection refused" message when I attempt to use the newest version of dhcpcd. I tried a few different options to the daemon but I always get the same message.
changelog 9.2.0 -> 9.3.1
https://github.com/rsmarples/dhcpcd/compare/dhcpcd-9.2.0...dhcpcd-9.3.1
and some changes on archlinux's side:
https://github.com/archlinux/svntogit-packages/commit/4757eea821e405202a029725ab6ee11bd1919d8a#diff-3e341d2d9c67be01819b25b25d5e53ea3cdf3a38d28846cda85a195eb9b7203a
artoo pushed new dhcpcd-openrc 2020102 version, try it! (is in testing now)
It looks like the dhcpcd-openrc script got rid of the argument that runs it in the foreground. I sure hope we don't have to do that for runit or s6. That goes against their process supervision model (still need to test this some more though).
Sidenote: The systemd service also forks, eh.
So there's no more way to use dhcpcd on runit?
No it can still work. It's just uglier.
This problem is present at least in my installation, it wait forever when booting.
downgrading to 9.2.0 solve the problem.
Artix Linux and OpenRC.
What information do you need to point out the problem?
The bug is present doing a search on internet,
https://www.reddit.com/r/archlinuxarm/comments/jjx0p3/dhcpcd9311_caused_dhcp_failure/
I don't know if dome LFS information about the process to adapt 9.3.1 that introduce privileged separation is relevant.
http://www.linuxfromscratch.org/blfs/view/systemd/basicnet/dhcpcd.html
Maybe using some helper like conman did not create the problem, but setting simply the interface as described in the documentation.
i.e. using the netifrc as described in the installation wiki make the machine unbootable due to the hang of dhcpcd getting stuck searching to set up things.
Regards
Carlo D.
I'm currently coordinating with upstream on this one. Might have something to do with SECCOMP support which is apparently CPU-dependent.
If it could help here my lscpu output
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 36 bits physical, 48 bits virtual
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 42
Model name: Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz
Stepping: 7
CPU MHz: 1622.268
CPU max MHz: 3300,0000
CPU min MHz: 1600,0000
BogoMIPS: 6587.75
Virtualization: VT-x
L1d cache: 64 KiB
L1i cache: 64 KiB
L2 cache: 512 KiB
L3 cache: 3 MiB
NUMA node0 CPU(s): 0-3
Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled
Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cach
e flushes, SMT vulnerable
Vulnerability Mds: Vulnerable: Clear CPU buffers attempted, no mic
rocode; SMT vulnerable
Vulnerability Meltdown: Mitigation; PTI
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user
pointer sanitization
Vulnerability Spectre v2: Mitigation; Full generic retpoline, IBPB condit
ional, IBRS_FW, STIBP conditional, RSB filling
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtr
r pge mca cmov pat pse36 clflush dts acpi mmx f
xsr sse sse2 ht tm pbe syscall nx rdtscp lm con
stant_tsc arch_perfmon pebs bts rep_good nopl x
topology nonstop_tsc cpuid aperfmperf pni pclmu
lqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx
16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_dead
line_timer xsave avx lahf_lm epb pti ibrs ibpb
stibp tpr_shadow vnmi flexpriority ept vpid xsa
veopt dtherm arat pln pts
Upstream is working on fixing this, but there's a workaround in the meantime. You just need to run a syslogd service (syslog-ng, metalog, etc.) at the same time. It seems like some of the SECCOMP stuff implicitly assumed /dev/log existed when in fact it might not.
Edit: To be clearer, the syslog service needs to be up before dhcpcd. So if you start them up at boot in parallel (like in runit or s6), it probably won't work.
dhcpcd-9.3.1.1 in the gremlins repo should resolve this issue. It'll make its way into stable soon.
It works fine. Thank you!