Bug 36863

Summary: Просьба обновить драйвере сетевых карт Intel до 5.2.0
Product: Sisyphus Reporter: Alexei Takaseev <taf>
Component: kernel-image-std-defAssignee: Vitaly Chikunov <vt>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: critical    
Priority: P3 CC: asy, kernelbot, placeholder, vt
Version: unstable   
Hardware: all   
OS: Linux   

Description Alexei Takaseev 2019-06-05 06:08:17 MSK
Ранее, в ветке ядра 4.9 собирались драйвера Intel версии 5.2.1, в версиях 4.19 собираются старые драйвера 5.1.0

Хотелось бы чтобы и далее в ядрах std-def драйвера были 5.2.1 и свежее.
Comment 1 Anton Farygin 2019-06-05 07:48:33 MSK
Если уж обновлять, то пожалуй весь стек интеловских драйверов:
https://sourceforge.net/projects/e1000/files/

И да, можно собрать внешними модулями для Sisyphus, но лучше всё-таки патчами на mainline.
Comment 2 Anton V. Boyarshinov 2019-06-05 10:20:34 MSK
> И да, можно собрать внешними модулями для Sisyphus, но лучше всё-таки патчами
> на mainline.
Не лучше. Надо собрать именно отдельными модулями. Отдельные модули меньше разваливаются при обновлении ядра внутри ветки и у них понятный workflow переезда между ветками.

Если что-то живёт вне ядра и у него отдельный релизный цикл, не привязанный к ядру -- пусть будет отдельными модулями.
Comment 3 Anton Farygin 2019-06-05 10:30:09 MSK
Отдельные модули нельзя делать для обратной совместимости - потерять доступ к серверу после обновления ядра по причине того, что ментейнер вынес модули в отдельные пакеты - недопустимо.

Как вариант - подумать на предмет зависимостей, но помоему это для ядерных модулей не работает из-за allow-duplicated.
Comment 4 Anton V. Boyarshinov 2019-06-05 12:17:00 MSK
(В ответ на комментарий №3)
> Отдельные модули нельзя делать для обратной совместимости - потерять доступ к
> серверу после обновления ядра по причине того, что ментейнер вынес модули в
> отдельные пакеты - недопустимо.

Переименовать в этих отдельных пакетах модули и положить в пакет с ними blacklist файл. Тогда их можно не выключать в ядре и при отсутствии внешнего пакета будет работать ядерная реализация.

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

> 
> Как вариант - подумать на предмет зависимостей, но помоему это для ядерных
> модулей не работает из-за allow-duplicated.
Comment 5 Anton Farygin 2019-06-05 12:28:28 MSK
(В ответ на комментарий №4)
> (В ответ на комментарий №3)
> > Отдельные модули нельзя делать для обратной совместимости - потерять доступ к
> > серверу после обновления ядра по причине того, что ментейнер вынес модули в
> > отдельные пакеты - недопустимо.
> 
> Переименовать в этих отдельных пакетах модули и положить в пакет с ними
> blacklist файл. Тогда их можно не выключать в ядре и при отсутствии внешнего
> пакета будет работать ядерная реализация.

У меня, например, скрипты заточены на имена модулей. Это ещё хуже, чем в ядре патчем обновлять.

> 
> Так или иначе, эксперимент с включением патчем модулей, имеющих отдельный
> релизный цикл я считаю провалившимся и повторять его не собираюсь.

А мне кажется, это было очень удачно. У меня ушло около 15 минут на создание патча, это же совсем просто.

> 
> > 
> > Как вариант - подумать на предмет зависимостей, но помоему это для ядерных
> > модулей не работает из-за allow-duplicated.
Comment 6 Alexei Takaseev 2019-06-05 12:33:48 MSK
А насколько будет удачным вынесение внешних драйверов сетевух при очередной смене версии ядра (типа 4.19 -> 5.0)? А до этого момента держать в виде патча.
Comment 7 Anton V. Boyarshinov 2019-06-05 12:43:39 MSK
> У меня, например, скрипты заточены на имена модулей. Это ещё хуже, чем в ядре
> патчем обновлять.
Если ты разложил себе грабли, написав скрипты, заточенные на имена модулей -- это твои грабли.
 
> А мне кажется, это было очень удачно. У меня ушло около 15 минут на создание
> патча, это же совсем просто.
А мне так не кажется. Периодически при выходе нового релиза приходится решать конфликты в этих модулях.
И выход нового ядра, на которое прежний патч, разумеется, не ляжет это не какое-то редкостное событие, а бывает раз в полтора месяца.

У нас есть хороший, удобный и работающий механизм сборки внешних модулей, их собирается множество. И только ixgb надо обязательно тащить в ядро.
Comment 8 Anton Farygin 2019-06-05 14:05:42 MSK
(В ответ на комментарий №7)
> > У меня, например, скрипты заточены на имена модулей. Это ещё хуже, чем в ядре
> > патчем обновлять.
> Если ты разложил себе грабли, написав скрипты, заточенные на имена модулей --
> это твои грабли.

Да не я один такой. Проверка или загрузка модуля по имени это зачастую стандартная схема деплоя. 

Убирая одну проблему ты создаёшь кучу новых, главная из которых - несовместимость с апстримом.


> 
> > А мне кажется, это было очень удачно. У меня ушло около 15 минут на создание
> > патча, это же совсем просто.
> А мне так не кажется. Периодически при выходе нового релиза приходится решать
> конфликты в этих модулях.
> И выход нового ядра, на которое прежний патч, разумеется, не ляжет это не
> какое-то редкостное событие, а бывает раз в полтора месяца.

Ну и что ? Не вижу проблем раз в полтора месяца пройтись по драйверам и смержить.

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

> 
> У нас есть хороший, удобный и работающий механизм сборки внешних модулей, их
> собирается множество. И только ixgb надо обязательно тащить в ядро.

Да если бы изначально собирали ixgbe отдельно от ядра, тотак бы и было. e1000, кстати, одно время был вне ядра, потом зачем-то втащили внутрь (что делается заметно легче).
Comment 9 Sergey Y. Afonin 2019-06-06 15:18:02 MSK
(In reply to comment #6)

> А насколько будет удачным вынесение внешних драйверов сетевух при очередной
> смене версии ядра (типа 4.19 -> 5.0)? А до этого момента держать в виде патча.

На самом деле если момент выбирать, то это прямо сейчас, пока про p9 официально не объявлено. Переделывать в рамках бранча плохо, а вот в момент перехода с бранча на бранч - это ещё более-менее. И, всё же, лучше для всех ядер, так как бывет надо скакать бежду std-def и un-def.
Comment 10 Alexei Takaseev 2019-11-16 15:32:14 MSK
Отдельно собран модуль kernel-modules-ixgbe-std-def