Package: grml-debootstrap
Version: 0.88
Severity: important

We noticed that the network configuration generated by
grml-debootstrap is unreliable for the predictable network naming
schema (when net.ifname=0 isn't set).

The underlying code in grml-debootstrap currently iterates over all
network devices via:

  for interface in $(udevadm info -e | sed -n -e 's/E: 
ID_NET_NAME_PATH=\([^$*]\)/\1/p'); do
  [...]

This means that we get something like the following for a (Proxmox)
VM with a virtio network device:

  # udevadm info -e | grep 'ID_NET_NAME_PATH'
  E: ID_NET_NAME_PATH=enp0s18

While on actual boot the device is named ens18 then. This results in
the VM having a broking network configuration.

I managed to track this down already. In systemd's link_config_apply
function (defined in src/udev/net/link-config.c) we have:

|         switch (policy) {
|         case NAMEPOLICY_KERNEL:
|                 if (name_type != NET_NAME_PREDICTABLE)
|                         continue;
|
|                 /* The kernel claims to have given a predictable name, keep 
it. */
|                 log_device_debug(device, "Policy *%s*: keeping predictable 
kernel name",
|                                  name_policy_to_string(policy));
|                 goto no_rename;
|         case NAMEPOLICY_KEEP:
|                 if (!IN_SET(name_type, NET_NAME_USER, NET_NAME_RENAMED))
|                         continue;
|
|                 log_device_debug(device, "Policy *%s*: keeping existing 
userspace name",
|                                  name_policy_to_string(policy));
|                 goto no_rename;
|         case NAMEPOLICY_DATABASE:
|                 (void) sd_device_get_property_value(device, 
"ID_NET_NAME_FROM_DATABASE", &new_name);
|                 break;
|         case NAMEPOLICY_ONBOARD:
|                 (void) sd_device_get_property_value(device, 
"ID_NET_NAME_ONBOARD", &new_name);
|                 break;
|         case NAMEPOLICY_SLOT:
|                 (void) sd_device_get_property_value(device, 
"ID_NET_NAME_SLOT", &new_name);
|                 break;
|         case NAMEPOLICY_PATH:
|                 (void) sd_device_get_property_value(device, 
"ID_NET_NAME_PATH", &new_name);
|                 break;
|         case NAMEPOLICY_MAC:
|                 (void) sd_device_get_property_value(device, 
"ID_NET_NAME_MAC", &new_name);
|                 break;
|         default:
|                 assert_not_reached("invalid policy");
|         }

So if a device has the propery ID_NET_NAME_PATH set (e.g. enp0s18),
but also ID_NET_NAME_SLOT (ens18), we can't just use the value from
ID_NET_NAME_PATH but have to follow the precedence.

I tend to call this a RC bug, so we should get this fixed for
Debian/buster.

regards
-mika-

Attachment: signature.asc
Description: Digital signature

Reply via email to