[make-initrd] Possible missing firmware

Sun Jul 6 18:36:47 MSK 2025

On 7/6/25 02:57, Alexey Gladkov wrote:
> On Sun, Jul 06, 2025 at 01:40:19AM +0300, Leonid Krivoshein wrote:
>> On 7/5/25 18:00, Alexey Gladkov wrote:
>>> On Sat, Jul 05, 2025 at 04:04:05PM +0300, Leonid Krivoshein wrote:
>>>>> Прошу, потому что из тех сообщений об ошибках я себе нафантазировал одно,
>>>>> а ты и Антон думаете скорее всего про другое.
>>>> Пакеты с firmware и пакеты с ядрами сопровождаются разными людьми, они
>>>> обновляются не синхронно, не согласованно.
>>> Ну то есть проблема всё-таки организационная. Из-за несогласованности
>>> мантейнеров пакетов страдают пользователи.
>> Да, потому что де-факто мы можем даже обновлять ядро независимо от
>> юзерспейса. Но не только организационная, потому что есть много причин
>> считать её ещё и технической. Хотя бы потому, что между ядром и пакетами
>> firmware фактически не обозначено жёстких файловых зависимостей. Даже
>> неведомые нам ошибки в ядре могли бы ловиться на более ранней стадии, а
>> не когда мы уже пытаемся использовать нерабочую пару ядро-initrd.
>> Поскольку в initramfs создаётся усечённый набор модулей и прошивок, он
>> больше подходит для решения данной задачи, некоторые проблемы порой
>> возникают из-за усечения набора, их может быть поздно исправлять в
>> stage2 rootfs, когда модуль уже неудачно загрузился на первой стадии.
> Признаться я не понимаю твою терминологию: stage1, stage2, ...

Первая стадия загрузки из initramfs, вторая стадия уже в стационарный 
rootfs после switch_root.

> Отсутствие зависимостей между модулями и firmware это просто недоработка
> вашей системы сборки т.к. зависимость на firmware в модуле это фактическая
> зависимость из модуля на файловую систему. Ядро даже имеет возможность
> загрузить firmware без udev и хэлперов т.е. напрямую с fs.

Всё верно.

>> Приведу в ретроспективе несколько примеров, в реальности их можно найти
>> в нашей багзиле намного больше, у них разные корни, а сколько ещё будет...
>>
>> https://bugzilla.altlinux.org/40079
>> https://bugzilla.altlinux.org/48803
>> https://bugzilla.altlinux.org/46348
>> https://bugzilla.altlinux.org/40065
>> https://bugzilla.altlinux.org/50471
>> https://bugzilla.altlinux.org/54261
>>
>> Нельзя утверждать на 100%, что все эти примеры про разъезд путей или
>> ядра с firmware. Большинство точно про это, другие с некоторой
>> вероятностью не исключают и такой разъезд.
> В большинстве упоминается, что помогло обновление linux-firmware. Но к
> сожалению я не увидел, что проблема именно в нехватке файлов firmware, а
> не в багах в самих firmware.

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

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

Ещё раз: это не для пользователей, им достаточно строчки со статистикой, 
остальное только с "-v". Можно даже сделать это частью make-initrd 
bug-report.

>>> Пользователю не ясно какие firmware необходимы, а какие нет. Список в
>>> десяток или сотни строк про отсутствующие чего-то-там никак пониманию не
>>> помогут. Непонятно, что делать пользователю, если он такое видит. Если это
>>> ошибка, то это должно быть ошибкой.
>>>
>>> Я уже не говорю, про обновления через gui всякие, где выхлопа от генерации
>>> initrd вообще не видно. Например на моей системе это вообще происходит в
>>> бэкграунде, не смотря что обновление не через gui происходит.
>> Поэтому вариант с фильтром и только с "-v" для начала всех бы устроил. В
>> основной вывод могла бы попадать лишь одна строчка со статистикой после
>> отбрасывания отфильтрованного. Like this:
>>
>> W: Possible missing firmware counters: 481 file(s), 8 module(s).
> Кто будет читать эти сообщения и когда ? Даже мне не понятно, что делать,
> если я увижу такую строчку.

make-initrd выводит много непонятных для большинства пользователей 
сообщений, но это не значит, что их вообще никто не читает. Если ты 
заметишь, что было 481, а стало 483, ты наверняка догадаешься, что в 
используемых модулях появились зависимости на две другие firmware, 
которых в твоём наборе нет.

> Что предлагаешь делать, в случае появления такого сообщения у
> пользователя ?

Если возникнет вопрос, можно дать ссылку на ВиКи, где описать ситуацию.

> Собственно, ссылка [1] из начала треда показывает, что эти
> сообщения ничем не помогают пользователю.
>
> [1] https://askubuntu.com/questions/1478862/after-a-fresh-install-of-kubuntu-error-shows-during-boot-amdgpu-secure-displa

Вообще-то для Linux админа здесь будет уместен самый стандартный 
алгоритм. Нет такого пути (провайдса) в дистрибутиве -- почему? Баг на 
firmware-linux. Есть такой путь -- какому пакету принадлежит, почему я 
его не установил?

> Кто и как будет поддерживать и обновлять эти фильтры ? Я этого делать не
> буду просто потому что релизы make-initrd выходят реже kernel и firmware.

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

>>> Вот варианты решения проблемы в порядке трудозатратности.
>>>
>>> 1. Добавить в depinfo режим отображения отсутствующих firmware и
>>> использовать эту утилиту для проверки при сборки пакетов с
>>> модулями/firmware. Так как именно при сборке пакета ломается загрузка.
>> Загрузка ломается (или это иначе выражается) после активации новой пары
>> ядро-initrd. Но да, сборка пакета -- ещё более ранняя стадия, нежели
>> сборка initrd. Вот только при сборке initrd без этой утилиты не
>> обойтись, поскольку создаётся усечённый набор, а не всё, что попадает в
>> stage2 rootfs.
> Ты уже не раз повторил про усечённый набор, хотя это очевидно неправда.
> В initrd пакуется _полный_ набор, который доступен на момент создания
> initrd.

Не совсем так. Всё зависит от установленных пакетов с firmware и их 
содержимого.

> Добавь зависимости в пакеты и всё попадёт в образ. Второй вариант, ставь
> всегда все firmware.

Да, всё верно.

>>> module /lib/modules/6.15.4-gentoo-dist/kernel/drivers/net/wireless/realtek/rtlwifi/rtlwifi.ko
>>>      \_ module /lib/modules/6.15.4-gentoo-dist/kernel/net/wireless/cfg80211.ko
>>>         \_ missing-firmware regulatory.db
>>>         \_ missing-firmware regulatory.db.p7s
>>>         \_ module /lib/modules/6.15.4-gentoo-dist/kernel/net/rfkill/rfkill.ko
>>>      \_ module /lib/modules/6.15.4-gentoo-dist/kernel/net/mac80211/mac80211.ko
>>>         \_ module /lib/modules/6.15.4-gentoo-dist/kernel/lib/crypto/libarc4.ko
>>>
>>> 2. Поскольку не существует хорошего способа определить необходимые
>>> firmware, то можно сделать режим, в котором будут требоваться _все_
>>> firmware для пакуемых модулей.
>>>
>>> 3. Можно сделать фичу по определению firmware требовавшихся для загрузки
>>> текущего ядра и пробовать использовать эту информацию. В этом случае можно
>>> будет по аналогии с MODULES_ADD добавить контроль за необходимыми
>>> firmware.
>>> Из минусов, что это всё ещё хак по определению требуемых firmware и всё
>>> равно нужно будет решать задачу с путями.
>> Пункт 3 уязвим к односторонним изменениям в апстриме ядра или firmware.
> Но ты ничего не сказал, про пункт 2.

Сказал, что тебе видней.

> Из услышанного я всё больше склоняюсь
> к нему. В этом случае пользователь не сможет сгенерировать потенциально
> ошибочный initrd из-за усеченного набора, а дальше он придёт к вам с
> репортом.
>
> Разумеется всё это не спасёт от ошибок в самих firmware и возможных
> проблем с разными сочетаниями ядро-firmware (слишком старое ядро и слишком
> новый linux-firmware, etc.).
>
>> Остальное тебе видней. Я лишь заметил, что в update-initramfs это
>> появилось. И ведь тоже не на пустом месте. Можно же посмотреть, как у
>> других решено.
> У них реализовано настолько не очевидное решение, что я даже не понимаю,
> это решение чего. По поводу сообщений я задал вопросы выше.

Вот и эти товарищи туда же! :-)
https://bugzilla.redhat.com/show_bug.cgi?id=700633

-- 
WBR, Leonid Krivoshein.