Running latest Debian 12, KDE Plasma 5.27.5. etc/network/interfaces and/or etc/NetworkManager/system-connections is set to configure the NIC to a reserved dhcp ip address. However, upon bootup, the NIC is first assigned a fixed ip address then it obtains the dhcp ip address as configured.
Doesn't matter if using NetworkManager or not, having interfaces file or system-connections files or not. I have been through the combinations of interfaces and NetworkManager managed interfaces (NM ifupdown = true or false). The unwanted fixed ip address is an old fixed ip configuration. As mentioned, I have changed, deleted, re-built, etc., interfaces and system-connections to remove the fixed ip address configuration.
Symptoms: depending on the interfaces / system-connections combo, variously I got:
- NetworkManager would build a manual (fixed) ip address using the same name (eth0) as a dhcp system-connection even though there was no manual system-connection file defined, and no interfaces file either. After bootup, I could select the dhcp configuration and it would switch to the dhcp ip address. But it is a remote computer and needs to boot to the dhcp ip address.
- NetworkManager uninstall completely and using interfaces (old ip address not even in a commented out configuration). At least this configuration assigned both ip addresses so the dhcp ip address was usable upon boot.
It behaves as though the old fixed ip address is being used at boot time before the network stack gets to interfaces or system-connection defined configurations. I have hunted for but can't find where that old fixed ip address may be stored or cached.
Any ideas?

When you say fixed do you mean static ip? Reserved is on the dhcp server side and shouldn't be anything other than dhcp on computer I'd think. An OS shouldn't move between static and dynamic. There are some situations in ilo pxe and such where things happen before actual os boot. Do you have any settings like boot on lan set or enabled in bios/lan card?

Yes, static. Good catch. Static and Reserved DHCP can both be thought of as fixed. Here's what 'ip addr' reports after boot, BEFORE and AFTER doing 'ifup -f eth0' (in the current configuration of the interfaces file and NetworkManager uninstalled, including associated files, it's no longer booting to both ip addresses, just the static one):

BEFORE (after boot):
eth0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet 192.168.0.8/24 brd 192.168.0.255 scope global eth0
valid_lft forever preferred_lft forever

AFTER 'ifup -f eth0':
eth0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet 192.168.0.8/24 brd 192.168.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.0.12/24 brd 192.168.0.255 scope global secondary dynamic eth0
valid_lft 168465sec preferred_lft 168465sec

After the ifup command the computer can be accessed using either ip address.

I agree this shouldn't be happening. There is no iface defined in interfaces that is defined as static nor uses the .8 ip address. And the dhcp behavior is as expected (gets its reserved ip address .12 from the dhcp server in the cable modem) when invoked. No wake-on-LAN, pxe, or any other remote specific configuration. It's just a computer that doesn't have any keyboard, mouse, or monitor attached. It's just supposed to boot, dhcp onto the network, and be available for remote access (ssh, telnet, X2Go, etc.). I have other computers configured similarly and they behave as expected.

It's acting like the static mode and .8 ip address is hiding in some cached file somewhere. Rather than spending a lot of time doing forensics on the network stack boot process, I was hoping someone has seen this before and could point me in the right direction. I'll double check, but I don't recall being able to set an ip address in the BIOS (its an old machine). This is not a show-stopper for me in using the computer, I'm curious more than anything at this point.

BTW, on this computer there is a motherboard NIC (eth0) and a add-in PCI NIC (eth1). I am only connecting one NIC at a time, not both. Same behavior, just different static/dynamic ip addresses (.8/.12 and .9/.13).

Almost seems like the dhcp server can't find mac address lookup before it offers an ip. Wireshare it from a different computer?

Not a networking expert but there are several different networking type services that might be in play. Have you checked the logs and dmesg for any clues? The systemd-analyze blame command will output a list of all running services which might provide a clue.

networking which uses the interfaces file and interfaces.d directory if so configured. As posted ifup/ifdown also uses the same configuration files.

Network Manager which uses its own configuration files.

systemd-networkd which uses its own configuration files

And of course any other script you created to assign an IP address.

In a normal install I believe networking starts which only configures lo and after that Network Manager takes over for the rest of the interfaces. If networking was running at startup I would expect that the .12 address would already be configured? Is networking enabled? Network Manager is not installed so that should not be a factor. Which leaves us with systemd-networkd?

Good thought - helps spark my thinking into other possible solution avenues. I will be looking into all elements of my setup: computer, switches, routers, dns server, dhcp server. As you know, sometimes it can be the simplest thing. In this instance it is strange that the 'unconfigured' static ip addresses happen to be old static addresses assigned to it before I changed to a reserved dhcp setup. I re-allocated ip addresses across devices when I migrated to the reserved dhcp configuration. Because the static addresses are not just random, but from a previous configuration, it leads me towards a 'lingering config' being held somewhere.

I could just re-allocate those ip addresses back to .8 & .9, but I want those reserved for other future devices and to maintain the advantages of going with a reserved dhcp setup. Anyway, now it's a puzzle begging to be solved.

Setup: [computer] <--> [switch (dumb 5-port, unmanaged)] <--> [AP (Access Point) wireless router also used as a second 4-port wired switch] <--> [AP wireless router, LAN dns server and 4-port switch] <--> [cable modem wireless router, dhcp server, 4-port switch] <--> [internet via cable]. The '<-->' denotes a wired connection between devices from the computer to the internet. This setup gives me wired connections to fixed devices (printers, print servers, desktop computers (one of which is this naughty computer), docked laptops, SmartTV) and APs for mobile wireless devices. There are 3 other computers wired to the first switch and the first AP/switch that are configured the same way as the problem child and they behave just fine.

Time for the ol' divide and conquer approach... Next step: unhook everything after the first AP router. I can reconfigure the first AP router as a temporary dhcp server to see if its anything further downstream.

====================================

UPDATE: Found it. At some point there was a 3rd network manager installed on the computer - Connection Manager (connman). Uninstalled connman, rebooted, and all is well. Something simple...

How found: After isolating the computer and first AP (used as temporary dhcp server) from the rest of the network the computer still configured itself to the old static addresses. A search through the /var/log files for '192.168.0.' showed it in connection with the connman daemon (connmand) - found it in the daemon.log. A quick internet search to find out what connman was, then running connman-gtk (also installed), showed it was the culprit and was configuring the NICs in the old configuration. Apparently connman was run ahead of the normal network/interfaces and NetworkManager. I don't even remember installing connman it's been that long ago. Live and learn...

You have a couple of AP wireless routers. If these are routers I assume their DHCP servers are turned off?

See UPDATE in previous post.