Re: [devel] Fwd: Политика установки и обновления grub-efi

[Leonid Krivoshein <klark.devel@gmail.com>]

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) 
>> <bugzilla-daemon@altlinux.ru>
>> To:     klark@altlinux.org
>>
>>
>>
>> https://bugzilla.altlinux.org/41959
>> Component: Sisyphus/grub-efi
>>
>> --- #21 from Leonid Krivoshein <klark@altlinux.org> ---
>> grub-efi-autoupdate для removable -- лишь часть политики установки и 
>> обновления grub-efi, которую имеет смысл поменять накануне 11.0. 
>> Детали ("зачем, почему?") можно обсудить в devel@, тут коротко 
>> предлагаю такой план:
>>
>> 1. На шагах разметки и установки загрузчика имеющийся ESP проверяется 
>> на предмет не только FAT, но и NTFS. Последнее нарушает стандарт и 
>> требует обязательного конвертирования в FAT.
>>
>> 2. Нужно проверять, есть ли раздел ESP. Если нет, только тогда его 
>> создаём. А если есть, я бы очищал его полностью. Но можно спросить 
>> пользователя, нужно ли его сохранить? По мне, так лучше его молча 
>> бэкапить.
>>
>> 3. Ориентироваться на EFI/<efi_distributor> по умолчанию не следует, 
>> если только пользователь об этом явно не попросит. Очень сильно этого 
>> могут захотеть лишь те, кто, во-первых, понимает, зачем им это надо, 
>> во-вторых, используют несколько ОС на машине, в-третьих, знает, что 
>> их 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.