Created attachment 7022 [details]
Fallback to use $BRCTL if brctl config file exists

Исходя из того, что проблема затрагивает только конкретное старое ядро:

- восстанавливаются переменные BRCTL/DEFAULT_BRCTL, где они были убраны 
  (а убраны они были не везде),
- при нахождении в каталоге конфигурации интерфейса файла brctl идёт переключение
  на использование brctl,
- при отсутствии brctl - идёт работа через 'ip link ... type bridge';
- добавляется игнорирование ошибок в вызовах ip link ... type bridge; 
  shutdown-bri при этом интерфейсы из bridge'а не удалит, но работу продолжит, 
  и они в любом случае уйдут при вызове destroy-bri.

Вставлю сюда пример использования:

# cat /etc/net/ifaces/breth0/brctl
stp AUTO on

# cat /etc/net/ifaces/breth0/options
BOOTPROTO=static
TYPE=bri
HOST=enp4s0

Потом на этот бридж навешивается OpenVZ (из конфига):
NETIF="ifname=breth0,bridge=breth0,mac=00:18:51:6C:44:0E,host_ifname=veth210.0,host_mac=00:18:51:A7:5A:F2"

сеть настраивается так:
# cat /etc/vz/vznet.conf
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"

Ну и там вызывается brctl:
# grep brctl /usr/sbin/vznetaddbr
    brctl addif "$bridge" "$host_ifname"

И незавершённое обсуждение в devel:
https://lists.altlinux.org/pipermail/devel/2018-November/205982.html

Для меня эта задача актуальна тем, что обновлением etcnet в «стабильном» p8 сломали настройку сети.

etcnet-0.9.18-alt2 -> sisyphus:

Mon Mar 11 2019 Andrey Bychkov <mrdrew@altlinux> 0.9.18-alt2
- iface status check for ifdown added (Closes: #22658)
- loading of kernel module 8021q disabled in VE (patch by Denis Yagofarov) (Closes: #13607)
- dhcpd service stop fixed (Closes: #19582)
- fixed unable to manage bridge ifaces on 2.6.32 OpenVZ kernels (patch by Nikolay A. Fetisov) (Closes: #33296)

В etcnet-0.9.18-alt3 код идентичен etcnet-0.9.18-alt1.

Бага висит на сизифе, а ядра 2.6.32 в сизифе нет, так почему бы ее не закрыть?

Закрыта с неправильным диагнозом. 
Надо закрывать как WONTFIX, т.к. исправлять это не будем в связи с концом ovz в Sisyphus.

...или перевесить на p8.

После обновления etcnet в p8 к создаваемым bridge-интерфейсам перестала добавляться физическая сетевая карта, указанная в параметра HOST файла options.

etcnet-0.9.16-alt1.M80P.2

помогает откат на 0.9.11-alt2.M80P.1

Я хотел бы обратить внимание, что подобная поломка в стабильном бранче p8 недопустима: при штатном обновлении системы ломается сеть и сервер становится недоступным.

На каком ядре ?

(В ответ на комментарий №8)
> После обновления etcnet в p8 к создаваемым bridge-интерфейсам перестала
> добавляться физическая сетевая карта, указанная в параметра HOST файла options.

Там ещё, как минимум, сломано создание bonding-интерфейсов - по той же причине,
на 2.6.32 у 'ip link' их настроить не получается.

Хотя всё это уже малоактуально, EOL OVZ6 был в ноябре 2019 г.

(В ответ на комментарий №9)
> На каком ядре ?
2.6.32-ovz-el-alt162

(В ответ на комментарий №10)
> (В ответ на комментарий №8)
> > После обновления etcnet в p8 к создаваемым bridge-интерфейсам перестала
> > добавляться физическая сетевая карта, указанная в параметра HOST файла options.
> 
> Там ещё, как минимум, сломано создание bonding-интерфейсов - по той же причине,
> на 2.6.32 у 'ip link' их настроить не получается.
> 
> Хотя всё это уже малоактуально, EOL OVZ6 был в ноябре 2019 г.
Это хорошая идея — ломать в  системе компоненты, по которым закончилась поддержка.
Но мне кажутся странными изменения в стабильном бранче, ломающие совместимость.

на этом ядре официально не выпускалось продуктов и оно не входит в наши тестовые сценарии.

Использование такого ядра - это риски тех, кто сделал такой выбор.