I don’t know if this is a bug with dietpi, or pihole. But after a fresh dietpi+pihole install, “sudo systemctl status” shows the system state as degraded, because dhcpcd.service failed to start.
Steps to reproduce:
- start dietpi with freshly created microsd image for raspberry pi.
- at the software configuration screen, add only pi-hole.
- in pi-hole configuration, adjust (or accept) the ip as static ip.
- finish the install.
After the install completes, run “sudo systemctl status”, it shows the status as degraded. Running “systemctl” shows that it is the dhcpcd.service that failed to start.
I tried this 3 times, on pi3 as well as pi2. Same result. If I don’t select pi-hole during the initial install, systemctl status is NOT degraded after install. But, installing pi-hole afterwards resulted in the same degraded systemctl status.
The bug does not occur with pi-hole on Raspbian Lite (2019/04 edition, Stretch). Systemctl status shows normal. Even though I am using static ip, dhcpcd.service is running fine on raspbian lite.
Has anyone seen this issue? I disabled dhcpcd.service with instruction from https://raspberrypi.stackexchange.com/questions/78510/disable-dhcpcd-service-for-static-ip/78518, and the status is now normal. But, it doesn’t look good when fresh dietpi+pihole results in degraded systemctl status.
Before pi-hole install, with static ip setup:
dietpi@DietPi:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 15G 1.7G 13G 12% /
devtmpfs 484M 0 484M 0% /dev
tmpfs 488M 0 488M 0% /dev/shm
tmpfs 488M 13M 476M 3% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 488M 0 488M 0% /sys/fs/cgroup
tmpfs 1023M 4.0K 1023M 1% /tmp
tmpfs 50M 0 50M 0% /var/log
tmpfs 10M 1.4M 8.7M 14% /DietPi
/dev/mmcblk0p1 253M 41M 212M 17% /boot
root@DietPi:~# systemctl status
● DietPi
State: running
Jobs: 0 queued
Failed: 0 units
Since: Thu 1970-01-01 01:00:02 BST; 49 years 7 months ago
CGroup: /
├─init.scope
│ └─1 /sbin/init
└─system.slice
├─system-getty.slice
│ └─getty@tty1.service
│ ├─596 /bin/login -p --
│ └─662 -bash
├─cron.service
│ └─640 /usr/sbin/cron -f
├─systemd-udevd.service
│ └─155 /lib/systemd/systemd-udevd
├─systemd-journald.service
│ └─111 /lib/systemd/systemd-journald
├─haveged.service
│ └─234 /usr/sbin/haveged --Foreground --verbose=1 -w 1024
└─dropbear.service
├─602 /usr/sbin/dropbear -p 22 -W 65536
├─719 /usr/sbin/dropbear -p 22 -W 65536
├─720 -bash
├─778 systemctl status
└─779 pager
root@DietPi:~# cat /etc/network/interfaces | egrep -v "^\s*(#|$)"
source interfaces.d/*
auto lo
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.9
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 8.8.8.8 8.8.4.4
iface wlan0 inet dhcp
address 0.0.0.0
netmask 0.0.0.0
gateway 0.0.0.0
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
root@DietPi:~# cat /etc/dhcpcd.conf | egrep -v "^\s*(#|$)"
hostname
clientid
persistent
option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option interface_mtu
require dhcp_server_identifier
slaac private
After pi-hole install:
root@DietPi:~# systemctl status
● DietPi
State: degraded
Jobs: 0 queued
Failed: 1 units
Since: Thu 1970-01-01 01:00:02 BST; 49 years 7 months ago
CGroup: /
├─init.scope
│ └─1 /sbin/init
└─system.slice
├─php7.3-fpm.service
│ ├─703 php-fpm: master process (/etc/php/7.3/fpm/php-fpm.conf)
│ ├─710 php-fpm: pool www
│ ├─711 php-fpm: pool www
│ ├─712 php-fpm: pool www
│ └─713 php-fpm: pool www
├─system-getty.slice
│ └─getty@tty1.service
│ └─658 /sbin/agetty -o -p -- \u --noclear tty1 linux
├─pihole-FTL.service
│ └─637 /usr/bin/pihole-FTL
├─lighttpd.service
│ └─720 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf
├─cron.service
│ └─724 /usr/sbin/cron -f
├─systemd-udevd.service
│ └─156 /lib/systemd/systemd-udevd
├─systemd-journald.service
│ └─100 /lib/systemd/systemd-journald
├─haveged.service
│ └─233 /usr/sbin/haveged --Foreground --verbose=1 -w 1024
└─dropbear.service
├─664 /usr/sbin/dropbear -p 22 -W 65536
├─750 /usr/sbin/dropbear -p 22 -W 65536
├─772 -bash
├─832 systemctl status
└─833 pager
root@DietPi:~# systemctl status dhcpcd
Warning: The unit file, source configuration file or drop-ins of dhcpcd.service changed on disk. Run 'systemc
tl daemon-reload' to reload units.
● dhcpcd.service - dhcpcd on all interfaces
Loaded: loaded (/lib/systemd/system/dhcpcd.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/dhcpcd.service.d
└─wait.conf
Active: failed (Result: exit-code) since Sat 2019-08-24 16:30:16 BST; 1min 22s ago
Process: 236 ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -w (code=exited, status=6)
Aug 24 16:30:16 DietPi systemd[1]: Starting dhcpcd on all interfaces...
Aug 24 16:30:16 DietPi dhcpcd[236]: Not running dhcpcd because /etc/network/interfaces
Aug 24 16:30:16 DietPi dhcpcd[236]: defines some interfaces that will use a
Aug 24 16:30:16 DietPi dhcpcd[236]: DHCP client or static address
Aug 24 16:30:16 DietPi systemd[1]: dhcpcd.service: Control process exited, code=exited, status=6
/NOTCONFIGURED
Aug 24 16:30:16 DietPi systemd[1]: dhcpcd.service: Failed with result 'exit-code'.
Aug 24 16:30:16 DietPi systemd[1]: Failed to start dhcpcd on all interfaces.
root@DietPi:~# cat /etc/dhcpcd.conf | egrep -v "^\s*(#|$)"
hostname
clientid
persistent
option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option interface_mtu
require dhcp_server_identifier
slaac private
interface eth0
static ip_address=192.168.1.9/24
static routers=192.168.1.1
static domain_name_servers=127.0.0.1
root@DietPi:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 15G 1.8G 13G 13% /
devtmpfs 484M 0 484M 0% /dev
tmpfs 488M 44K 488M 1% /dev/shm
tmpfs 488M 6.5M 482M 2% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 488M 0 488M 0% /sys/fs/cgroup
tmpfs 50M 32K 50M 1% /var/log
tmpfs 1023M 4.0K 1023M 1% /tmp
tmpfs 10M 1.4M 8.7M 14% /DietPi
/dev/mmcblk0p1 253M 41M 212M 17% /boot
wildgoose
Disable dhcpcd: systemctl disable dhcpcd
Or purge it: apt purge dhcpcd5
It is not required, we use isc-dhcp-client and configure static IP via usual /etc/network/intefaces static entries for the interfaces. Pi-hole installs dhcpcd to then setting static IPs via it’s config, so a DHCP client is installed to disable DHCP… Something that works, but is kinda funny and not required, however so far I could not convince the devs to set static IPs via interfaces options and skip installing a DHCP client that conflicts with default Debian setup.
I am anyway currently tuning webserver configs for Pi-hole and will add disabling dhcpcd to the install steps. I think purging it, even that it would be cleaner, is reverted with every pihole -up.
Ah I see. Thanks for the reply! So dietpi uses a slightly different flavor of dhcp client than what pihole wants to install. Make sense.
Pihole should have an option to not touch the network setting. If I already configured static ip on the host, there’s no reason for pihole to mess with it. I also feels like it is the configuration file change that pihole made that broke it. I did notice pihole installed dhcpcd5 during the initial steps, but before the pihole configure step (after the package is installed), I recall systemctl status stilled showed everything is ok. Not clear exaclty what configuration change broke it…
wildgoose
I’m not sure if dhcpcd is started automatically on install, but definitly after reboot. AFAIK Pi-hole does not touch the interface settings in /etc/network/interfaces. It works around this by applying the settings with dhcpcd. But as can be seen this does not work, if /etc/network/interfaces is configured already the regular way.
Here is the part that makes it “fail”:
Aug 24 16:30:16 DietPi systemd[1]: Starting dhcpcd on all interfaces...
Aug 24 16:30:16 DietPi dhcpcd[236]: Not running dhcpcd because /etc/network/interfaces
Aug 24 16:30:16 DietPi dhcpcd[236]: defines some interfaces that will use a
Aug 24 16:30:16 DietPi dhcpcd[236]: DHCP client or static address
- It requires /etc/network/interfaces declarations to look like this: iface eth0 inet manual
- ifupdown (the lower-level tool set to handle interfaces on Debian) configures static IPs itself when those lines end with static instead of manual.
- isc-dhcp-client would apply DHCP leased IPs, if those lines end with dhcp.
So yeah whether it is better not not to either mess with existing /etc/network/interfaces or apply static IP via an DHCP client that only disables itself and which does not work in above cases, is another question. But I totally agree that it should be possible to skip this setup and allow the user so apply static IPs oneself beforehand.
We already committed the ability to skip Lighttpd install with Pi-hole (to allow installing other webservers without running into conflicts) a while ago, so I think the guys will be open for making the dhcpcd5 install + interface configuration optional as well. I will have a look when I can.