DietPi OS software update broke everything

~# 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 noprefixroute 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:02:94:34 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.180/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.227.5/24 brd 192.168.227.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::886d:aebe:1a5c:7b2b/64 scope link 
       valid_lft forever preferred_lft forever
root@JacoPi:~# 

For whatever reason, there are two IP addresses assigned to the eth0 interface. Let’s see if we can find the configuration.

grep -Hn -A3 -B1 -E '(^|\s)eth0(\s|$)' /etc/network/interfaces /etc/network/interfaces.d/* 2>/dev/null

https://tricorder.pi-hole.net/42Mgpo6R/

I was able to generate a debug log (see above).

And this is what it spits out:

~# grep -Hn -A3 -B1 -E '(^|\s)eth0(\s|$)' /etc/network/interfaces /etc/network/interfaces.d/* 2>/dev/null
/etc/network/interfaces-8-# Ethernet
/etc/network/interfaces:9:allow-hotplug eth0
/etc/network/interfaces:10:iface eth0 inet dhcp
/etc/network/interfaces-11-address 192.168.0.180
/etc/network/interfaces-12-netmask 255.255.255.0
/etc/network/interfaces-13-gateway 192.168.0.180

I am not sure what is causing that second IP address. Thanks.

Linking the related topic on Pi-hole forum: PiHole stopped working after DietPi OS update interrupted - Help - Pi-hole Userspace

So something is assigning an additonal wrong IP address to the system and sometimes gets the default route as well, pointing to a non-existing host/IP.

Problem might be dhcpcd since ifupdown is used as well. First I thought a rogue DHCP server, but the flags shown in ip a do not look like it’s from a DCHP client. However purging dhcpcd is one step that makes sense in any case, then observing whether this IP keeps being assigned.

The debug log is from PiHole I guess. This we we are not able to access as it’s outside our domain.

Jep, was checked over at the Pi-hole forum.