Was the software title installed freshly or updated/migrated? Freshly
Can this issue be replicated on a fresh installation of DietPi? Probably
Steps to reproduce
I setup a fresh install of DietPi with an initial static ip address of 192.168.1.6 with the intention of testing the setup of mosquitto and node-red before moving it to a production environment by changing the ip address to 192.168.1.8. This is easier than having to change 20+ devices to point to a new server.
Using Dietpi-config I changed the static ip address.
Both old and new addresses are now accessible and I can SSH into either. I rebooted multiple times and even rebooted the router as a precaution. My configuration for mosquitto and node-red works fine but the issue is that I seem to have retained the old IP address and don’t know how to get rid of it. Thanks in advance for any help, I’m loving DietPi so far.
Expected behaviour
Below outputs are with me logged in as 192.168.1.8 via wireguard VPN:
Only one ip address should be configured.
ip a | grep eth0 listed below shows a secondary old IP address 192.168.1.6 on second line.
dietpi@DietPi:~$ ip a | grep eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
inet 192.168.1.8/24 brd 192.168.1.255 scope global eth0
inet 192.168.1.6/24 brd 192.168.1.255 scope global secondary noprefixroute eth0
========================
dietpi@DietPi:~$ ip r
default via 192.168.1.1 dev eth0 src 192.168.1.6 metric 202
10.104.139.0/24 dev wg0 proto kernel scope link src 10.104.139.1
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.6 metric 202
=========================
dietpi@DietPi:~$ ip addr show
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
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether dc:a6:32:b3:b1:a4 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.8/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.1.6/24 brd 192.168.1.255 scope global secondary noprefixroute eth0
valid_lft forever preferred_lft forever
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.104.139.1/24 scope global wg0
valid_lft forever preferred_lft forever
==========================
/etc/network/interfaces looks ok. I have wifi disabled in dietpi-config
Used that command and it still shows after a reboot
dietpi@DietPi:~$ ip r
default via 192.168.1.1 dev eth0 src 192.168.1.6 metric 202
10.104.139.0/24 dev wg0 proto kernel scope link src 10.104.139.1
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.6 metric 202
dietpi@DietPi:~$ ip a | grep eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
inet 192.168.1.8/24 brd 192.168.1.255 scope global eth0
inet 192.168.1.6/24 brd 192.168.1.255 scope global secondary noprefixroute eth0
Hi, no it didn’t. I have only one reservation on the router and that’s not it.
I’ve researched this a bit and I’m inclined to think this is an issue with the way it is implemented and that a full wipe and reinstall of OS is required. Not ideal though as fundamental issue remains.
I’m not sure if I’m leading to the right direction. Would you please check the /etc/dhcpcd.conf file? There should be lines of configuration for static address setup. Hope this helps.
You should find sth similar as below. Please configure accordingly of those parameters:
interface eth0
static ip_address=192.168.8.10/24
static routers=192.168.8.1
static domain_name_servers=127.0.0.1 1.1.1.1
Do you mean the way it is implemented into DietPi?
I doubt that.
I switched on my test machine from DHCP to static, and after a reboot I changed this static IP to another static IP without leaving a secondary IP on the interface.
Did you install dhcpcd manually, or was it probably some 3rd party installer? It is not pre-installed on DietPi, but if it’s installed and configured as in your case, of course it will ask for a DHCP lease. Try to purge it, and see whether this would remove another package (which then depends on it) as well:
Until summer 2021, the Pi-hole installer installed it as dependency. So if Pi-hole was installed in the past, that may be a remain. Although we masked the service, when Pi-hole was installed via dietpi-software.
I discovered by chance that it is pivpn that is installing dhcpcd5. I was doing a repair install and noted the following appeared:
Somehow it had the old IP address! Anyway sudo apt purge dhcpcd5 sorted it
Recommended packages:
openresolv | resolvconf
The following NEW packages will be installed:
dhcpcd5
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 163 kB of archives.
After this operation, 432 kB of additional disk space will be used.
Get:1 https://archive.raspberrypi.org/debian bullseye/main arm64 dhcpcd5 arm64 1:8.1.2-1+rpt9 [163 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 163 kB in 0s (465 kB/s)
Selecting previously unselected package dhcpcd5.
(Reading database ... 34970 files and directories currently installed.)
Preparing to unpack .../dhcpcd5_1%3a8.1.2-1+rpt9_arm64.deb ...
Unpacking dhcpcd5 (1:8.1.2-1+rpt9) ...
Setting up dhcpcd5 (1:8.1.2-1+rpt9) ...
Created symlink /etc/systemd/system/multi-user.target.wants/dhcpcd.service -> /lib/systemd/system/dhcpcd.service.
::: Package dhcpcd5 successfully installed!
::: PiVPN Automated Installer
::: This installer will transform your Debian host into an OpenVPN or WireGuard server!
::: Initiating network interface
::: Enable forced IPv6 route with no IPv6 uplink on server.
::: Using interface: eth0 for IPv4
::: Your static IPv4 address: 192.168.1.6/24
