Re: [make-initrd] Possible missing firmware

[Alexey Gladkov <legion@kernel.org>]

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, ...

Отсутствие зависимостей между модулями и 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.

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

Кто будет читать эти сообщения и когда ? Даже мне не понятно, что делать,
если я увижу такую строчку.

Что предлагаешь делать, в случае появления такого сообщения у
пользователя ? Собственно, ссылка [1] из начала треда показывает, что эти
сообщения ничем не помогают пользователю.

[1] https://askubuntu.com/questions/1478862/after-a-fresh-install-of-kubuntu-error-shows-during-boot-amdgpu-secure-displa

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

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

Ты уже не раз повторил про усечённый набор, хотя это очевидно неправда.
В initrd пакуется _полный_ набор, который доступен на момент создания
initrd.

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

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

-- 
Rgrds, legion