[make-initrd] Possible missing firmware

[Leonid Krivoshein]

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, когда модуль уже неудачно загрузился на первой стадии.

>> О проблемах разъезда путей в ядре и соответствующей firmware мы всегда
>> узнаём постфактум по соответствующим багам,
> Что ты имеешь в виду под разъездом путей ?
>
> /lib/firmware/nvidia/470.256.02/gsp.bin
> /lib/firmware/nvidia/570.169/gsp_ga10x.bin
> /lib/firmware/nvidia/570.169/gsp_tu10x.bin
>
> Ты про вот такие пути, где есть версия ? Это единственный пример с
> проблемными путями, который я смог придумать.

Приведу в ретроспективе несколько примеров, в реальности их можно найти 
в нашей багзиле намного больше, у них разные корни, а сколько ещё будет...

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. Большинство точно про это, другие с некоторой 
вероятностью не исключают и такой разъезд.

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

Поэтому вариант с фильтром и только с "-v" для начала всех бы устроил. В 
основной вывод могла бы попадать лишь одна строчка со статистикой после 
отбрасывания отфильтрованного. Like this:

W: Possible missing firmware counters: 481 file(s), 8 module(s).


> Вот варианты решения проблемы в порядке трудозатратности.
>
> 1. Добавить в depinfo режим отображения отсутствующих firmware и
> использовать эту утилиту для проверки при сборки пакетов с
> модулями/firmware. Так как именно при сборке пакета ломается загрузка.

Загрузка ломается (или это иначе выражается) после активации новой пары 
ядро-initrd. Но да, сборка пакета -- ещё более ранняя стадия, нежели 
сборка initrd. Вот только при сборке initrd без этой утилиты не 
обойтись, поскольку создаётся усечённый набор, а не всё, что попадает в 
stage2 rootfs.


> 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. 
Остальное тебе видней. Я лишь заметил, что в update-initramfs это 
появилось. И ведь тоже не на пустом месте. Можно же посмотреть, как у 
других решено.


-- 
WBR, Leonid Krivoshein.