[make-initrd] Possible missing firmware

[Alexey Gladkov]

On Sun, Jul 06, 2025 at 06:36:47PM +0300, Leonid Krivoshein wrote:
> > Признаться я не понимаю твою терминологию: stage1, stage2, ...
> 
> Первая стадия загрузки из initramfs, вторая стадия уже в стационарный 
> rootfs после switch_root.

Ясно. спасибо.

> > В большинстве упоминается, что помогло обновление linux-firmware. Но к
> > сожалению я не увидел, что проблема именно в нехватке файлов firmware, а
> > не в багах в самих firmware.
> 
> Я просто не стал лазить по багзиле более детально. Мне постоянно 
> приходится смотреть логи со всевозможного железа. С amdgpu такое 
> эпизодически вылазит. Наш набор упакованных файлов видимо какой-то 
> другой, не полный. Партнёры присылают "правильный" набор, но с 
> непонятными лицензиями и из неизвестного источника, мы такое даже не 
> можем опакетить. И нет нормального инструмента, чтобы чётко 
> диагностировать, что у нас не так с firmware. И тот же инструмент помог 
> бы быстро и точно диагностировать баг с BT в ядре, там как раз разъезд 
> путей.

Я наверно неправильно выразился. Я не просил доказательств. Если бы ты
просто сказал, то это очень массовое явление, то я бы тебе поверил.

Раз нет инструмента, то давай конечно что-нибудь придумаем.

Тем более, что пока я копался вчера с firmware, то открыл портал в ад.
Оказывается, в поле модуля firmware не имена, а паттерны, хотя описание
макроса MODULE_FIRMWARE ни о чём таком не говорит. Это делает выяснение
списка firmware мягко говоря сложнее для обычного скрипта.

> >>>> когда новое initrd уже сгенерировано и не получилось загрузиться или
> >>>> получилось, но эта новая связка создала проблемы при дальнейшей работе.
> >>>> Мы могли бы выявлять потенциальные проблемы уже на этапе создания
> >>>> initrd. А без реализации предлагаемого мы не сможем даже примерно
> >>>> оценить масштаб этой проблемы для будущих обновлений. Поэтому я считаю,
> >>>> что такой инструмент был бы полезным. Хотя бы подсчитывать число
> >>>> предупреждений без вывода их в stderr, если не указан "-v".
> >>> Я считаю, что никто из пользователей не будет смотреть на эти
> >>> предупреждения об отсутствующих firmware.
> 
> Ещё раз: это не для пользователей, им достаточно строчки со статистикой, 
> остальное только с "-v". Можно даже сделать это частью make-initrd 
> bug-report.

Ок. Убедил.

Но вот с bug-report мне не очень понятно. Баг-репорт это просто инфа про
систему, а не про initramfs. Что ты предлагаешь туда класть в контексте
firmware ? Список всех firmware, которые на момент bug-report были на
машине ?

> > Кто и как будет поддерживать и обновлять эти фильтры ? Я этого делать не
> > буду просто потому что релизы make-initrd выходят реже kernel и firmware.
> 
> Хороший и непростой вопрос, но он следующий. Сейчас даже базы нет, чтобы 
> использовать это для диагностики. Пока фильтров нет, пока они не 
> заполнены, понятно, что с "-v" сообщений будет больше. Как только 
> кто-то, например я, начнёт пользоваться и анализировать данный вывод, 
> начнут появляться фильтры. Продвинутый админ тогда сможет настроить 
> фильтр под свою систему за ненадобностью вообще всех прошивок. Конечно, 
> если он использует "-v". Без "-v" эти фильтры будут влиять только на 
> цифры в статистике.

Давай пока обойдёмся без фильтров и просто пусть будут сообщения. Плюс
depinfo будет уметь показывать отсутствующие firmware.

> >>> 3. Можно сделать фичу по определению firmware требовавшихся для загрузки
> >>> текущего ядра и пробовать использовать эту информацию. В этом случае можно
> >>> будет по аналогии с MODULES_ADD добавить контроль за необходимыми
> >>> firmware.
> >>> Из минусов, что это всё ещё хак по определению требуемых firmware и всё
> >>> равно нужно будет решать задачу с путями.
> >> Пункт 3 уязвим к односторонним изменениям в апстриме ядра или firmware.
> > Но ты ничего не сказал, про пункт 2.
> 
> Сказал, что тебе видней.

Раз так, то ограничусь сообщениями. Эвристики для firmware это отдельное
дело и его нужно делать только есть запрос.

-- 
Rgrds, legion