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=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751816212; x=1752421012; darn=lists.altlinux.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=p4I5nanf96phb5c8j6oYfJTvYuF0AV1QimDwpdJP9hQ=; b=mtT20hFnR3MpmvNnv/pLSC8DnlT+2YfGRIp/5cMmOM8Yk7NfdwQtVHXUuRD37qGdAA UT2V7lASNbLLsNkNdZhagd4gPW+duFjKxentI5zju09AiKysFzKc00ewCp1epV3vbmH8 InmhClnh6t2KnYqjr9+pRIgFo5fb49sR1J31bktBiNLSyv9IoUW6amN0qCk+56317g90 b/onVUoaG4SV/qGa3dpyOzUDwGd5qPh86XNHYYVaXlE0dv/C17RujSj1AnZxocvObHNQ P+4qpV0ef4JpiH4tBLh/hs2FE3LB8mMHLuvYJ/fJcjGDGngCyt/5c95C54SvsKLqz6Wh +hMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751816212; x=1752421012; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=p4I5nanf96phb5c8j6oYfJTvYuF0AV1QimDwpdJP9hQ=; b=vJiJG82ywnBZpVe6YEcyJnIClb6AsBp402v4/w17h8UczbP1cCi5+G1uIcE5HT/r4p W9hfzpBcPoBAyLFZ7bcg9ikhV2z3EL9xvB0wn4a5UgMzsjG8BX85s1gbYg+9o34y+ujt qXSPfX7epViHGXthXYn7qQtIfVnt/S7KVBLrZ3r0ZRseQbNQsuXMGwAA36Hu2xOme77b rtUODct/yT1Z8pycx+MMq1WVRxObB4WMe6TGKQYN/zS3dSPs5fYchEuqfd1uPRtO5sMs tguNtX5mB3mgaZOWJj7N+YFuG2nY/wGJR7zz2+9bde2YS93wb9MCIuDFDbSg3bDnjQ/Z n/TQ== X-Gm-Message-State: AOJu0Yx8ldHKiYi4l4QfPuVdGcAztleX63ZSH1kdGY4w2drISgAcgOY2 BZgoMEMd0XzUlLczKlRmBS/GMP65XAliLRixvJ5aqlJeeqb8IcamU81tTyNpaw== X-Gm-Gg: ASbGncsRxFZqPaXaaPLN0W/8vUNOrWo+7qXBe4ZLW9wVClONWJpwnjGx4NpKmwrYBFi vQIxdJQ5FAK/Wb7wqWdWOSB4R1C0DtZpCH0KUT8tMGSNsHn08BqVliOrc0CP9aYFwtBYUALtNtP pTsiJvhvCRuy+oamGFPPk4TamBxevzCswozePeoH7M33nG2imcLkYbglE7WgKv23gScSWeq3AWS tgPUInbAm0AfE8xDuZ0Ix4ZwV0i9e63fQk6ksK8IV/AhwFTaGXuLoTjYNZU2yyQM75rdeico2l0 OEGI4BClc6OnjNQQ1KvnlYfg+CTEw1Sc8swykUijCOv6DAejfw2J4yunzwW2+3LYjJ/xjgHo7sI 9rSDclnAMDvWibYYm7GuPR7mDU9063hLtLdK4 X-Google-Smtp-Source: AGHT+IH7f+Zi5mzQTy1SWE01F/1EtcO84P1A+pL/+Y5q/Wwq95hUdN3UBJyocBmn2XGRgd8znDSrOw== X-Received: by 2002:a05:6512:6181:b0:553:accf:d75 with SMTP id 2adb3069b0e04-557e559e63fmr1773318e87.26.1751816211765; Sun, 06 Jul 2025 08:36:51 -0700 (PDT) Message-ID: <7054f951-85ab-4fcc-8787-f33db604c5dc@gmail.com> Date: Sun, 6 Jul 2025 18:36:47 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: make-initrd@lists.altlinux.org 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> Content-Language: ru, en-US From: Leonid Krivoshein In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 15:36:55 -0000 Archived-At: List-Archive: 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.