Anaconda installer renaming first network interface to ksdev0

In Rocky 8 VM (hypervisor is also Rocky 8) "first " network interface is ksdev0, the “second” is enp4s0. I thought both of them should be en*.

There is nothing special about how they are defined (virt-install command below). Also there is nothing special in libvirt domain file (below).

Is there anything I can do enforce the en* naming?

virt_install_command: "virt-install --name {{ next_server_name }} 
--ram=2048 --vcpus=2
--os-type {{ tmp_virt_ostype }} --os-variant {{ tmp_virt_osvariant }} 
--disk {{ next_server_name }}.qcow2,pool=vm,bus=virtio,size=10,format=qcow2 
{% for net in net_config -%}
{% for net_type in vm_net_type if == -%}
--network network:net-ovs-br0,mac={{ net.mac }},portgroup=vlan-{{ net_type.vlan }} 
{% endfor -%}
{% endfor -%}
--location {{ tmp_virt_iso }} 
--nographics --noautoconsole --watchdog default 
--initrd-inject {{ kickstart_file }} 
--extra-args='inst.ks=file:/{{ next_server_name }}.ks console=ttyS0,115200n8'"
    <interface type='network'>
      <mac address='52:54:00:a0:2b:60'/>
      <source network='net-ovs-br0' portgroup='vlan-6'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
    <interface type='network'>
      <mac address='52:54:00:b0:2b:60'/>
      <source network='net-ovs-br0' portgroup='vlan-22'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>

I have found the guilty party:

Anaconda installer is placing configuration file for systemd-networkd.
But the system is using network manager (and networkd is not even installed)…

Interface names like “enp5s0” are normal on RHEL 8.4, even on bare metal.

RHEL 7 had already predictable names on metal. CentOS 7 VM’s still get “eth*” names, which aren’t predictable.

OT: There were/is extra twist. Anaconda installer configures connections. It does bind the connection to device by MAC address, rather than the name of the device. When you create connection with nmcli you must use the name of device. It is possible to modify connection later to bind with MAC, not name. How did I learn this? I had C7 VM with three manually defined connections. Every second boot had net down, for the “eth*” names were truly random and config was bound to those names … except for the one connection that the installer had generated.

So, it is anaconda installer renaming the network interface (title updated).

Instead of figuring out why anaconda is doing that (like sane person would do), I resorted to red herring workaround: I created dummy interface for anaconda to rename, and than I removed that interface.
Problem solved.

In kickstart file I match interfaces with MAC address:

network --device={{ net.mac }} --bootproto=static --activate --onboot=on --noipv6 --ip={{ net.ip }} --netmask= --gateway={{ gw }} --nameserver={{ ns } --hostname={{ tmp_ks_hostname }}

Extra twist is that anaconda is placing configuration file for systemd-networkd (at least that is my understanding). But systemd-networkd is not installed, so how this is applied?

Removing the file in kickstart (in %post) solves naming issue, but than the interface is not configured…


How about package NetworkManager-config-server?

Description  : This adds a NetworkManager configuration file to make it behave more
             : like the old "network" service. In particular, it stops NetworkManager
             : from automatically running DHCP on unconfigured ethernet devices, and
             : allows connections with static IP addresses to be brought up even on
             : ethernet devices with no carrier.
             : This package is intended to be installed by default for server
             : deployments.

Nice find.

But this package provides only one file:
that disables by default the DHCP on unconfigured interfaces.

Since I am using static IP this does not help me.

What could help is to stop using kickstart’s network command, and configure network interfaces with nmcli in the kickstart’s %post section. But that means parsing nmcli output…

What if … you leave the --activate out and have --onboot=no? You could even have it with default DHCP config, but since it will never been started …

That does not help (–no-activate --onboot=no on both interfaces)…
There are 2 interfaces. The “first” one still gets renamed to ksdev0, and then renamed back - except its “correct” configuration stays in the ksdev0 connection profile.
The “Wired connection 1” profile is a default DHCP

[a@a ~]$ ip a s                                                                                           
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 scope host lo                                                                                     
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:a0:4e:60 brd ff:ff:ff:ff:ff:ff
    inet brd scope global dynamic noprefixroute enp3s0
       valid_lft 6174sec preferred_lft 6174sec
    inet6 fe80::9a55:18b8:ef75:a4b8/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:b0:4e:60 brd ff:ff:ff:ff:ff:ff
[a@a ~]$ nmcli d s
DEVICE  TYPE      STATE         CONNECTION         
enp3s0  ethernet  connected     Wired connection 1 
enp4s0  ethernet  disconnected  --                 
lo      loopback  unmanaged     --                 
[a@a ~]$ nmcli c s                                                                                         
NAME                UUID                                  TYPE      DEVICE 
Wired connection 1  05cbf7c0-40b7-3a5e-b8ec-5e7a7694ad1d  ethernet  enp3s0 
enp4s0              503de7d2-fe5d-45d4-ac2e-561641c06a25  ethernet  --     
ksdev0              a748ee03-c68e-4e2c-ac53-bd5ad50ba45c  ethernet  --