Bug 60316

Summary:

grub-efi-install без проверки перезаписывает EFI резервный файл

Product:

Sisyphus

Reporter:

Жора Змейкин <me>

Component:

grub-efi

Assignee:

Egor Ignatov <egori>

Status:

ASSIGNED ---

QA Contact:

qa-sisyphus

Severity:

normal

Priority:

CC:

egori, nickel, placeholder, rider

Version:

unstable

Hardware:

x86_64

OS:

Linux

Attachments:

Description	Flags
Набросок патча	none

Description

Жора Змейкин 2026-08-30 14:32:27 MSK

Created attachment 22085 [details]
Набросок патча

Сейчас grub-efi-install, когда доступен shim и готовый EFI-образ GRUB, безусловно пытается записать ALT shim в EFI/BOOT/BOOTX64.EFI. В исходном случае операция закончилась ошибкой «mv: File exists», о чём я написал здесь:
https://bugzilla.altlinux.org/show_bug.cgi?id=59632#c5

Проблем здесь две. Если на ESP уже лежит строчный bootx64.efi, а раздел смонтирован с iocharset=utf8, обращение к BOOTX64.EFI может его не найти. Скрипт создаёт BOOTX64.EFI.new, но mv получает EEXIST, и установка обрывается до регистрации ALT в NVRAM. Параметры монтирования исправляются отдельно в guile-evms, но после этого текущий код просто начнёт успешно перезаписывать существующий резервный файл.

При этом grub-efi-install никак не проверяет, кому принадлежит файл. В EFI/BOOT/BOOTX64.EFI может вообще находиться загрузчик Windows или другого дистрибутива, что в редких случаях может сломать двойную загрузку.

В этом плане мне нравится поведение как у openSUSE: отсутствующий резервный файл устанавливать, собственный обновлять, а чужой или неизвестный оставлять без изменений. Я попытался повторить такой подход и набросал патч, он проверяет vendor-запись SBAT и ищет резервный файл без учёта регистра

Comment 1

Egor Ignatov 2026-09-16 10:29:37 MSK

(In reply to Жора Змейкин from comment #0)
> Created attachment 22085 [details]
> Набросок патча
> 
> Сейчас grub-efi-install, когда доступен shim и готовый EFI-образ GRUB,
> безусловно пытается записать ALT shim в EFI/BOOT/BOOTX64.EFI. В исходном
> случае операция закончилась ошибкой «mv: File exists», о чём я написал здесь:
> https://bugzilla.altlinux.org/show_bug.cgi?id=59632#c5
> 
> Проблем здесь две. Если на ESP уже лежит строчный bootx64.efi, а раздел
> смонтирован с iocharset=utf8, обращение к BOOTX64.EFI может его не найти.
> Скрипт создаёт BOOTX64.EFI.new, но mv получает EEXIST, и установка
> обрывается до регистрации ALT в NVRAM. Параметры монтирования исправляются
> отдельно в guile-evms, но после этого текущий код просто начнёт успешно
> перезаписывать существующий резервный файл.

Описал решение в https://bugzilla.altlinux.org/show_bug.cgi?id=59632#c6

> При этом grub-efi-install никак не проверяет, кому принадлежит файл. В
> EFI/BOOT/BOOTX64.EFI может вообще находиться загрузчик Windows или другого
> дистрибутива, что в редких случаях может сломать двойную загрузку.

grub-efi-install не должен проверять кому принадлежит файл, его задача - установить grub в одном из доступных режимов. А вот необходимость установки(обновления) и режим выбирает grub-efi-autoupdate[1].

> В этом плане мне нравится поведение как у openSUSE: отсутствующий резервный
> файл устанавливать, собственный обновлять, а чужой или неизвестный оставлять
> без изменений. Я попытался повторить такой подход и набросал патч, он
> проверяет vendor-запись SBAT и ищет резервный файл без учёта регистра

Сейчас grub-efi-autoupdate для обхода проблем некоторых прошивок всегда делает установку в режиме "force extra removable", то есть при установке в EFI\altlinux делает копию в EFI\BOOT.

При необходимости в рамках этого бага можем обсудить:
1. Дополнительные режимы установки для grub-efi-install (например установка для Secure Boot только в EFI\altlinux\, хоть это и противоречит документации shim[2])
2. Улучшения логики автоопределения режима обновления в grub-efi-autoupdate (продолжение https://bugzilla.altlinux.org/41959)


[1] https://git.altlinux.org/gitoskop/#/gears/g/grub.git/-/blob/sisyphus/altlinux/grub-efi-autoupdate
[2] https://github.com/rhboot/shim/blob/72fd4b70e7562d25234204249462da97080ef56f/README.fallback#L23