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=1751755224; x=1752360024; 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=Gn/ceCbgU7hjG1veN4j1zvvfFBjJC5gJ1GKHnkSqIV4=; b=fIDOFME0RVVN2Y5t8+cQSUnbSgP2tyAtzIx8RETeat6mtJwkoTME7j5NM5gzGmlEVN JbEOLtrXReD+I3XqYIsAnCGfZXITIQhU/Jrl1/aK6h1Ba1J7HGhP7VQxyOL4bpRLp/nf MUPMf0TTpnUzf7jkx8wqVGuzz9QKWJrBftHLhTUJRQ5kAQc9Wp2utgWb1ynW6D1CuZE/ upvRkzaBvG9VnZJnuQ+ZP/7M9sYCYbioEu/grgWeRMGe8VkQRh0VO6aWGiNtFA0rkB0j NS/yw+FQ4wFBIfICnqkPJ8pGWrnIms9vdX0tHgwZCQwyNvdEIJhvA0wy3kwLZCHHL81Q XPfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751755224; x=1752360024; 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=Gn/ceCbgU7hjG1veN4j1zvvfFBjJC5gJ1GKHnkSqIV4=; b=WFM8gz4o2YCj6RoWxqB44uwlKrE9JWXCxuH4wTqLVwz1W+TvxBiAQDK13xd6fTROIF GN8mBBHBBrO4rA1w/xuCCdh9Wv9FBRwzEX8eqCSsWjtanXppeQ7SGSOothz9MMib55Mc RmiSeM4fXBgWEHGGb8il4kzH/tld1uoCEWxq1uSEZgQlbpKb2N91GlJYR0Q8i2WaerAV IN3dFF561oPz21bMIZQHf26MkLnbwS3UKBjB/0IU3cLHC9HikNjR8VYElT3HZo6tgOjm AMgjBvVFL22NRtkFDdgsL/m1zBgLQahgCF1Xev2/HMVWKs9+7CMRv0/L7YmUP7fNCPMr TXxQ== X-Gm-Message-State: AOJu0Yzja12Q8mLK+BDwvg6EqINi3zVHzTJDS92BPhdtyvDtHxEhEGq7 WxPBe3IaRGLo0X6TF3vIhOT3Y9/1DgOaJzHk4s6/yr46j92sAFI93kNf83bG9g== X-Gm-Gg: ASbGncsEZAMuW2qQtEH/eB7F93LXyhJrpo1XnkYdyj+WnniE+b+6/keNoKxrlYRBAWn BpSJoMO3Z/lv9uMExwVirsW5E5UbZqLGp9WcxYs3E81T11goPaB924PTQvQs2AnjsoinQ1XVlSs WXCwf0X0WMay1CVSyYPc2Dd8xLBfwGWswGSukkOoZ59bSaq7p5YHB3/Wr1O32P+SQMEbQgy1RB/ Vy0vmm5ushvnLSE3IhfkRi1mDHHuQic69cwbk7j5UllTdzogcV9b+S5xbXFEbIzs6zLVfmY/As5 fW4M/Jfp3mkYu9mTsDOSNSnz0BslX+K3BM4G5G77xB0/1IEG/LV0Rbz+mSKzZdCGZtvhJ5dTp/C 7Tk4B1PE3zkG+lvaR3iw1VKT3FuF+yhfxWXZN X-Google-Smtp-Source: AGHT+IEOG5AZ0tCIPjxPwoSFF6dXHjxOCXWK/A6mHVgTq+EtiR7uQZY57G1prbs33f39+fcNU1ajbA== X-Received: by 2002:a05:6512:6d2:b0:553:2375:c6ea with SMTP id 2adb3069b0e04-556de26e070mr2357694e87.50.1751755223332; Sat, 05 Jul 2025 15:40:23 -0700 (PDT) Message-ID: <2f81ae4a-606a-4cfd-9bdd-4d8c234d74c4@gmail.com> Date: Sun, 6 Jul 2025 01:40:19 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: make-initrd@lists.altlinux.org 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> 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: Sat, 05 Jul 2025 22:40:26 -0000 Archived-At: List-Archive: 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.