Продублирую еще хвост оригинального треда:

(Ответ для Anton Farygin на комментарий #15)
> А почему в этом месте нельзя проверить оба варианта ?
>  $EFI_DIR/EFI/BOOT/BOOT*.EFI и GRUB*.EFI ?

Проверить можно.
Просто напомню, что наличие EFI/BOOT - это не только признак "--removable" установки после того, как его добавили для объезда ошибок в некоторых новых UEFI-прошивках (где основная загрузочная запись пропадала при отсутствии EFI\BOOT).

Раньше в усложнении условий в efi-boot-autoupdate не было необходимости, а сейчас просто придется рассмотреть все возможные варианты.

Николай, напоминаю об этой проблеме.

(Ответ для Ivan A. Melnikov на комментарий #0)
> Однако такой вариант заменяет на grub не только старый grub, но и любой
> другой загрузчик, включая, например, переименованный shim (что ломает secure
> boot).

Определить, что там grub, а не другой загрузчик можно по наличию EFI/BOOT/grub.cfg
Для того, чтобы отличить --removable от --force-extra-removable, нужно смотреть, есть ли каталог EFI/altlinux (уже же делается). Если есть, то не --removable.

Можно попробовать так:

diff --git a/grub-efi-autoupdate b/grub-efi-autoupdate
index 844788721..180259aac 100755
--- a/grub-efi-autoupdate
+++ b/grub-efi-autoupdate
@@ -25,9 +25,9 @@ GRUB_REMOVABLE=
 
 if ! stat $EFI_DIR/EFI/$DIST/grub*.efi > /dev/null 2>&1; then
 	echo "$EFI_DIR/EFI/$DIST/grub*.efi is missing, not fatal yet."
-	if ! stat $EFI_DIR/EFI/BOOT/grub*.efi > /dev/null 2>&1; then
+	if ! stat $EFI_DIR/EFI/BOOT/grub.cfg > /dev/null 2>&1; then
 		echo
-		echo "$EFI_DIR/EFI/BOOT/grub*.efi is missing too. Fatal."
+		echo "$EFI_DIR/EFI/BOOT/grub.cfg is missing too. Fatal."
 		echo "Nothing to update. Please run: grub-install && grub-efi-autoupdate"
 		echo
 		echo "If your system lacks NVRAM or you are getting persistent errors, please"

(In reply to Антон Мидюков from comment #3)
> Определить, что там grub, а не другой загрузчик можно по наличию
> EFI/BOOT/grub.cfg

У меня на riscv64 такого нет.

# find /boot/efi/EFI -type f
/boot/efi/EFI/altlinux/grubriscv64.efi
/boot/efi/EFI/BOOT/BOOTRISCV64.EFI

(Ответ для Ivan A. Melnikov на комментарий #4)
> (In reply to Антон Мидюков from comment #3)
> > Определить, что там grub, а не другой загрузчик можно по наличию
> > EFI/BOOT/grub.cfg
> 
> У меня на riscv64 такого нет.
> 
> # find /boot/efi/EFI -type f
> /boot/efi/EFI/altlinux/grubriscv64.efi
> /boot/efi/EFI/BOOT/BOOTRISCV64.EFI

Да, и на aarch64. А если выполнить
grub-install --removable

то появится. Причина в опции --no-uefi-secure-boot, с которой собираются на aarch64 и riscv64. Надо её убрать из tar2fs.

(In reply to Антон Мидюков from comment #5)
> (Ответ для Ivan A. Melnikov на комментарий #4)
> > (In reply to Антон Мидюков from comment #3)
> > > Определить, что там grub, а не другой загрузчик можно по наличию
> > > EFI/BOOT/grub.cfg
> > 
> > У меня на riscv64 такого нет.
> > 
> > # find /boot/efi/EFI -type f
> > /boot/efi/EFI/altlinux/grubriscv64.efi
> > /boot/efi/EFI/BOOT/BOOTRISCV64.EFI
> 
> Да, и на aarch64. А если выполнить
> grub-install --removable
> 
> то появится.

[root@unmatched1 ~]# grub-install --removable
Installing for riscv64-efi platform.
Installation finished. No error reported.
[root@unmatched1 ~]# find /boot/efi/EFI -type f
/boot/efi/EFI/altlinux/grubriscv64.efi
/boot/efi/EFI/BOOT/BOOTRISCV64.EFI

HiFive Unmatched, загружалась grub'ом.

(Ответ для Ivan A. Melnikov на комментарий #6)
> (In reply to Антон Мидюков from comment #5)
> > (Ответ для Ivan A. Melnikov на комментарий #4)
> > > (In reply to Антон Мидюков from comment #3)
> > > > Определить, что там grub, а не другой загрузчик можно по наличию
> > > > EFI/BOOT/grub.cfg
> > > 
> > > У меня на riscv64 такого нет.
> > > 
> > > # find /boot/efi/EFI -type f
> > > /boot/efi/EFI/altlinux/grubriscv64.efi
> > > /boot/efi/EFI/BOOT/BOOTRISCV64.EFI
> > 
> > Да, и на aarch64. А если выполнить
> > grub-install --removable
> > 
> > то появится.
> 
> [root@unmatched1 ~]# grub-install --removable
> Installing for riscv64-efi platform.
> Installation finished. No error reported.
> [root@unmatched1 ~]# find /boot/efi/EFI -type f
> /boot/efi/EFI/altlinux/grubriscv64.efi
> /boot/efi/EFI/BOOT/BOOTRISCV64.EFI
> 
> HiFive Unmatched, загружалась grub'ом.

Действительно так. Если запустить
grub-install --removable -v

то в конце будет
grub-install: info: No Secure Boot: installing core image.
grub-install: info: copying `/boot/grub/riscv64-efi/core.efi' -> `/boot/efi/EFI/BOOT/BOOTRISCV64.EFI'.

Т.е. grub.cfg записывается, если grub подписан. Наличие shim при этом не требуется, что показывает пример aarch64.

Итого: идея с ориентиром на EFI/BOOT/grub.cfg не подходит.

(Ответ для Ivan A. Melnikov на комментарий #0)
> По мотивам обсуждения в #41945
> 
> Коммит [1] добавляет в grub-efi-autoupdate обновление конфигураций,
> использующих grub-install --removable. 
> 
> [1]
> http://git.altlinux.org/gears/g/grub.git?a=commitdiff;
> h=3af85716bdb15e6434d37e76ff3e29a02eba3425
> 
> Однако в таких ситуациях не используется путь $EFI_DIR/EFI/BOOT/grub*.efi;
> вместо этого grub использует путь для efi-загрузчика по-умолчанию,
> определённый спецификацией UEFI: $EFI_DIR/EFI/BOOT/BOOT*.EFI. Исправление
> могло бы быть тривиальным:
> 
> http://git.altlinux.org/people/iv/packages/?p=grub.git;a=commitdiff;
> h=e2f359146bc70c0b0e2c4793b8d83d0ac373ad8a
> 
> Однако такой вариант заменяет на grub не только старый grub, но и любой
> другой загрузчик, включая, например, переименованный shim (что ломает secure
> boot).
> 
> Надо как-то разрулить эту ситуацию.

На x86_64 под именем BOOT*.EFI прячется SHIM*.EFI, можно дополнительно проверить еще и наличие grub*.efi и делать выводы где мы оказались.
Или усложнить скрипт платформозависимыми суффиксами и выстраивать поведение на из основе.

Проблема в том, что под именем BOOT*.EFI может быть всё, что угодно. Даже собранное пользователем ядро с efistub, которое он сам туда положил. Поэтому заменять BOOT*.EFI на grub из нового пакета можно только если это grub из старого пакета.

Как понять, что BOOT*.EFI это grub из старого пакета? На данный момент -- никак. Никакой информации о том, что из себя представлял старый grub, у grub-efi-autoupdate просто нет, а косвенные признаки ненадёжны.

Значит, нужно где-то оставить эту информацию.

Предлагаю сделать это сурово, брутально и бессердечно: grub-install --removable должен, когда копирует grub в BOOT*.EFI, положить рядом файл с его контрольной суммой, скажем $EFI_DIR/EFI/BOOT/alt.grub.sha1. Или в /etc/ где-нибудь, если в $EFI_DIR страшно. И если такгого файла нет или контрольные суммы не совпадают, ничего не делать.

А давайте подумаем ещё с другой стороны. В принципе, чем нас не устраивает grub-install --force-extra-removable? Мне кажется, что только тем, что он лезет в NVRAM.
Отсюда вопрос: а действительно ли нужно лезть в NVRAM при выполнении grub-efi-autoupdate? В самой NVRAM же обновляем только информацию, где находится EFI-бинарик. Его местоположение же не меняется? Тогда в чём необходимость? Если необходимости нет, то можно добавить --no-nvram. И тогда будем при сборке img указывать --force-extra-removable --no-nvram вместо --removable. Собственно, это и сейчас можно делать, но не нравится только то, что grub-efi-autoupdate тогда лезет в NVRAM, которого нет.

(Ответ для Антон Мидюков на комментарий #10)
> А давайте подумаем ещё с другой стороны. В принципе, чем нас не устраивает
> grub-install --force-extra-removable? Мне кажется, что только тем, что он
> лезет в NVRAM.
> Отсюда вопрос: а действительно ли нужно лезть в NVRAM при выполнении
> grub-efi-autoupdate? В самой NVRAM же обновляем только информацию, где
> находится EFI-бинарик. Его местоположение же не меняется? Тогда в чём
> необходимость? Если необходимости нет, то можно добавить --no-nvram. И тогда
> будем при сборке img указывать --force-extra-removable --no-nvram вместо
> --removable. Собственно, это и сейчас можно делать, но не нравится только
> то, что grub-efi-autoupdate тогда лезет в NVRAM, которого нет.

У --removable и --force-extra-removable разное поведение при использовании c опцией --uefi-secure-boot. В первом случае создаётся EFI/BOOT/grub.cfg, во втором - не создаётся, из-за чего не грузится. С --no-uefi-secure-boot EFI/BOOT/grub.cfg не нужен.

Но, если вернуться к коду, то выдумывать ничего не надо. Есть надёжный признак определения removable - $EFI_DIR/EFI/BOOT/grub*.efi
И на самом деле вопрос другой: почему работает неправильно --removable в режиме --no-uefi-secure-boot? В этом режиме grub*.efi должен быть скопирован в два места: в $EFI_DIR/EFI/BOOT/grub*.efi и $EFI_DIR/EFI/BOOT/BOOT*.efi
Вот такое решение напрашивается.

Created attachment 14057 [details]
EFI/BOOT/grub.cfg такой же признак removable, как и EFI/BOOT/grub*.efi

Предлагаю вернуться к первоначальной мысли про /EFI/BOOT/grub.cfg
Его можно создавать при сборке образа и при установке в alterator-grub.

(In reply to Ivan A. Melnikov from comment #9)
> Проблема в том, что под именем BOOT*.EFI может быть всё, что угодно. Даже
> собранное пользователем ядро с efistub, которое он сам туда положил.

Как обработается этот use case? Мне он важен.

(Ответ для Ivan A. Melnikov на комментарий #13)
> (In reply to Ivan A. Melnikov from comment #9)
> > Проблема в том, что под именем BOOT*.EFI может быть всё, что угодно. Даже
> > собранное пользователем ядро с efistub, которое он сам туда положил.
> 
> Как обработается этот use case? Мне он важен.

Если EFI/BOOT/grub.cfg нет, то не затрётся EFI/BOOT/BOOT*.EFI.
EFI/BOOT/grub.cfg не появится сам.

Распишу сценарий подробнее.

1. Пользователь поставил дистрибутив Альт. Появился EFI/BOOT/grub.cfg.

2. Пользователь понял, что ядро альта его не устраивает, и собрал своё. Поскольку в особенностях нашего grub он не понимает (а кто в них понимает?), ядро он собрал сразу с efi stub и загружает его без загрузчика. EFI/BOOT/grub.cfg не удалил, так как откуда бы он узнал, что его нужно удалить.

3. Через пару месяцев с очередным dist-upgrade обновился grub и, увидев EFI/BOOT/grub.cfg, затёр что смог.

Пункты 1 и 2 основаны на реальных событиях, такие пользователи у одноплатников есть.

(Ответ для Ivan A. Melnikov на комментарий #15)
> Распишу сценарий подробнее.
> 
> 1. Пользователь поставил дистрибутив Альт. Появился EFI/BOOT/grub.cfg.
> 
> 2. Пользователь понял, что ядро альта его не устраивает, и собрал своё.
> Поскольку в особенностях нашего grub он не понимает (а кто в них понимает?),
> ядро он собрал сразу с efi stub и загружает его без загрузчика.
> EFI/BOOT/grub.cfg не удалил, так как откуда бы он узнал, что его нужно
> удалить.

Не пользуешься grub, удали его.

> 
> 3. Через пару месяцев с очередным dist-upgrade обновился grub и, увидев
> EFI/BOOT/grub.cfg, затёр что смог.
> 
> Пункты 1 и 2 основаны на реальных событиях, такие пользователи у
> одноплатников есть.

Что за одноплатник такой?

Коллеги, попробовал разобраться в этой проблеме.
Получается нас интересует пропуск автообновления grub, когда:
1. grub был установлен с --removable (нет директории altlinux)
2. установка была с --no-uefi-secure-boot (установлен только grub как BOOT/BOOT<efiarch>.EFI)
3. BOOT<efiarch>.EFI не является grub

Как по мне проблема надумана и пользователь, который собрал на свой страх и риск ядро с efi stub и загружает его без загрузчика должен создать себе отдельный boot entry или удалить grub на системах без NVRAM. В grub-efi-autoupdate можно добавить warning, что BOOT<efiarch>.EFI обновлен и перезаписан на grub или shim.

(In reply to Ivan A. Melnikov from comment #9)
> Предлагаю сделать это сурово, брутально и бессердечно: grub-install
> --removable должен, когда копирует grub в BOOT*.EFI, положить рядом файл с
> его контрольной суммой, скажем $EFI_DIR/EFI/BOOT/alt.grub.sha1. Или в /etc/
> где-нибудь, если в $EFI_DIR страшно. И если такгого файла нет или
> контрольные суммы не совпадают, ничего не делать.

С другой стороны можно действительно добавить создание файла с чексуммой в grub-efi-autoupdate сразу после grub-install и проверку в начало.
Например как-то так:
grub-install -v 2>&1 | grep -o "/boot/efi[^']*" | xargs md5sum

(Ответ для Egor Ignatov на комментарий #17)
> Коллеги, попробовал разобраться в этой проблеме.
> Получается нас интересует пропуск автообновления grub, когда:
> 1. grub был установлен с --removable (нет директории altlinux)

Если есть shim, то grub обновляется. А вот если его нет, то не обновляется.
И наличие директории altlinux обновиться не поможет. grub обновится только в ней.
Так что мы хотим, чтобы обновление происходило, если в BOOT/BOOT<efiarch>.EFI действительно grub.
На системах без NVRAM --removable у нас стандартный вариант установки. Кроме того, для переносного SSD это тоже стандартный вариант, так как записываться в NVRAM противопоказано.

> 2. установка была с --no-uefi-secure-boot (установлен только grub как
> BOOT/BOOT<efiarch>.EFI)

На riscv64 не получается установиться с --uefi-secure-boot, так как grub не подписан. grub.cfg всегда встраивается.

> 3. BOOT<efiarch>.EFI не является grub
> 
> Как по мне проблема надумана и пользователь, который собрал на свой страх и
> риск ядро с efi stub и загружает его без загрузчика должен создать себе
> отдельный boot entry или удалить grub на системах без NVRAM. В
> grub-efi-autoupdate можно добавить warning, что BOOT<efiarch>.EFI обновлен и
> перезаписан на grub или shim.
> 

Да, warning не помешает.

> (In reply to Ivan A. Melnikov from comment #9)
> > Предлагаю сделать это сурово, брутально и бессердечно: grub-install
> > --removable должен, когда копирует grub в BOOT*.EFI, положить рядом файл с
> > его контрольной суммой, скажем $EFI_DIR/EFI/BOOT/alt.grub.sha1. Или в /etc/
> > где-нибудь, если в $EFI_DIR страшно. И если такгого файла нет или
> > контрольные суммы не совпадают, ничего не делать.
> 
> С другой стороны можно действительно добавить создание файла с чексуммой в
> grub-efi-autoupdate сразу после grub-install и проверку в начало.
> Например как-то так:
> grub-install -v 2>&1 | grep -o "/boot/efi[^']*" | xargs md5sum

Но можно и так. Только создание контрольной суммы будет при каком условии происходить? Если только в grub-efi-autoupdate, то как она появится в первый раз? При установке grub-efi-autoupdate не используется. Придётся реализовывать при установке и сборке образа.

Вообще целостность $EFI_DIR/EFI/BOOT/BOOT*.EFI и/или $EFI_DIR/EFI/BOOT/GRUB*.EFI можно проверять в %pre скрипте grub-efi, таким образом можно определить, что мы обновляем именно наш grub старой версии, а не собранный пользователем. Но тогда, наверное, нужно еще и в %pre shim-signed делать проверку.

(Ответ для Egor Ignatov на комментарий #19)
> Вообще целостность $EFI_DIR/EFI/BOOT/BOOT*.EFI и/или
> $EFI_DIR/EFI/BOOT/GRUB*.EFI можно проверять в %pre скрипте grub-efi, таким
> образом можно определить, что мы обновляем именно наш grub старой версии, а
> не собранный пользователем. Но тогда, наверное, нужно еще и в %pre
> shim-signed делать проверку.

Давайте уже решим эту багу как-нибудь.
Она актуальна для кейса установки на ESP из RAID1 c суперблоком 0.9 или 1.0.
В этом случае совершенно естественно, что ставим в режиме removable, так как наш grub не может сделать записи в NVRAM для каждого раздела. Да и если бы и мог, всё равно после замены одного из диска требовалось вы вручную делать grub-efi-autoupdate.

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

(In reply to Ivan A. Melnikov from comment #9)
> Как понять, что BOOT*.EFI это grub из старого пакета? На данный момент --
> никак. Никакой информации о том, что из себя представлял старый grub, у
> grub-efi-autoupdate просто нет, а косвенные признаки ненадёжны.

На самом деле есть. У всех наших efi бинарей есть секция .sbat по которой можно точно определить, что BOOT*.EFI это старый grub или shim. 

Подготовил изменение grub-efi-autoupdate[1], прошу всех заинтересованных проверить покрывает ли новый скрипт все редкие случаи.

[1] https://git.altlinux.org/people/egori/packages/grub.git?p=grub.git;a=commit;h=a47dcd0d57198a4bee2fd11b474f60ff5fd30e5c

(In reply to Egor Ignatov from comment #22)
> На самом деле есть. У всех наших efi бинарей есть секция .sbat по которой
> можно точно определить, что BOOT*.EFI это старый grub или shim. 

Это интересно, идея хороша.

> Подготовил изменение grub-efi-autoupdate[1], прошу всех заинтересованных
> проверить покрывает ли новый скрипт все редкие случаи.

Насчёт всех случаев пока не вчитывался но есть вопрос.

Нормально ли это, что grub начинает зависеть от binutils? Я слышал, что, например, в какие-то наши защищённые дистрибутивы нельзя включать компиляторы.

(In reply to Ivan A. Melnikov from comment #23)
> Насчёт всех случаев пока не вчитывался но есть вопрос.
> 
> Нормально ли это, что grub начинает зависеть от binutils? Я слышал, что,
> например, в какие-то наши защищённые дистрибутивы нельзя включать
> компиляторы.

Да, правильное замечание.
Заменил objcopy на самописную утилиту: https://git.altlinux.org/people/egori/packages/grub.git?p=grub.git;a=commitdiff;h=bf8a0a922fe0868db21cf7fb5dc4ab0212dd58d6

grub-2.12-alt1 -> sisyphus:

 Tue Jul 23 2024 Egor Ignatov <egori@altlinux> 2.12-alt1
 - 2.12
 - grub-efi-autoupdate: update only ALT Linux GRUB efi images (closes: #41959)
 - grub-install: validate grub root volume in efi boot (fixes: CVE-2023-4001)
 - grub-install: install efi grub.cfg for removable (closes: #39745)
 - grub-mkconfig: add --class altlinux for menuentries (closes: #39609)
 - support xfsprogs >= 6.5.0 (closes: #49891)
 - add sysconfig option GRUB_TOP_LEVEL set to /boot/vmlinuz (closes: #48681)
 - package unicode.pf2 to the datadir also (closes: #39616)

Created attachment 16855 [details]
полный лог grub-install на loongarch64.

(In reply to Egor Ignatov from comment #22)
> На самом деле есть. У всех наших efi бинарей есть секция .sbat по которой
> можно точно определить, что BOOT*.EFI это старый grub или shim. 

Наконец-то добрался потестировать это дело на loongarch64. Изменения, необходимые для сборки, минималистичны, можно посмотреть здесь:

https://git.altlinux.org/people/iv/packages/grub.git?a=shortlog;h=refs/tags/2.12-alt0.port

Даже после grub-install --force имеем следующее:

# grub-efi-autoupdate
Searching for ALT Linux GRUB efi image to update
Skipping /boot/efi/EFI/BOOT/BOOT*.EFI (not ALT Linux GRUB)
Skipping /boot/efi/EFI/BOOT/grub*.efi (not ALT Linux GRUB)
Skipping /boot/efi/EFI/altlinux/grub*.efi (not ALT Linux GRUB)

ALT Linux EFI GRUB image was not found, nothing to update. Please run:
grub-install && grub-efi-autoupdate

If your system lacks NVRAM or you are getting persistent
errors, please run:
grub-install --removable && grub-efi-autoupdate

Почему? Потому что на платформах без secure boot grub-install устанавливает core.efi:

grub-install: info: No Secure Boot: installing core image.
grub-install: info: copying `/boot/grub/loongarch64-efi/core.efi' -> `/boot/efi/EFI/altlinux/grubloongarch64.efi'.

А в это core.efi секция sbat не попадает.

При этом на x86_64 используется собранный из пакета grubx64.efi, в котором sbat естественно есть:

grub-install: info: copying `/usr/lib64/grub/x86_64-efi/../../efi/grubx64.efi' -> `/boot/efi/EFI/altlinux/grubx64.efi'.

Кстати, секции sbat в /boot/grub/x86_64-efi/core.efi у меня на x86_64 тоже нет.

Пока пробегал мимо, обратил внимание. x86_64, сизиф:

# grub-dumpsbat /boot/efi/EFI/altlinux/grubx64.efi | cut -d, -f5
1
2.06
2.12-alt3

Это нормально что во второй и третьей строке версии разные? Я в спецификацию SBAT пока не настолько сильно вчитался, но мне кажется, что всё-таки нет.

(In reply to Ivan A. Melnikov from comment #27)
> Пока пробегал мимо, обратил внимание. x86_64, сизиф:
> 
> # grub-dumpsbat /boot/efi/EFI/altlinux/grubx64.efi | cut -d, -f5
> 1
> 2.06
> 2.12-alt3
> 
> Это нормально что во второй и третьей строке версии разные? Я в спецификацию
> SBAT пока не настолько сильно вчитался, но мне кажется, что всё-таки нет.

Технически на механизм работы SBAT это не влияет, но это действительно ошибка. Спасибо, исправлю.

(In reply to Ivan A. Melnikov from comment #26)
> Created attachment 16855 [details]
[...]
> Почему? Потому что на платформах без secure boot grub-install устанавливает
> core.efi:
> А в это core.efi секция sbat не попадает.

И вот с этим я не знаю, что делать.

- Таскать с собой sbat.csv и при каких-то условиях класть его в образы, создаваемые grub-mkimage?
- Использовать по умолчанию собранный заранее grub, как при включенном Secure Boot (а так можно вообще?)
- Ещё варианты?

(In reply to Ivan A. Melnikov from comment #29)
> (In reply to Ivan A. Melnikov from comment #26)
> > Created attachment 16855 [details]
> [...]
> > Почему? Потому что на платформах без secure boot grub-install устанавливает
> > core.efi:
> > А в это core.efi секция sbat не попадает.
> 
> И вот с этим я не знаю, что делать.
> 
> - Таскать с собой sbat.csv и при каких-то условиях класть его в образы,
> создаваемые grub-mkimage?
Я думаю мы можем класть sbat.csv во все образы, созданные через grub-install. И добавить опцию --disable-sbat или --no-sbat, чтобы grub-install умел делать образы без sbat.
> - Использовать по умолчанию собранный заранее grub, как при включенном
> Secure Boot (а так можно вообще?)
grub-install так и делает для I386_EFI, X86_64_EFI, ARM_EFI, ARM64_EFI и IA64_EFI систем, он проверяет наличие /usr/lib{,64}/efi/grub${efi_suffix}.efi и устанавливает его если он есть и опция --no-uefi-secure-boot не указана явно. Даже при выключенном Secure Boot. Можем добавить LOONGARCH64_EFI, RISCV32_EFI и RISCV64_EFI.
> - Ещё варианты?

(In reply to Ivan A. Melnikov from comment #29)
> (In reply to Ivan A. Melnikov from comment #26)
> > Created attachment 16855 [details]
> [...]
> > Почему? Потому что на платформах без secure boot grub-install устанавливает
> > core.efi:
> > А в это core.efi секция sbat не попадает.
> 
> И вот с этим я не знаю, что делать.
> 
> - Таскать с собой sbat.csv и при каких-то условиях класть его в образы,
> создаваемые grub-mkimage?

Начиная с grub 2.12-alt4 в grub-efi упакован /usr/share/grub/sbat.csv
Логику его добавления в образ нужно продумать отдельно, но так как он по сути отражает закрытие уязвимостей в grub из наших исходников не вижу проблему добавлять его по умолчанию во все образы сделанные grub-mkimage и grub-install.

> - Использовать по умолчанию собранный заранее grub, как при включенном
> Secure Boot (а так можно вообще?)
> - Ещё варианты?

(In reply to Ivan A. Melnikov from comment #9)
> Проблема в том, что под именем BOOT*.EFI может быть всё, что угодно. Даже
> собранное пользователем ядро с efistub, которое он сам туда положил. Поэтому
> заменять BOOT*.EFI на grub из нового пакета можно только если это grub из
> старого пакета.
> 
> Как понять, что BOOT*.EFI это grub из старого пакета? На данный момент --
> никак. Никакой информации о том, что из себя представлял старый grub, у
> grub-efi-autoupdate просто нет, а косвенные признаки ненадёжны.
> 
> Значит, нужно где-то оставить эту информацию.
> 
> Предлагаю сделать это сурово, брутально и бессердечно: grub-install
> --removable должен, когда копирует grub в BOOT*.EFI, положить рядом файл с
> его контрольной суммой, скажем $EFI_DIR/EFI/BOOT/alt.grub.sha1. Или в /etc/
> где-нибудь, если в $EFI_DIR страшно. И если такгого файла нет или
> контрольные суммы не совпадают, ничего не делать.

Также мне тут подумалось, что для продвинутых пользователей, которые устанавливают свой загрузчик (efistab/uki) можно добавить опцию GRUB_DISABLE_AUTOUPDATE в /etc/sysconfig/grub2, чтобы точно не перезаписывать пользовательский загрузчик при обновлении системного grub.

grub-2.12-alt15 -> sisyphus:

Fri Nov 14 2025 Egor Ignatov <egori@altlinux> 2.12-alt15
- grub-install: Embed SBAT metadata by default (closes: #41959)