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=1751822746; bh=iv5q+O0SvSmuO/Gp1k97m5xArx/9b6QafRUJfIxQuyk=; h=Date:From:To:Subject:References:In-Reply-To:From; b=m9IFtoV84lib1abBCJp/vy7BfR3UlJtPdsCuj/+xZ7IXZeQEn2WEMeRnHC7mBp5Ef Sedurvas56xanAlJOevsY0drGM0pWo8EhIqlquSbeHRFTWNPXpSm1MqrVVA/45PiWO GkhrRDU+Qp1pnt5ha3TWVirr3HCj/9ezHRIaVpd5phVw3z9eY2Kajqtuv2jTOOU6jW W0YKfdR5lacDoqtUCEyXY/bNThHbnlHVVRr07oEONYB60gVzaPNyzZFvFSkUsFgzDv 0izpD2EZJMk48fzLH20HWmDHtPRN5u55b+BkZYfCB0+qomyGzQlFx2pAbxze4AGNVj pRk4Jzmw0w+/w== Date: Sun, 6 Jul 2025 19:25:42 +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> <7054f951-85ab-4fcc-8787-f33db604c5dc@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7054f951-85ab-4fcc-8787-f33db604c5dc@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: Sun, 06 Jul 2025 17:25:50 -0000 Archived-At: List-Archive: 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