CentOS 7 (dracut) находит противоречивые имена сетевых устройств, вызывающие проблемы при кикстарте

Я использую параметры загрузкиbiosdevname=1 net.ifnames=1чтобы получить согласованные и предсказуемые имена устройств. Я начинаю замечать проблему: в некоторых случаях имена сетевых устройств не совпадают. Например, если я перейду в оболочку отладки dracut и посмотрю вывод rdsosreport.txt, я увижу следующее:

      + ip addr
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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: p3p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a8:b4:56:50:97:08 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a8:b4:56:50:97:09 brd ff:ff:ff:ff:ff:ff

Обратите внимание, что существует сочетание последовательного (p3p1) и устаревшего стиля именования (eth1). Однако, если я посмотрю на интерфейсы оболочки отладки dracut, я увижу следующее:

      initqueue:/run/initramfs# ip addr
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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: p3p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a8:b4:56:50:97:08 brd ff:ff:ff:ff:ff:ff
3: p3p2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a8:b4:56:50:97:09 brd ff:ff:ff:ff:ff:ff

p3p1/p3p2 — правильные ожидаемые имена. По какой-то причине в начале последовательности initrd они появляются в смешанном формате. Я предполагаю, что здесь происходит какая-то гонка, и если пройти немного больше времени, он (udev?) придет в правильное состояние, но я не уверен, где именно. К сожалению, это вызывает проблемы для некоторых наших автоматизированных сборок серверов, поскольку серверы запускаются после (после установки) первой загрузки и пытаются запуститьeth1когда настоящее имя интерфейсаp3p2.

Я копался в модулях dracut, чтобы попытаться выяснить, в чем может заключаться проблема, но пока не смог определить ее окончательно, поэтому ищу предложения.

Кроме того, такое поведение происходит не всегда. Один и тот же сервер, загружающий один и тот же образ, иногда работает нормально, а иногда имеет смешанное поведение при именовании. Это также говорит мне о том, что это своего рода гонка: иногда гонка выигрывается, а иногда проигрывается.