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

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

[Leonid Krivoshein]

Для обсуждения. С небольшими добавками...

п.1 -- только intel.

п.6 -- при обновлении grub-efi NVRAM вообще не надо трогать, за 
исключением ситуации отсутсвия в ней записи $EFI_DISTRIBUTOR, если мы её 
создавали при установке. В этом случае её надо создать заново.


-------- 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 -- велкам 
на ВиКи и руками лопатить данный конфиг.


-- 
WBR, Leonid Krivoshein.

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

[Anton Farygin]

On 20.02.2024 02:58, Leonid Krivoshein wrote:
> Для обсуждения. С небольшими добавками...
>
> п.1 -- только intel.
>
> п.6 -- при обновлении grub-efi NVRAM вообще не надо трогать, за 
> исключением ситуации отсутсвия в ней записи $EFI_DISTRIBUTOR, если мы 
> её создавали при установке. В этом случае её надо создать заново.

nvram надо трогать иногда, когда меняются правила работы с nvram.

Пункт 1 - ты предлагаешь конвертировать NTFS в VFAT ? Думаю что это 
плохая идея

Пункт 2 - вычищать раздел ESP нельзя, мы должны сосуществовать с другими 
системами.

И из предложенного непонятно что делать с кривыми BIOS'ами, которые 
трактуют установленные системы в режиме removable как хотят.

С записью 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 -- велкам на ВиКи и руками лопатить данный конфиг.
>
>

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

[Антон Мидюков]

20.02.2024 11:45, Anton Farygin пишет:
> On 20.02.2024 02:58, Leonid Krivoshein wrote:
>> Для обсуждения. С небольшими добавками...
>>
>> п.1 -- только intel.
>>
>> п.6 -- при обновлении grub-efi NVRAM вообще не надо трогать, за исключением ситуации отсутсвия в ней записи $EFI_DISTRIBUTOR, если мы её создавали при установке. В этом случае её надо создать заново.
> 
> nvram надо трогать иногда, когда меняются правила работы с nvram.
> 
> Пункт 1 - ты предлагаешь конвертировать NTFS в VFAT ? Думаю что это плохая идея
> 
> Пункт 2 - вычищать раздел ESP нельзя, мы должны сосуществовать с другими системами.
> 
> И из предложенного непонятно что делать с кривыми BIOS'ами, которые трактуют установленные системы в режиме removable как хотят.
> 
> С записью nvram хотя бы есть шанс ими управлять
> 

На некоторых кривых UEFI мы сейчас получаем следующее.
Мы устанавливаем в каталог EFI/altlinux/ shim + grub + grub.cfg и в дополнение к этому в EFI/BOOT/ shim + grub без grub.cfg
На кривом UEFI пропадает запись altlinux, а наш EFI/BOOT/ определяется как некий Linpus, который грузится, но не находит grub.cfg, поэтому выпадает в grub-rescue.
Выход мне видится в том, чтобы в параллель ставить EFI/altlinux/ shim + grub + grub.cfg и EFI/BOOT/ shim + grub + grub.cfg
Тогда EFI/BOOT/ будет запасным вариантом полноценным. Мне изначально было непонятно почему мы сделали так, как сделали. Скорее всего изначально grub.cfg встраивался в неподписанный grub.
Но теперь то он подписанный всегда и ему нужен внешний grub.cfg

Таким образом, я предложил бы оставить два варианта установки:
- EFI/altlinux/ + EFI/BOOT/ (отличие от сейчас, что в EFI/BOOT создаётся всегда grub.cfg)
- EFI/BOOT/

Второй вариант предлагать дефолтом, когда ESP раздел в RAID1 с суперблоком 0.9 или 1.0. Потому что:
- grub создать записи в nvram для каждого диска у нас в инсталляторе не может, выдаёт ошибку
- после замены диска потребуется создавать запись в NVRAM для заменённого диска
 
Также я предлагаю сделать опцией поддержку Secure Boot. У shim могут быть проблемы с загрузкой на некоторых UEFI, поэтому было бы не плохо иметь возможность при установке его поддержку выключить, сняв галочку.

>>
>>
>> -------- 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

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

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

[Ivan A. Melnikov]

On Tue, Feb 20, 2024 at 02:58:14AM +0300, Leonid Krivoshein wrote:
> 4. Исходя из вышесказанного, вариант установки grub-efi по умолчанию только
> в EFI/BOOT, т.е. как в сабже c --removable, как у всех Linux-дистрибутивов и
> главное, как у Windows. С полной перезаписью того, что там есть. Не важно,
> наше оно, чьё-то ещё или ядро EFI STUB, ставится с нуля или обновляется,
> grub-efi сам найдёт всё, что было на диске, и сделает своё меню, обычно
> более юзабельное, чем во встроенной firmware.

Я знаю человека, который
- сам себе собирает ядра, потому что дистрибутивные -- слишком большие и
  тяжёлые
- собирает их с EFI stub и кладёт их в EFI/BOOT/, потому что grub - это
  лишняя сущность, и чем проще, тем надёжнее.

Как такой человек узнает, чем ему грозит обновление grub?

Как правильно ему пережить такое обновление?

-- 
  wbr,
    iv m.

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

[Антон Мидюков]

20.02.2024 12:54, Ivan A. Melnikov пишет:
> On Tue, Feb 20, 2024 at 02:58:14AM +0300, Leonid Krivoshein wrote:
>> 4. Исходя из вышесказанного, вариант установки grub-efi по умолчанию только
>> в EFI/BOOT, т.е. как в сабже c --removable, как у всех Linux-дистрибутивов и
>> главное, как у Windows. С полной перезаписью того, что там есть. Не важно,
>> наше оно, чьё-то ещё или ядро EFI STUB, ставится с нуля или обновляется,
>> grub-efi сам найдёт всё, что было на диске, и сделает своё меню, обычно
>> более юзабельное, чем во встроенной firmware.
> 
> Я знаю человека, который
> - сам себе собирает ядра, потому что дистрибутивные -- слишком большие и
>   тяжёлые
> - собирает их с EFI stub и кладёт их в EFI/BOOT/, потому что grub - это
>   лишняя сущность, и чем проще, тем надёжнее.
> 
> Как такой человек узнает, чем ему грозит обновление grub?
> 
> Как правильно ему пережить такое обновление?
> 

Если у него нет EFI/BOOT/grub.cfg или EFI/BOOT/grubx64.efi, то обновление ему не должно ничего ломать.


-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

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

[Leonid Krivoshein]

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.

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

[Leonid Krivoshein]

On 2/20/24 08:27, Антон Мидюков wrote:
> 20.02.2024 11:45, Anton Farygin пишет:
>> On 20.02.2024 02:58, Leonid Krivoshein wrote:
>>> Для обсуждения. С небольшими добавками...
>>>
>>> п.1 -- только intel.
>>>
>>> п.6 -- при обновлении grub-efi NVRAM вообще не надо трогать, за исключением ситуации отсутсвия в ней записи $EFI_DISTRIBUTOR, если мы её создавали при установке. В этом случае её надо создать заново.
>> nvram надо трогать иногда, когда меняются правила работы с nvram.
>>
>> Пункт 1 - ты предлагаешь конвертировать NTFS в VFAT ? Думаю что это плохая идея
>>
>> Пункт 2 - вычищать раздел ESP нельзя, мы должны сосуществовать с другими системами.
>>
>> И из предложенного непонятно что делать с кривыми BIOS'ами, которые трактуют установленные системы в режиме removable как хотят.
>>
>> С записью nvram хотя бы есть шанс ими управлять
>>
> На некоторых кривых UEFI мы сейчас получаем следующее.
> Мы устанавливаем в каталог EFI/altlinux/ shim + grub + grub.cfg и в дополнение к этому в EFI/BOOT/ shim + grub без grub.cfg
> На кривом UEFI пропадает запись altlinux, а наш EFI/BOOT/ определяется как некий Linpus, который грузится, но не находит grub.cfg, поэтому выпадает в grub-rescue.
> Выход мне видится в том, чтобы в параллель ставить EFI/altlinux/ shim + grub + grub.cfg и EFI/BOOT/ shim + grub + grub.cfg
> Тогда EFI/BOOT/ будет запасным вариантом полноценным. Мне изначально было непонятно почему мы сделали так, как сделали. Скорее всего изначально grub.cfg встраивался в неподписанный grub.
> Но теперь то он подписанный всегда и ему нужен внешний grub.cfg
>
> Таким образом, я предложил бы оставить два варианта установки:
> - EFI/altlinux/ + EFI/BOOT/ (отличие от сейчас, что в EFI/BOOT создаётся всегда grub.cfg)
> - EFI/BOOT/

Всё это -- результат криво реализованной нами поддержки спецификации 
UEFI. Сравнивал от 2.5 до 2.10, как наиболее актуальных. Собственно, два 
разных поведения определяются пп. 3.5.1.1 и 3.5.1.2. Для увеличения 
надёжности (однозначности) нужно не два каталога создавать, а никогда не 
использовать запись в NVRAM при вызове grub-install, но делать 
стандартные пути на случай кривых BIOS (3.5.1.1, grub-install 
--removable), и одновременно использовать по умолчанию добивающую запись 
в NVRAM через efibootmgr, чтобы определить явно порядок загрузки, что 
поддерживается и верно интерпретируется на большинстве машин, 
желательно, во избежании сюрпризов, с предварительной очисткой NVRAM.


> Второй вариант предлагать дефолтом, когда ESP раздел в RAID1 с суперблоком 0.9 или 1.0. Потому что:
> - grub создать записи в nvram для каждого диска у нас в инсталляторе не может, выдаёт ошибку
> - после замены диска потребуется создавать запись в NVRAM для заменённого диска

grub-install --removable и добивающая запись в efibootmgr обе проблемы 
решают, т.к. первый не пишет и не спотыкается, а второй может быть 
вызван отдельно для каждого диска RAID-1/multipath. И я проверял с 
RAID-1 на альте -- при создании записи в NVRAM и удалении диска, вставки 
нового, запись не будет удалена, есть видео всего процесса.


> Также я предлагаю сделать опцией поддержку Secure Boot. У shim могут быть проблемы с загрузкой на некоторых UEFI, поэтому было бы не плохо иметь возможность при установке его поддержку выключить, сняв галочку.

Отличная идея, стоит добавить в предлагаемую политику. Больше всего 
кривизны как раз с не выключенным SB.


>
>>>
>>> -------- 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.

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

[Leonid Krivoshein]

On 2/20/24 08:54, Ivan A. Melnikov wrote:
> On Tue, Feb 20, 2024 at 02:58:14AM +0300, Leonid Krivoshein wrote:
>> 4. Исходя из вышесказанного, вариант установки grub-efi по умолчанию только
>> в EFI/BOOT, т.е. как в сабже c --removable, как у всех Linux-дистрибутивов и
>> главное, как у Windows. С полной перезаписью того, что там есть. Не важно,
>> наше оно, чьё-то ещё или ядро EFI STUB, ставится с нуля или обновляется,
>> grub-efi сам найдёт всё, что было на диске, и сделает своё меню, обычно
>> более юзабельное, чем во встроенной firmware.
> Я знаю человека, который
> - сам себе собирает ядра, потому что дистрибутивные -- слишком большие и
>    тяжёлые
> - собирает их с EFI stub и кладёт их в EFI/BOOT/, потому что grub - это
>    лишняя сущность, и чем проще, тем надёжнее.
>
> Как такой человек узнает, чем ему грозит обновление grub?

См. п.5 предлагаемой политики. Изначально поведение флажками на шаге 
alteraor-grub регулируется, в дальнейшем -- через /etc/sysconfig/grub2. 
В дефолтном поведении мы обновляем всё, что установили. На остальное 
есть help в установщике и ВиКи.


> Как правильно ему пережить такое обновление?

Отключить автообновление через /etc/sysconfig/grub2. Поскольку случай 
редкий, сомневаюсь, что под него нужен отдельный флажок в установщике. 
Таким людям и установщик-то не особо нужен. Они вполне могут 
догадываться, чем чревато обновление grub, так что их забота -- найти и 
выключить автообновление.


-- 
WBR, Leonid Krivoshein.