[sisyphus] Работа ядра 2.6.32-ovz-el на текущем Sisyphus

[Nikolay A. Fetisov]

Здравствуйте!

По результатам обновления нескольких машин с t7 до Sisyphus,
возник один вопрос - а как предполагается сейчас работа
на реальном оборудовании систем на ядрах kernel-image-ovz-el ?


Сейчас в Sisyphus есть ядро 2.6.32-ovz-el-alt133. В нем есть 
некоторое число модулей, которые требуют BLOB'ы с firmware:
# find /lib/firmware/2.6.32-ovz-el-alt133/ -type f | wc -l
193

Начиная с udev-217, который в Sisyphus с 10.11.2014, из systemd 
убрана поддержка user-space firmware loader - т.к. ядра 3.3.7 
и выше загружать firmware умеют сами и сторонняя поддержка для 
этого им не нужна.

Сейчас в Sisyphus udev-219, запросы от ядра на загрузку firmware 
он не обрабатывает. Поддержки kernel-space firmware loader в
ядрах 2.6.32-ovz-el нет. Т.е., модули из kernel-image-ovz-el,
запрашивающие загрузку firmware, на текущем Sisyphus ничего не
получают.



Из трёх разным машин, которые были обновлены с t7 до Sisyphus,
две осталось без сети (модули bnx2 и e100), на третьей в модуль r8169
не загрузился "firmware patch" rtl_nic/rtl8168g-1.fw, но сетевой
интерфейс как-то работал.

Пока из идей (помимо отката до {systemd-utils,udev,udev-hwdb,
udev-rules}-216) - возврат к загрузке firmware внешним скриптом. 
Т.е., создание правила для udev вида

SUBSYSTEM=="firmware",ACTION=="add",RUN+="/usr/local/sbin/firmware.sh"

и вытаскивание firmware.sh из http://git.altlinux.org/people/shaba/pack
ages/udev.git?p=udev.git;a=blob_plain;f=extras/firmware/firmware.sh;hb=
66a4fc29f9c63743c36229962b10c95b8954d349

Из плюсов, наличие такого правила:
- не мешает работе с udev-216 - там эти запросы обрабатываются самим
udev и до внешних правил не доходят, 
- не мешает работе с ядрами 3.XX - там запросов на загрузку firmware в
udev вообще не идёт,
- и оно более-менее работает на udev>=217.
Из минусов - с udev-219 оно работает именно более-менее.

Как минимум для сервера с двумя картами Broadcom BCM5709 (bnx2) на 
этапе запуска udev поднимается только одна. Такое впечатление, что 
udev-219 загружает модули параллельно, и в ядре при этом возникает 
какой-то race condition - /sys$DEVPATH/loading создаётся только для 
одной сетевой карты, в случайном порядке. Это было решено через запрет 
на загрузку модуля udev'ом внесением его в blacklist, благо etcnet сам 
потом загружает модуль при поднятии интерфейса - но как универсальный 
вариант внешний скрипт загрузки firmware, по-видимому, сейчас тоже не 
годится.


Т.е., суммируя: появление на openvz.org репозитория с 
branch-rh7-3.10.0-123.1.2-ovz определённые надежды на будущее даёт, 
но что делать сейчас?



-- 
С уважением,
Николай Фетисов