По мотивам обсуждения в #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). Надо как-то разрулить эту ситуацию.
Продублирую еще хвост оригинального треда: (Ответ для 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. > - Ещё варианты?
