* [make-initrd] Possible missing firmware @ 2025-07-02 23:37 Leonid Krivoshein 2025-07-04 10:42 ` Alexey Gladkov 0 siblings, 1 reply; 16+ messages in thread From: Leonid Krivoshein @ 2025-07-02 23:37 UTC (permalink / raw) To: make-initrd Всем привет! Обратил внимание на такую интересную фичу в аналогичном инструменте: 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [make-initrd] Possible missing firmware 2025-07-02 23:37 [make-initrd] Possible missing firmware Leonid Krivoshein @ 2025-07-04 10:42 ` Alexey Gladkov 2025-07-04 10:43 ` Anton Midyukov 0 siblings, 1 reply; 16+ messages in thread From: Alexey Gladkov @ 2025-07-04 10:42 UTC (permalink / raw) To: make-initrd 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [make-initrd] Possible missing firmware 2025-07-04 10:42 ` Alexey Gladkov @ 2025-07-04 10:43 ` Anton Midyukov 2025-07-04 11:38 ` Alexey Gladkov 0 siblings, 1 reply; 16+ messages in thread From: Anton Midyukov @ 2025-07-04 10:43 UTC (permalink / raw) To: make-initrd 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [make-initrd] Possible missing firmware 2025-07-04 10:43 ` Anton Midyukov @ 2025-07-04 11:38 ` Alexey Gladkov 2025-07-04 13:20 ` Alexey Gladkov 0 siblings, 1 reply; 16+ messages in thread From: Alexey Gladkov @ 2025-07-04 11:38 UTC (permalink / raw) To: make-initrd 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [make-initrd] Possible missing firmware 2025-07-04 11:38 ` Alexey Gladkov @ 2025-07-04 13:20 ` Alexey Gladkov 2025-07-04 15:03 ` Alexey Gladkov 0 siblings, 1 reply; 16+ messages in thread From: Alexey Gladkov @ 2025-07-04 13:20 UTC (permalink / raw) To: make-initrd 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [make-initrd] Possible missing firmware 2025-07-04 13:20 ` Alexey Gladkov @ 2025-07-04 15:03 ` Alexey Gladkov 2025-07-04 15:23 ` Leonid Krivoshein 0 siblings, 1 reply; 16+ messages in thread From: Alexey Gladkov @ 2025-07-04 15:03 UTC (permalink / raw) To: make-initrd 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [make-initrd] Possible missing firmware 2025-07-04 15:03 ` Alexey Gladkov @ 2025-07-04 15:23 ` Leonid Krivoshein 2025-07-04 18:23 ` Alexey Gladkov 0 siblings, 1 reply; 16+ messages in thread From: Leonid Krivoshein @ 2025-07-04 15:23 UTC (permalink / raw) To: make-initrd Привет! 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [make-initrd] Possible missing firmware 2025-07-04 15:23 ` Leonid Krivoshein @ 2025-07-04 18:23 ` Alexey Gladkov 2025-07-05 0:47 ` Leonid Krivoshein 0 siblings, 1 reply; 16+ messages in thread From: Alexey Gladkov @ 2025-07-04 18:23 UTC (permalink / raw) To: make-initrd 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [make-initrd] Possible missing firmware 2025-07-04 18:23 ` Alexey Gladkov @ 2025-07-05 0:47 ` Leonid Krivoshein 2025-07-05 8:36 ` Alexey Gladkov 0 siblings, 1 reply; 16+ messages in thread From: Leonid Krivoshein @ 2025-07-05 0:47 UTC (permalink / raw) To: make-initrd 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [make-initrd] Possible missing firmware 2025-07-05 0:47 ` Leonid Krivoshein @ 2025-07-05 8:36 ` Alexey Gladkov 2025-07-05 13:04 ` Leonid Krivoshein 0 siblings, 1 reply; 16+ messages in thread From: Alexey Gladkov @ 2025-07-05 8:36 UTC (permalink / raw) To: make-initrd 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [make-initrd] Possible missing firmware 2025-07-05 8:36 ` Alexey Gladkov @ 2025-07-05 13:04 ` Leonid Krivoshein 2025-07-05 15:00 ` Alexey Gladkov 0 siblings, 1 reply; 16+ messages in thread From: Leonid Krivoshein @ 2025-07-05 13:04 UTC (permalink / raw) To: make-initrd 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [make-initrd] Possible missing firmware 2025-07-05 13:04 ` Leonid Krivoshein @ 2025-07-05 15:00 ` Alexey Gladkov 2025-07-05 22:40 ` Leonid Krivoshein 0 siblings, 1 reply; 16+ messages in thread From: Alexey Gladkov @ 2025-07-05 15:00 UTC (permalink / raw) To: make-initrd 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [make-initrd] Possible missing firmware 2025-07-05 15:00 ` Alexey Gladkov @ 2025-07-05 22:40 ` Leonid Krivoshein 2025-07-05 23:57 ` Alexey Gladkov 0 siblings, 1 reply; 16+ messages in thread From: Leonid Krivoshein @ 2025-07-05 22:40 UTC (permalink / raw) To: make-initrd 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [make-initrd] Possible missing firmware 2025-07-05 22:40 ` Leonid Krivoshein @ 2025-07-05 23:57 ` Alexey Gladkov 2025-07-06 15:36 ` Leonid Krivoshein 0 siblings, 1 reply; 16+ messages in thread From: Alexey Gladkov @ 2025-07-05 23:57 UTC (permalink / raw) To: make-initrd 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [make-initrd] Possible missing firmware 2025-07-05 23:57 ` Alexey Gladkov @ 2025-07-06 15:36 ` Leonid Krivoshein 2025-07-06 17:25 ` Alexey Gladkov 0 siblings, 1 reply; 16+ messages in thread From: Leonid Krivoshein @ 2025-07-06 15:36 UTC (permalink / raw) To: make-initrd 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [make-initrd] Possible missing firmware 2025-07-06 15:36 ` Leonid Krivoshein @ 2025-07-06 17:25 ` Alexey Gladkov 0 siblings, 0 replies; 16+ messages in thread From: Alexey Gladkov @ 2025-07-06 17:25 UTC (permalink / raw) To: make-initrd On Sun, Jul 06, 2025 at 06:36:47PM +0300, Leonid Krivoshein wrote: > > Признаться я не понимаю твою терминологию: stage1, stage2, ... > > Первая стадия загрузки из initramfs, вторая стадия уже в стационарный > rootfs после switch_root. Ясно. спасибо. > > В большинстве упоминается, что помогло обновление linux-firmware. Но к > > сожалению я не увидел, что проблема именно в нехватке файлов firmware, а > > не в багах в самих firmware. > > Я просто не стал лазить по багзиле более детально. Мне постоянно > приходится смотреть логи со всевозможного железа. С amdgpu такое > эпизодически вылазит. Наш набор упакованных файлов видимо какой-то > другой, не полный. Партнёры присылают "правильный" набор, но с > непонятными лицензиями и из неизвестного источника, мы такое даже не > можем опакетить. И нет нормального инструмента, чтобы чётко > диагностировать, что у нас не так с firmware. И тот же инструмент помог > бы быстро и точно диагностировать баг с BT в ядре, там как раз разъезд > путей. Я наверно неправильно выразился. Я не просил доказательств. Если бы ты просто сказал, то это очень массовое явление, то я бы тебе поверил. Раз нет инструмента, то давай конечно что-нибудь придумаем. Тем более, что пока я копался вчера с firmware, то открыл портал в ад. Оказывается, в поле модуля firmware не имена, а паттерны, хотя описание макроса MODULE_FIRMWARE ни о чём таком не говорит. Это делает выяснение списка firmware мягко говоря сложнее для обычного скрипта. > >>>> когда новое initrd уже сгенерировано и не получилось загрузиться или > >>>> получилось, но эта новая связка создала проблемы при дальнейшей работе. > >>>> Мы могли бы выявлять потенциальные проблемы уже на этапе создания > >>>> initrd. А без реализации предлагаемого мы не сможем даже примерно > >>>> оценить масштаб этой проблемы для будущих обновлений. Поэтому я считаю, > >>>> что такой инструмент был бы полезным. Хотя бы подсчитывать число > >>>> предупреждений без вывода их в stderr, если не указан "-v". > >>> Я считаю, что никто из пользователей не будет смотреть на эти > >>> предупреждения об отсутствующих firmware. > > Ещё раз: это не для пользователей, им достаточно строчки со статистикой, > остальное только с "-v". Можно даже сделать это частью make-initrd > bug-report. Ок. Убедил. Но вот с bug-report мне не очень понятно. Баг-репорт это просто инфа про систему, а не про initramfs. Что ты предлагаешь туда класть в контексте firmware ? Список всех firmware, которые на момент bug-report были на машине ? > > Кто и как будет поддерживать и обновлять эти фильтры ? Я этого делать не > > буду просто потому что релизы make-initrd выходят реже kernel и firmware. > > Хороший и непростой вопрос, но он следующий. Сейчас даже базы нет, чтобы > использовать это для диагностики. Пока фильтров нет, пока они не > заполнены, понятно, что с "-v" сообщений будет больше. Как только > кто-то, например я, начнёт пользоваться и анализировать данный вывод, > начнут появляться фильтры. Продвинутый админ тогда сможет настроить > фильтр под свою систему за ненадобностью вообще всех прошивок. Конечно, > если он использует "-v". Без "-v" эти фильтры будут влиять только на > цифры в статистике. Давай пока обойдёмся без фильтров и просто пусть будут сообщения. Плюс depinfo будет уметь показывать отсутствующие firmware. > >>> 3. Можно сделать фичу по определению firmware требовавшихся для загрузки > >>> текущего ядра и пробовать использовать эту информацию. В этом случае можно > >>> будет по аналогии с MODULES_ADD добавить контроль за необходимыми > >>> firmware. > >>> Из минусов, что это всё ещё хак по определению требуемых firmware и всё > >>> равно нужно будет решать задачу с путями. > >> Пункт 3 уязвим к односторонним изменениям в апстриме ядра или firmware. > > Но ты ничего не сказал, про пункт 2. > > Сказал, что тебе видней. Раз так, то ограничусь сообщениями. Эвристики для firmware это отдельное дело и его нужно делать только есть запрос. -- Rgrds, legion ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2025-07-06 17:25 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2025-07-02 23:37 [make-initrd] Possible missing firmware Leonid Krivoshein 2025-07-04 10:42 ` Alexey Gladkov 2025-07-04 10:43 ` Anton Midyukov 2025-07-04 11:38 ` Alexey Gladkov 2025-07-04 13:20 ` Alexey Gladkov 2025-07-04 15:03 ` Alexey Gladkov 2025-07-04 15:23 ` Leonid Krivoshein 2025-07-04 18:23 ` Alexey Gladkov 2025-07-05 0:47 ` Leonid Krivoshein 2025-07-05 8:36 ` Alexey Gladkov 2025-07-05 13:04 ` Leonid Krivoshein 2025-07-05 15:00 ` Alexey Gladkov 2025-07-05 22:40 ` Leonid Krivoshein 2025-07-05 23:57 ` Alexey Gladkov 2025-07-06 15:36 ` Leonid Krivoshein 2025-07-06 17:25 ` Alexey Gladkov
Make-initrd development discussion This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/make-initrd/0 make-initrd/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 make-initrd make-initrd/ http://lore.altlinux.org/make-initrd \ make-initrd@lists.altlinux.org make-initrd@lists.altlinux.ru make-initrd@lists.altlinux.com public-inbox-index make-initrd Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.make-initrd AGPL code for this site: git clone https://public-inbox.org/public-inbox.git