[make-initrd] Possible missing firmware

[make-initrd] Possible missing firmware

[Leonid Krivoshein]

Всем привет!


Обратил внимание на такую интересную фичу в аналогичном инструменте:

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

|... update-initramfs: Generating /boot/initrd.img-6.4.6-060406-generic|
|W: Possible missing firmware /lib/firmware/amdgpu/ip_discovery.bin for 
module amdgpu W: Possible missing firmware 
/lib/firmware/amdgpu/vega10_cap.bin for module amdgpu W: Possible 
missing firmware /lib/firmware/amdgpu/sienna_cichlid_cap.bin for module 
amdgpu ... ||W: Possible missing firmware /lib/firmware/amdgpu/smu_13_0_10.bin for 
module amdgpu |


Есть ли что-то подобное в make-initrd? Если нет, стоит прикрутить по 
аналогии. А может даже сделать ключик, чтобы стало ошибкой, а не 
предупреждением. Что скажете?


-- 
WBR, Leonid Krivoshein.

Re: [make-initrd] Possible missing firmware

[Alexey Gladkov]

On Thu, Jul 03, 2025 at 02:37:23AM +0300, Leonid Krivoshein wrote:
> Всем привет!
> 
> 
> Обратил внимание на такую интересную фичу в аналогичном инструменте:
> 
> https://askubuntu.com/questions/1478862/after-a-fresh-install-of-kubuntu-error-shows-during-boot-amdgpu-secure-displa
> 
> |... update-initramfs: Generating /boot/initrd.img-6.4.6-060406-generic|
> |W: Possible missing firmware /lib/firmware/amdgpu/ip_discovery.bin for 
> module amdgpu W: Possible missing firmware 
> /lib/firmware/amdgpu/vega10_cap.bin for module amdgpu W: Possible 
> missing firmware /lib/firmware/amdgpu/sienna_cichlid_cap.bin for module 
> amdgpu ... ||W: Possible missing firmware /lib/firmware/amdgpu/smu_13_0_10.bin for 
> module amdgpu |
> 
> 
> Есть ли что-то подобное в make-initrd? Если нет, стоит прикрутить по 
> аналогии. А может даже сделать ключик, чтобы стало ошибкой, а не 
> предупреждением. Что скажете?

Если я правильно понял, хотя не уверен, ты предлагаешь показывать
предупреждение в случае если firmware не нашлось для модуля. Я лишь
предполагаю.

Если я правильно понял, то сейчас такой возможности нет и если firmware не
находится, то игнорируется. Это делается потому что не все firmware
необходимы.

-- 
Rgrds, legion

Re: [make-initrd] Possible missing firmware

[Anton Midyukov]

04.07.2025 13:42, Alexey Gladkov пишет:
> On Thu, Jul 03, 2025 at 02:37:23AM +0300, Leonid Krivoshein wrote:
>> Всем привет!
>>
>>
>> Обратил внимание на такую интересную фичу в аналогичном инструменте:
>>
>> https://askubuntu.com/questions/1478862/after-a-fresh-install-of-kubuntu-error-shows-during-boot-amdgpu-secure-displa
>>
>> |... update-initramfs: Generating /boot/initrd.img-6.4.6-060406-generic|
>> |W: Possible missing firmware /lib/firmware/amdgpu/ip_discovery.bin for 
>> module amdgpu W: Possible missing firmware 
>> /lib/firmware/amdgpu/vega10_cap.bin for module amdgpu W: Possible 
>> missing firmware /lib/firmware/amdgpu/sienna_cichlid_cap.bin for module 
>> amdgpu ... ||W: Possible missing firmware /lib/firmware/amdgpu/smu_13_0_10.bin for 
>> module amdgpu |
>>
>>
>> Есть ли что-то подобное в make-initrd? Если нет, стоит прикрутить по 
>> аналогии. А может даже сделать ключик, чтобы стало ошибкой, а не 
>> предупреждением. Что скажете?
> 
> Если я правильно понял, хотя не уверен, ты предлагаешь показывать
> предупреждение в случае если firmware не нашлось для модуля. Я лишь
> предполагаю.
> 
> Если я правильно понял, то сейчас такой возможности нет и если firmware не
> находится, то игнорируется. Это делается потому что не все firmware
> необходимы.
> 

При использовании опции -v тоже не показываются эти сообщения в make-initrd?

-- 
best regards, Anton Midyukov <antohami@altlinux.org>

Re: [make-initrd] Possible missing firmware

[Alexey Gladkov]

On Fri, Jul 04, 2025 at 01:43:45PM +0300, Anton Midyukov wrote:
> 04.07.2025 13:42, Alexey Gladkov пишет:
> > On Thu, Jul 03, 2025 at 02:37:23AM +0300, Leonid Krivoshein wrote:
> >> Всем привет!
> >>
> >>
> >> Обратил внимание на такую интересную фичу в аналогичном инструменте:
> >>
> >> https://askubuntu.com/questions/1478862/after-a-fresh-install-of-kubuntu-error-shows-during-boot-amdgpu-secure-displa
> >>
> >> |... update-initramfs: Generating /boot/initrd.img-6.4.6-060406-generic|
> >> |W: Possible missing firmware /lib/firmware/amdgpu/ip_discovery.bin for 
> >> module amdgpu W: Possible missing firmware 
> >> /lib/firmware/amdgpu/vega10_cap.bin for module amdgpu W: Possible 
> >> missing firmware /lib/firmware/amdgpu/sienna_cichlid_cap.bin for module 
> >> amdgpu ... ||W: Possible missing firmware /lib/firmware/amdgpu/smu_13_0_10.bin for 
> >> module amdgpu |
> >>
> >>
> >> Есть ли что-то подобное в make-initrd? Если нет, стоит прикрутить по 
> >> аналогии. А может даже сделать ключик, чтобы стало ошибкой, а не 
> >> предупреждением. Что скажете?
> > 
> > Если я правильно понял, хотя не уверен, ты предлагаешь показывать
> > предупреждение в случае если firmware не нашлось для модуля. Я лишь
> > предполагаю.
> > 
> > Если я правильно понял, то сейчас такой возможности нет и если firmware не
> > находится, то игнорируется. Это делается потому что не все firmware
> > необходимы.
> > 
> 
> При использовании опции -v тоже не показываются эти сообщения в make-initrd?

Даже с -v не показывает.

https://github.com/osboot/make-initrd/blob/master/utils/depinfo/kmod-depinfo.c#L325-L338

-- 
Rgrds, legion

Re: [make-initrd] Possible missing firmware

[Alexey Gladkov]

On Fri, Jul 04, 2025 at 01:38:10PM +0200, Alexey Gladkov wrote:
> > 
> > При использовании опции -v тоже не показываются эти сообщения в make-initrd?
> 
> Даже с -v не показывает.
> 
> https://github.com/osboot/make-initrd/blob/master/utils/depinfo/kmod-depinfo.c#L325-L338

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

diff --git a/utils/depinfo/kmod-depinfo.c b/utils/depinfo/kmod-depinfo.c
index 6a761af4..58ee2075 100644
--- a/utils/depinfo/kmod-depinfo.c
+++ b/utils/depinfo/kmod-depinfo.c
@@ -315,6 +315,7 @@ process_firmware(const char *firmware)
 {
        char firmware_buf[MAXPATHLEN];
        char *s, *str, *token, *saveptr = NULL;
+       int found = 0;
        s = str = strdup(firmware_dir);
 
        while ((token = strtok_r(str, ":", &saveptr)) != NULL) {
@@ -334,6 +335,7 @@ again:
                                if (opts & SHOW_PREFIX)
                                        printf("firmware ");
                                printf("%s\n", firmware_buf);
+                               found = 1;
                                break;
                        }
 
@@ -347,6 +349,9 @@ again:
                str = NULL;
        }
        free(s);
+
+       if (!found)
+               warnx("WARNING: firmware not found: %s", firmware);
 }
 
 static int
---

-- 
Rgrds, legion

Re: [make-initrd] Possible missing firmware

[Alexey Gladkov]

On Fri, Jul 04, 2025 at 03:20:02PM +0200, Alexey Gladkov wrote:
> On Fri, Jul 04, 2025 at 01:38:10PM +0200, Alexey Gladkov wrote:
> > > 
> > > При использовании опции -v тоже не показываются эти сообщения в make-initrd?
> > 
> > Даже с -v не показывает.
> > 
> > https://github.com/osboot/make-initrd/blob/master/utils/depinfo/kmod-depinfo.c#L325-L338
> 
> Можно сделать что-то типа такого. У меня при генерации таких сообщений не
> выводится, но непонятно насколько это будет спамить пользователей. 

Не. Такие сообщения, как минимум по умолчанию, выводить нельзя. Я даже не
уверен, что такое количество сообщений полезно с -v.

$ ./depinfo nouveau 2>&1 >/dev/null |grep -c 'depinfo: WARNING: firmware'
431

-- 
Rgrds, legion

Re: [make-initrd] Possible missing firmware

[Leonid Krivoshein]

Привет!


On 7/4/25 18:03, Alexey Gladkov wrote:
> On Fri, Jul 04, 2025 at 03:20:02PM +0200, Alexey Gladkov wrote:
>> On Fri, Jul 04, 2025 at 01:38:10PM +0200, Alexey Gladkov wrote:
>>>> При использовании опции -v тоже не показываются эти сообщения в make-initrd?
>>> Даже с -v не показывает.
>>>
>>> https://github.com/osboot/make-initrd/blob/master/utils/depinfo/kmod-depinfo.c#L325-L338
>> Можно сделать что-то типа такого. У меня при генерации таких сообщений не
>> выводится, но непонятно насколько это будет спамить пользователей.
> Не. Такие сообщения, как минимум по умолчанию, выводить нельзя. Я даже не
> уверен, что такое количество сообщений полезно с -v.
>
> $ ./depinfo nouveau 2>&1 >/dev/null |grep -c 'depinfo: WARNING: firmware'
> 431

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


-- 
WBR, Leonid Krivoshein.

Re: [make-initrd] Possible missing firmware

[Alexey Gladkov]

On Fri, Jul 04, 2025 at 06:23:52PM +0300, Leonid Krivoshein wrote:
> Привет!
> 
> 
> On 7/4/25 18:03, Alexey Gladkov wrote:
> > On Fri, Jul 04, 2025 at 03:20:02PM +0200, Alexey Gladkov wrote:
> >> On Fri, Jul 04, 2025 at 01:38:10PM +0200, Alexey Gladkov wrote:
> >>>> При использовании опции -v тоже не показываются эти сообщения в make-initrd?
> >>> Даже с -v не показывает.
> >>>
> >>> https://github.com/osboot/make-initrd/blob/master/utils/depinfo/kmod-depinfo.c#L325-L338
> >> Можно сделать что-то типа такого. У меня при генерации таких сообщений не
> >> выводится, но непонятно насколько это будет спамить пользователей.
> > Не. Такие сообщения, как минимум по умолчанию, выводить нельзя. Я даже не
> > уверен, что такое количество сообщений полезно с -v.
> >
> > $ ./depinfo nouveau 2>&1 >/dev/null |grep -c 'depinfo: WARNING: firmware'
> > 431
> 
> Дело в том, что в модуле есть ссылка на firmware. Если при загрузке 
> нужной не окажется, загрузки может не случиться. Почему здесь такое 
> число ссылок на отсутствующие файлы firmware -- отдельный хороший вопрос.

В моём случае у меня не установлены firmware для nvidia.

-- 
Rgrds, legion

Re: [make-initrd] Possible missing firmware

[Leonid Krivoshein]

On 7/4/25 21:23, Alexey Gladkov wrote:
> On Fri, Jul 04, 2025 at 06:23:52PM +0300, Leonid Krivoshein wrote:
>> Привет!
>>
>>
>> On 7/4/25 18:03, Alexey Gladkov wrote:
>>> On Fri, Jul 04, 2025 at 03:20:02PM +0200, Alexey Gladkov wrote:
>>>> On Fri, Jul 04, 2025 at 01:38:10PM +0200, Alexey Gladkov wrote:
>>>>>> При использовании опции -v тоже не показываются эти сообщения в make-initrd?
>>>>> Даже с -v не показывает.
>>>>>
>>>>> https://github.com/osboot/make-initrd/blob/master/utils/depinfo/kmod-depinfo.c#L325-L338
>>>> Можно сделать что-то типа такого. У меня при генерации таких сообщений не
>>>> выводится, но непонятно насколько это будет спамить пользователей.
>>> Не. Такие сообщения, как минимум по умолчанию, выводить нельзя. Я даже не
>>> уверен, что такое количество сообщений полезно с -v.
>>>
>>> $ ./depinfo nouveau 2>&1 >/dev/null |grep -c 'depinfo: WARNING: firmware'
>>> 431
>> Дело в том, что в модуле есть ссылка на firmware. Если при загрузке
>> нужной не окажется, загрузки может не случиться. Почему здесь такое
>> число ссылок на отсутствующие файлы firmware -- отдельный хороший вопрос.
> В моём случае у меня не установлены firmware для nvidia.

А если начать с самого мягкого варианта -- предупреждения с "-v" и с 
фильтрацией по спискам? Например, в 
"/etc/initrd.mk.d/{modules,firmware}/*.list" файлы со списками по тем 
модулям/фирмварям, по которым не нужно выводить предупреждения?

Во первых, эти списки можно будет потом опакетить. Во-вторых, это даст 
возможность изучить вопрос во времени без спама пользователей. 
Предпосылка: если даже система загрузилась успешно, из-за отсутствия 
отдельных firmware она дальше может не совсем корректно работать. 
Проблема затрагивает даже обычный rootfs. Здесь мы получаем возможность, 
при желании, отлавливать ситуации разъезда новых зависимостей ядра при 
его обновлении.


-- 
WBR, Leonid Krivoshein.

Re: [make-initrd] Possible missing firmware

[Alexey Gladkov]

On Sat, Jul 05, 2025 at 03:47:15AM +0300, Leonid Krivoshein wrote:
> А если начать с самого мягкого варианта -- предупреждения с "-v" и с 
> фильтрацией по спискам? Например, в 
> "/etc/initrd.mk.d/{modules,firmware}/*.list" файлы со списками по тем 
> модулям/фирмварям, по которым не нужно выводить предупреждения?

Это ужасная идея.

> Во первых, эти списки можно будет потом опакетить. Во-вторых, это даст 
> возможность изучить вопрос во времени без спама пользователей. 
> Предпосылка: если даже система загрузилась успешно, из-за отсутствия 
> отдельных firmware она дальше может не совсем корректно работать. 
> Проблема затрагивает даже обычный rootfs. Здесь мы получаем возможность, 
> при желании, отлавливать ситуации разъезда новых зависимостей ядра при 
> его обновлении.

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

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

-- 
Rgrds, legion

Re: [make-initrd] Possible missing firmware

[Leonid Krivoshein]

On 7/5/25 11:36, Alexey Gladkov wrote:
> On Sat, Jul 05, 2025 at 03:47:15AM +0300, Leonid Krivoshein wrote:
>> А если начать с самого мягкого варианта -- предупреждения с "-v" и с
>> фильтрацией по спискам? Например, в
>> "/etc/initrd.mk.d/{modules,firmware}/*.list" файлы со списками по тем
>> модулям/фирмварям, по которым не нужно выводить предупреждения?
> Это ужасная идея.
>
>> Во первых, эти списки можно будет потом опакетить. Во-вторых, это даст
>> возможность изучить вопрос во времени без спама пользователей.
>> Предпосылка: если даже система загрузилась успешно, из-за отсутствия
>> отдельных firmware она дальше может не совсем корректно работать.
>> Проблема затрагивает даже обычный rootfs. Здесь мы получаем возможность,
>> при желании, отлавливать ситуации разъезда новых зависимостей ядра при
>> его обновлении.
> Давай сначала сделаем шаг назад и ты опишешь проблему, которую предлагаешь
> решить. А также масштаб проблемы. Потому что для меня сейчас проблема
> видится несколько надуманной.
>
> Прошу, потому что из тех сообщений об ошибках я себе нафантазировал одно,
> а ты и Антон думаете скорее всего про другое.

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


-- 
WBR, Leonid Krivoshein.

Re: [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

Re: [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.

Re: [make-initrd] Possible missing firmware

[Alexey Gladkov]

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