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=1708417089; x=1709021889; 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=Zd7mgu+qmN2crYhz7gquL5o1YFdrGnbCS2+l6q5V0F4=; b=dHUnISJxpy7nPNHc9NmbPl3L1jHPH0vV2znlc9vAfa0YUT07BJW6Il+dyJwkmGhDA9 Afr5Vo+3O+vRfGjoYHDjIV+PMMnLcmtsPmPWpCjhUhYgu+SgHF8y7Tch6NzbrKwc/bZV 8qlMssreDZBd2m7mNMEra9/1hUaU6Fb7hxllSgl8VntV4xOY/ieM/JRf5+Z8Q5VUXoL8 m/oK2lxkVz8YtnH7InA6H+HUTB9SSjS5MjTvbMw3NLd7GZA+o/YJklTBo9cgan2vzQGN CoCKKPpR8jyDJ8xNNhvynKby+jorcKA/l9Fm+11NhrPBziz2pfH5CB5EzD6CU08llFP5 E7YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708417089; x=1709021889; 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=Zd7mgu+qmN2crYhz7gquL5o1YFdrGnbCS2+l6q5V0F4=; b=Czolhzz4LwAhewMjBZYIk/0Oe6b98ps5V1fohUo9bnhTlBD+SgTEg2y8w21sI0NoO+ jFfKyTi3JwKFSHP8pqDxa8QyrPJ0R7j0qSYzDXDzQ8nCqvIyd0CL5LY1HL5WD6owzSEi l7ZonHU70k1h8mDgvuo4JEfCZO12ldMm1rm4/n+FlLCal0lzevEGUS1CkEaZ4NxKBlJX ct2Haw3oc6NXEUS1CsqwwbZIVQ55QdCi58GlUUVQHNxvkf7itzTQV+eWnZB/o5iEW9Db TpdaAMDVtUVycu91Baw32KNRw4d/y46DBycfmYQu3L19Tk8calr+nbYAQPHlY/fxUbPV uxWw== X-Gm-Message-State: AOJu0YzjNlYA+sCdjlWZtnkRzNikWSDFHzxn3DRikPuUlmOjV6G+LvfI Attn7Bh9yiWF313thPdresmDzRiVu7r5bybzu24s/KTaJx6yksms8mKsHemb X-Google-Smtp-Source: AGHT+IEMU3u22RfYEdzG26n5AQn09EoaDaJDqb3t6eh6L5TlVt6vjXI/By5C4WttvyoeEOfCnwWN9A== X-Received: by 2002:a19:f706:0:b0:511:9746:6794 with SMTP id z6-20020a19f706000000b0051197466794mr9494084lfe.60.1708417088922; Tue, 20 Feb 2024 00:18:08 -0800 (PST) Message-ID: <978836d8-109b-41c9-8f86-a3f7661d4642@gmail.com> Date: Tue, 20 Feb 2024 11:18:07 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: devel@lists.altlinux.org References: <34e38dbd-9465-4429-b1ce-f46a5745a8cd@gmail.com> <17a386d6-8600-4a53-a4ff-fac07c5014f1@basealt.ru> Content-Language: ru, en-US From: Leonid Krivoshein In-Reply-To: <17a386d6-8600-4a53-a4ff-fac07c5014f1@basealt.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] =?utf-8?b?RndkOiDQn9C+0LvQuNGC0LjQutCwINGD0YHRgtCw0L0=?= =?utf-8?b?0L7QstC60Lgg0Lgg0L7QsdC90L7QstC70LXQvdC40Y8gZ3J1Yi1lZmk=?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2024 08:18:14 -0000 Archived-At: List-Archive: List-Post: On 2/20/24 07:45, Anton Farygin wrote: > On 20.02.2024 02:58, Leonid Krivoshein wrote: >> Для обсуждения. С небольшими добавками... >> >> п.1 -- только intel. >> >> п.6 -- при обновлении grub-efi NVRAM вообще не надо трогать, за >> исключением ситуации отсутсвия в ней записи $EFI_DISTRIBUTOR, если мы >> её создавали при установке. В этом случае её надо создать заново. > > nvram надо трогать иногда, когда меняются правила работы с nvram. Когда это они менялись? На худой конец, если "поменяются правила", перед запуском grub-efi-autoupdate просто удаляется имеющаяся запись. Вообще запись в NVRAM иногда м.б. чревата, мы заранее проверить этого не можем, пользователь об этом д.б. предупреждён, пусть это будет его риском. Спецификация UEFI допускает загрузку без записи в NVRAM (3.5.1.1, grub-install --removable), но именно в этом месте может иметь широкую трактовку производителями железа (отличия в реализации), так что в большинстве случаев хорошо бы "догонять" после запуска grub вызовом efibootmgr при установке, если пользователь не выразил явного нежелания. В этом случае все записи из NVRAM желательно предварительно вычистить, что согласно спецификации должно включить их заводской recovery после создания нашей единственной записи. А какой смысл менять уже существующую запись? > Пункт 1 - ты предлагаешь конвертировать NTFS в VFAT ? Думаю что это > плохая идея Новаторство в том, что не только Альт -- все дистрибутивы Linux спотыкаются об это и не справляются с ситуацией, когда производитель железа в нарушении спецификации допускает загрузку с подготовленного недокументированным способом раздела ESP, отформатированного в NTFS, на котором установлен загрузчик Windows. Они таким способом дополнительно защищают предустановленную систему от того, чтобы рядом с ней чего-то ставили, но скорее это игры в монополию. Особенно часто замечено за техникой HP, жалоб много. Нужно, чтобы установщик хотя бы обнаруживал такую ситуацию и предупреждал, что загрузиться новая конфигурация не сможет, если не переформатировать раздел ESP в FAT32. Установщик не должен создавать второй ESP раздел, BIOS его всё равно проигнорирует, grub-efi всё равно споткнётся на шаге alterator-grub, поскольку не сможет выполнить установку загрузчика на NTFS-раздел, если мы оставим его как есть. Главное здесь -- автоматически решать сложную проблему, а не перекладывать решение на плечи неподготовленного пользователя. > Пункт 2 - вычищать раздел ESP нельзя, мы должны сосуществовать с > другими системами. Предлагаемое не противоречит возможности сосуществования. Выбор д.б. за пользователем на шаге установки загрузчика. Большинству это сосуществование вообще не нужно, они буду переустанавливать единственную ОС. Также замечу, что установка нашего загрузчика grub-efi обеспечивает такое сосуществование в более лучшей форме. В большинстве случаев необходимо, чтобы меню выбора загружаемой ОС было перенесено из разношёрстных firmware со своими заморочками в наш стандартный загрузчик. > И из предложенного непонятно что делать с кривыми BIOS'ами, которые > трактуют установленные системы в режиме removable как хотят. Проблема не в кривизне прошивки, а в интерпретации ей порядка загрузки, когда он не определён явно через NVRAM. Догоняющий вызов efibootmgr должен помочь, поскольку мы увеличиваем надёжность. Ссылки: 3. The UEFI boot manager is a firmware policy engine that can be configured by modifying architecturally defined global NVRAM variables. The boot manager will attempt to load UEFI drivers and UEFI applications (including UEFI OS boot loaders) in an order defined by the global NVRAM variables. *The platform firmware must use the boot order specified in the global NVRAM variables for normal boot*. 3.5.1.1. To generate a file name *when none is present in the FilePath*, the firmware must append a default file name in the form \EFI\BOOT\BOOT{machine type short-name}.EFI where machine type short-name defines a PE32+ image format architecture. > С записью nvram хотя бы есть шанс ими управлять Верно, как написано выше. Но если есть кривизна железа, пользователю нужен шанс её учитывать. Если о машине заведомо известно, что её NVRAM трогать нельзя, значит флажком отключаем. Если пользователю нужны имеющиеся сторонние записи в NVRAM и он не хочет, чтобы мы вычистили потенциальный "мусор", он флажком просит установщик не чистить NVRAM перед созданием нашей записи. >> >> >> -------- Forwarded Message -------- >> Subject:     [Bug 41959] grub-efi-autoupdate для removable >> Date:     Mon, 19 Feb 2024 22:56:54 +0000 >> From:     Leonid Krivoshein (ALT Linux Bugzilla) >> >> To:     klark@altlinux.org >> >> >> >> https://bugzilla.altlinux.org/41959 >> Component: Sisyphus/grub-efi >> >> --- #21 from Leonid Krivoshein --- >> grub-efi-autoupdate для removable -- лишь часть политики установки и >> обновления grub-efi, которую имеет смысл поменять накануне 11.0. >> Детали ("зачем, почему?") можно обсудить в devel@, тут коротко >> предлагаю такой план: >> >> 1. На шагах разметки и установки загрузчика имеющийся ESP проверяется >> на предмет не только FAT, но и NTFS. Последнее нарушает стандарт и >> требует обязательного конвертирования в FAT. >> >> 2. Нужно проверять, есть ли раздел ESP. Если нет, только тогда его >> создаём. А если есть, я бы очищал его полностью. Но можно спросить >> пользователя, нужно ли его сохранить? По мне, так лучше его молча >> бэкапить. >> >> 3. Ориентироваться на EFI/ по умолчанию не следует, >> если только пользователь об этом явно не попросит. Очень сильно этого >> могут захотеть лишь те, кто, во-первых, понимает, зачем им это надо, >> во-вторых, используют несколько ОС на машине, в-третьих, знает, что >> их UEFI Firmware очень хорошо справляется с задачей управляения >> записями NVRAM, включая вывод более удобных меню, нежели это делает >> grub-efi. >> >> 4. Исходя из вышесказанного, вариант установки grub-efi по умолчанию >> только в EFI/BOOT, т.е. как в сабже c --removable, как у всех >> Linux-дистрибутивов и главное, как у Windows. С полной перезаписью >> того, что там есть. Не важно, наше оно, чьё-то ещё или ядро EFI STUB, >> ставится с нуля или обновляется, grub-efi сам найдёт всё, что было на >> диске, и сделает своё меню, обычно более юзабельное, чем во >> встроенной firmware. >> >> 5. Значимые переменные конфигурации grub-efi хранятся в >> /etc/sysconfig/grub2 (grub-common), наши grub'овские скрипты патчены >> под него всё равно, так что не надо придумывать никаких контрольных >> сумм. Всё, что мы установили, с какими параметрами, сохраняется тут, >> и если включено автообновление (по умолчанию д.б. включено), то >> берётся снова отсюда. grub-efi не всегда реально удалить из-за >> цепочки зависимостей, так что любителям под себя перезаточить >> содержимое /EFI/BOOT -- велкам на ВиКи и руками лопатить данный конфиг. >> >> > > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel -- WBR, Leonid Krivoshein.