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 и ищет резервный файл без учёта регистра
(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
