Сетевые интерфейсы после обновления.

После последнего обновления появилась в лога такая фигня:

Jan  6 12:20:30 calculate syslog-ng[4294]: syslog-ng starting up; version='3.7.3'
Jan  6 12:20:31 calculate kernel: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Jan  6 12:20:31 calculate kernel: bond122: renamed from bond0
Jan  6 12:20:31 calculate kernel: udevd[3420]: renamed network interface bond0 to bond122
Jan  6 12:20:31 calculate kernel: bonding: bond0 is being created...
Jan  6 12:20:31 calculate kernel: bond121: renamed from bond0
Jan  6 12:20:31 calculate kernel: udevd[3420]: renamed network interface bond0 to bond121
Jan  6 12:20:31 calculate /etc/init.d/net.bond0[4802]: ERROR: interface bond0 does not exist
Jan  6 12:20:31 calculate /etc/init.d/net.bond0[4803]: Ensure that you have loaded the correct kernel module for your hardware
Jan  6 12:20:32 calculate /etc/init.d/net.bond0[3484]: ERROR: net.bond0 failed to start
...

Соответственно сети нет и сервисов, зависящих от сети тоже нет.
Зачем udev переименовывает интерфейсы и что теперь с этим делать?
Драйвер bonding.ko.xz лежит там, где ему и положено.
Вот содержание /etc/conf.d/net

modules="bonding"
interfaces="bond0"

config_eth0="null"
config_eth1="null"
config_eth2="null"
config_eth3="null"

config_bond0="192.168.1.2 netmask 255.255.255.0 broadcast 192.168.1.255"
slaves_bond0="eth0 eth1 eth2 eth3"
routes_bond0="default gw 192.168.1.254"
dns_servers="192.168.1.100"
mode_bond0="balance-alb"
miimon_bond0="100"

ifplugd="--no-beep"

Без бондинга карты работают. Бондинг теперь не поднимается. Хотя до обновления всё работало.
Причём, на двух серверах бондинг не работает, а на третьем всё хорошо. На всех трёх серверах обновления идентичные.
Кто сталкивался с этой проблемой? Подскажите куда копать.

Попробуйте удалить '/etc/udev/rules.d/70-persistent-net.rules' и пересоздать initramfs выполнив 'dracut -fH'. Причину будем искать сразу после праздников.

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

Есть ещё одна проблема небольшая, связанная с ядром.
При инициализации ядра на мониторе появляются ошибки связанные с ACPI
и предупреждения IPv6. Это всё отражено в логах dmesg
Вот:

[    0.364733] ACPI Error: [\_SB_.PRAD] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364)
[    0.364733] ACPI Error: Method parse/execution failed \_GPE._L24, AE_NOT_FOUND (20170728/psparse-550)
[    0.364733] ACPI Exception: AE_NOT_FOUND, while evaluating GPE method [_L24] (20170728/evgpe-646)
...
[    2.188006] IPv6: Attempt to unregister permanent protocol 6
...
[    2.220004] IPv6: Attempt to unregister permanent protocol 136
[    2.236007] IPv6: Attempt to unregister permanent protocol 17
...
#Дальше повторяются несколько раз строки
[    2.931986] IPv6: Attempt to unregister permanent protocol 6
[    2.963980] IPv6: Attempt to unregister permanent protocol 136
[    2.979980] IPv6: Attempt to unregister permanent protocol 17

Ядро calculate-sources-4.14.12 Своей конфигурации нет. Всё по дефолту.
На предыдущих ядрах были такие же сообщения.

Не знаю что это означает, но вроде не ошибка.

Ошибка, но не ядра. Вот, нашёл объяснение RedHat на аналогичный случай https://access.redhat.com/articles/65378

Resolution

These messages indicate that there are BIOS errors related to power management control and
PCI root bridge enumeration data due to an improper ACPI table. While these should not 
cause problems with regular system operation, they could cause issues with power management 
functions. Please contact your system vendor and ask for an updated BIOS.

Перевод
Эти сообщения указывают на наличие ошибок BIOS, связанных с управлением питанием и данными 
переустройства PCI-корневого узла из-за неправильной таблицы ACPI. Хотя они не должны 
вызывать проблем при регулярной работе системы, они могут вызвать проблемы с функциями 
управления питанием. Обратитесь к поставщику системы и попросите обновленный BIOS.

Учитывая, что версия BIOS стоит последняя, а к Supermicro обращаться бесполезно… придётся забить на это, так как не критично.

Bonding - перестал работать. Но, кроме бондинга, перестало работать всё, имеющее более одного сетевого интерфейса. В случае 2х физических интерфейсов - из /etc/init.d исчезла ссылка на eth1, если же были виртуальные интерфейсы (напр. macvtap), не запустились виртуальные машины. Предложенное решение сработало.