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, чтобы попытаться выяснить, в чем может заключаться проблема, но пока не смог окончательно определить ее, поэтому ищу предложения.

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