[make-initrd] Possible missing firmware

[Alexey Gladkov]

On Sat, Jul 05, 2025 at 04:04:05PM +0300, Leonid Krivoshein wrote:
> > Прошу, потому что из тех сообщений об ошибках я себе нафантазировал одно,
> > а ты и Антон думаете скорее всего про другое.
> 
> Пакеты с firmware и пакеты с ядрами сопровождаются разными людьми, они 
> обновляются не синхронно, не согласованно.

Ну то есть проблема всё-таки организационная. Из-за несогласованности
мантейнеров пакетов страдают пользователи.

> О проблемах разъезда путей в ядре и соответствующей 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

Ты про вот такие пути, где есть версия ? Это единственный пример с
проблемными путями, который я смог придумать.

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

Я считаю, что никто из пользователей не будет смотреть на эти
предупреждения об отсутствующих firmware.

Пользователю не ясно какие firmware необходимы, а какие нет. Список в
десяток или сотни строк про отсутствующие чего-то-там никак пониманию не
помогут. Непонятно, что делать пользователю, если он такое видит. Если это
ошибка, то это должно быть ошибкой.

Я уже не говорю, про обновления через gui всякие, где выхлопа от генерации
initrd вообще не видно. Например на моей системе это вообще происходит в
бэкграунде, не смотря что обновление не через gui происходит.

Вот варианты решения проблемы в порядке трудозатратности.

1. Добавить в depinfo режим отображения отсутствующих 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 и всё
равно нужно будет решать задачу с путями.

-- 
Rgrds, legion