From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751759863; bh=Mxxypy2kVlqZf0aH/Cj1xat1a9CtOXhmtfZyunzWNsY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=pBMkUcD+aIyCS8mQEod+syfm2LffDzO+Ezt0rQzzY5dDJAFPeqt7u2wMP9RLvNVLL KBKtiHjF11N1QK/48GiLxscJADwRRBa2cOJRx7F9WyrvS9AWj8tSYR2DwhEfTCfIQL W+N8vQi4+kB9O0K3qZEw7B3AQrjJsMKkJ6XpLn+v7T21Co5lX0Ej3dx1P+LT/qwmNd 3HoCXo5UV8ulwLhZX4xxmB3IqpP8etWOrgGZQwHQe9NgBHTBqOyCvEdSjcm/QTupYA bu0HO5eHvEjS7FyNCz2NU0F34w/Ji5xl3n3unDmm+zZ/rL2kNoquzRFK1RCFz9a7ty d6KdcVkpJRF0w== Date: Sun, 6 Jul 2025 01:57:39 +0200 From: Alexey Gladkov To: make-initrd@lists.altlinux.org Message-ID: References: <7ea72ffa-4e94-4e22-9158-6930530c675c@gmail.com> <8fc9f887-7448-4e4e-a2a1-a829a8b25f1f@gmail.com> <73b7d08b-5a20-4dfb-86df-0471151708c6@gmail.com> <2f81ae4a-606a-4cfd-9bdd-4d8c234d74c4@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2f81ae4a-606a-4cfd-9bdd-4d8c234d74c4@gmail.com> Subject: Re: [make-initrd] Possible missing firmware X-BeenThere: make-initrd@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: make-initrd@lists.altlinux.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2025 23:57:48 -0000 Archived-At: List-Archive: 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