How is your network setup?

Contribute Room
22 
root@uno:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto enp1s0
iface enp1s0 inet dhcp
# This is an autoconfigured IPv6 interface
iface enp1s0 inet6 auto

dns-nameserver 192.168.1.1


/etc/systemd/network/dhcp.network
root@uno:~# cat /etc/systemd/network/dhcp.network
[Match]
Name=en*

[Network]
DHCP=yes

root@uno:~# cat /etc/systemd/network/dhcp.network
[Match]
Name=en*

[Network]
DHCP=yes

root@uno:\~# systemctl status networking 
**●** networking.service - Raise network interfaces 
     Loaded: loaded (/lib/systemd/system/networking.service; **enabled**; preset: **enabled**) 
     Active: **active (exited)** since Wed 2026-09-30 11:44:50 CEST; 1 day 2h ago 
       Docs: man:interfaces(5) 
    Process: 827 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=0/SUCCESS) 
    Process: 1031 ExecStart=/bin/sh -c if \[ -f /run/network/restart-hotplug \]; then /sbin/ifup > 
   Main PID: 1031 (code=exited, status=0/SUCCESS) 
      Tasks: 1 (limit: 14300) 
     Memory: 3.6M 
        CPU: 382ms 
     CGroup: /system.slice/networking.service 
             └─887 dhclient -4 -v -i -pf /run/dhclient.enp1s0.pid -lf /var/lib/dhcp/dhclient.en> 

Oct 01 07:25:50 uno dhclient\[887\]: **suspect value in domain_search option - discarded** 
Oct 01 07:25:50 uno dhclient\[887\]: **suspect value in domain_search option - discarded** 
Oct 01 07:25:50 uno dhclient\[887\]: **Error printing text.** 
Oct 01 07:25:50 uno dhclient\[887\]: bound to 192.168.1.35 -- renewal in 18026 seconds. 
Oct 01 12:26:16 uno dhclient\[887\]: DHCPREQUEST for 192.168.1.35 on enp1s0 to 192.168.1.1 port 67 
Oct 01 12:26:16 uno dhclient\[887\]: DHCPACK of 192.168.1.35 from 192.168.1.1 
Oct 01 12:26:16 uno dhclient\[887\]: **suspect value in domain_search option - discarded** 
Oct 01 12:26:16 uno dhclient\[887\]: **suspect value in domain_search option - discarded** 
Oct 01 12:26:16 uno dhclient\[887\]: **Error printing text.** 
Oct 01 12:26:16 uno dhclient\[887\]: bound to 192.168.1.35 -- renewal in 16278 seconds. 
lines 1-23/23 (END)

root@uno:\~# systemctl status systemd-network 
**Unit systemd-network.service could not be found.**

root@uno:\~# systemctl status systemd-resolved 
**Unit systemd-resolved.service could not be found.**

root@uno:\~# cat /etc/systemd/network/dhcp.network 
\[Match\] 
Name=en\* 

**●** NetworkManager.service - Network Manager 
     Loaded: loaded (/lib/systemd/system/NetworkManager.service; **enabled**; preset: **enabled**) 
     Active: **active (running)** since Wed 2026-09-30 11:44:48 CEST; 1 day 2h ago 
       Docs: man:NetworkManager(8) 
   Main PID: 738 (NetworkManager) 
      Tasks: 3 (limit: 14300) 
     Memory: 11.5M 
        CPU: 4.133s 
     CGroup: /system.slice/NetworkManager.service 
             └─738 /usr/sbin/NetworkManager --no-daemon 

Sep 30 11:44:55 uno NetworkManager\[738\]: <info>  \[1790761495.0167\] device (docker0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'external') 
Sep 30 11:44:55 uno NetworkManager\[738\]: <info>  \[1790761495.0170\] device (docker0): state change: prepare -> config (reason 'none', sys-iface-state: 'external') 
Sep 30 11:44:55 uno NetworkManager\[738\]: <info>  \[1790761495.0172\] device (docker0): state change: config -> ip-config (reason 'none', sys-iface-state: 'external') 
Sep 30 11:44:55 uno NetworkManager\[738\]: <info>  \[1790761495.0176\] device (docker0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'external') 
Sep 30 11:44:55 uno NetworkManager\[738\]: <info>  \[1790761495.0263\] device (docker0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'external') 
Sep 30 11:44:55 uno NetworkManager\[738\]: <info>  \[1790761495.0266\] device (docker0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'external') 
Sep 30 11:44:55 uno NetworkManager\[738\]: <info>  \[1790761495.0272\] device (docker0): Activation: successful, device activated. 
Sep 30 11:44:56 uno NetworkManager\[738\]: <info>  \[1790761496.4814\] manager: (veth3d013f2): new Veth device (/org/freedesktop/NetworkManager/Devices/4) 
Sep 30 11:44:56 uno NetworkManager\[738\]: <info>  \[1790761496.5283\] device (veth3d013f2): carrier: link connected 
Sep 30 11:44:56 uno NetworkManager\[738\]: <info>  \[1790761496.5286\] device (docker0): carrier: link connected

root@uno:\~# ip -br link show |cut -d" " -f1 
lo 
enp1s0 
docker0 
veth3d013f2@if2

root@uno:\~# grep -i "net.ifnames" /boot/grub/grub.cfg 
root@uno:\~#

root@uno:\~# cat /etc/udev/rules.d/70-persistent-net.rules | sed -E "s/\[0-9a-f:\]{17}/aa:bb:cc:dd:
ee:ff/" 
cat: /etc/udev/rules.d/70-persistent-net.rules: No such file or directory

root@uno:\~# yunohost --version 
**yunohost**:  
  **repo**: stable 
  **version**: 12.1.41.2 
**yunohost-admin**:  
  **repo**: stable 
  **version**: 12.1.15 
**yunohost-portal**:  
  **repo**: stable 
  **version**: 12.1.2 
**moulinette**:  
  **repo**: stable 
  **version**: 12.1.4 
**ssowat**:  
  **repo**: stable 
  **version**: 12.1.1 
root@uno:\~#
23

Maybe something like the following can help with classic setups.
If /etc/network/interfaces exists, maintain near the top some:

rename <whatever_current_new_pesky_name>=<known_previous_name>

The topic seems a saga and odyssey https://wiki.debian.org/NetworkInterfaceNames, don’t get let on by any sirens daemon.

Even if there is some narrow theoretic definition to make that “predictable” appear ‘true’…
Apparently predictable in some narrow sense (but not persistent) doesn’t constitute much of any practical help. Neither for you devs nor for end-users.

Practically, debian seems to only support “This time your network device X will be renamed to Y after rebooting your upgraded OS (on your current, unchanged setup)” and leave the problem to their users.

In the end, that’s what a meek release note entry seems to do, producing yet something more for their users (distros) to swallow from the once “universal distribution”.

As it requires probing the installed system, and the names are clearly expected to change when switching underlying hardware/vm, I’d consider these practically impossible-to-predict changes of in-use interface names (which may be named in differnt forms of xy.z@abc). And I’d also consider it completely needless, even an anti-pattern, to change names during upgrades.

Upstream and Debian decided to break the naming with upgrades, instead of persisting the names, and to mention only one particular way to persist names in upgrade(!) release notes? Believe that preference was by accident?

24

Hm, there seem to exist different tools to persist the naming independent of the network management setup stack The name game: Naming network interfaces in Linux