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=1751727627; bh=0dRGvgGmPgrShvem61+WFvdDlhZ5v+vDSQgDs9L952U=; h=Date:From:To:Subject:References:In-Reply-To:From; b=BvXPXeQlNghLD0XTmLw/aJQWdi016WbJUjQeJE1/9Qcd9slqiTA5Lbz7VPwNdFaMf rCw9+N1hmW8AssF0eUdg48RsfVfbiigZMcv0kjrakWOsNMRtQ/czKwAfs4ljHKtJ5g 6x09/M4JBUO6u+ZBUNB3C5oVPnBrUL0suKjb1e701NhL4waGj2l/f0CFmyOozTcH7O 1X3+g36IF7CS1QaOsDLBJ1g6AFlaz2T9kkOP2AEyZF6+Uu1ukzwg1qXaE1ggYqbWc1 D6GR5KscSG/P7S1yWlEM6GsnJrSmyIP9IhRT0polOZQgoDcBm51/kMOKVI7LF1VgIS 5+qsKUeXUGtZQ== Date: Sat, 5 Jul 2025 17:00:23 +0200 From: Alexey Gladkov To: make-initrd@lists.altlinux.org Message-ID: References: <99bf271f-f81d-4588-b10d-0dda94e1277c@altlinux.org> <7ea72ffa-4e94-4e22-9158-6930530c675c@gmail.com> <8fc9f887-7448-4e4e-a2a1-a829a8b25f1f@gmail.com> <73b7d08b-5a20-4dfb-86df-0471151708c6@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <73b7d08b-5a20-4dfb-86df-0471151708c6@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 15:00:31 -0000 Archived-At: List-Archive: 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