преобразование загрузки из legacy в uefi

• создать EFI раздел и файловую систему на нём
• смонтировать его
• установить GRUB с платформой efi-64

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

Наличие legacy-загрузки никак не мешает наличию uefi загрузки (в случае линукса, винду я так не смог затаваить сделать). А это означает, что речь не про «преобразовать», а «добавить». То есть все выполняемые операция не долдны приводить к тому что legacy-загрузка сломается.

Она возможно слоамается когда-то в будущем, если уже не связанные с переходом между типами загрузки обновления gtub/ядра станут обновлять только один конфигурационный файл. в связи сэтим же хочу предостеречь - от начала работ по получения результата «работают обе загрузки»- не рекомендую обновлять пакеты ядра или grub, даже минорно. Поэтому Иначе может оказаться так что ссылка на обновлённое ядро в том конфиге grub, который пока недонастроен. Соответственно как первый этап - обновите/установите пакеты модулей grub-efi-amd64-bin grub-pc-bin они друг с другом не конфликтуют.

А вот grub-efi-amd64 и grub-pc - как пакеты конфликтуют, но в них содержатся только скрипты обновления/верхнеуровневые утилиты. Так что по идее идее пока пакеты с суффиксом -bin - самому процессу загрузки ничего не угрожают

ну вобщем да, добавить:
создал раздел uefi, с флагом esp и файловой системой fat32
создал каталог /boot/efi
примонтировал раздел uefi в boot/efi
выполнил grub-install --target=x86_64-efi --efi-directory=/boot/efi --removable /dev/sda3
в fstab добавил UUID=xxxx-xxxx /boot/efi......

попробовал загрузиться, выдаёт Grub bash-like line editor, Grub>
и всё... предыдущий загрузчик работает

А конфиг кто напишет? Если не ошибаюсь:

grub-mkconfig -o /boot/efi/grub/grub.cfg

В целом да, но обычно рядом с grub.efi или bootx64.efi файле от grub лежит минимальный конфиг, в котором прописан только search и установка корневой ФС для загрузчика.

Вот в него лучше прописать поиск ФС, которая монтируется в /boot и далее строчку загрузки конфига уже с корня, т.е. с /boot.

А конфиг кто напишет? Если не ошибаюсь:

grub-mkconfig -o /boot/efi/grub/grub.cfg

он создался в /boot/efi/EFI/BOOT, но содержимое не знаю на сколько правильное:

search.fs_uuid 0a7ee881-dd72-4e05-8129-4186066705a4 root hd0,gpt1
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

он создался в /boot/efi/EFI/BOOT, но содержимое не знаю на сколько правильное:

Содержимое правильное, если UUID 0a7ee881-dd72-4e05-8129-4186066705a4 указывает на ФС, которая монтируется в /boot сейчас. Если под /boot нет отдельной ФС, а это корневая - значит UUID 0a7ee881-dd72-4e05-8129-4186066705a4 должен указывать на корневую ФС.

Проверь и поправь.

# cat /boot/efi/EFI/centos/grub.cfg
search --no-floppy --root-dev-only --fs-uuid --set=dev b7588706-c38a-4beb-9e84-e9d01db80e75
set prefix=($dev)/boot/grub2
export $prefix
configfile $prefix/grub.cfg

# blkid | grep 'b7588706-c38a-4beb-9e84-e9d01db80e75'
/dev/vda2: LABEL="root" UUID="b7588706-c38a-4beb-9e84-e9d01db80e75" TYPE="xfs" PARTUUID="9560faf1-4f53-47fb-bb07-8099f4fb310b"

# mount | grep '/dev/vda2'
/dev/vda2 on / type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)

Вот как это сделано в Centos 9 Stream.

Содержимое правильное, если UUID 0a7ee881-dd72-4e05-8129-4186066705a4 указывает на ФС, которая монтируется в /boot сейчас. Если под /boot нет отдельной ФС, а это корневая - значит UUID 0a7ee881-dd72-4e05-8129-4186066705a4 должен указывать на корневую ФС.

Проверь и поправь.

сначала был uuid корневого раздела, поменял на uuid sda3 (/boot/efi), ничего не поменялось

но у меня grub.cfg лежит в /boot/efi/EFI/BOOT

А вот grub-efi-amd64 и grub-pc - как пакеты конфликтуют

И я нахожу это странным. Потому что по факту установить grub для BIOS или EFI решается одним ключиком --target=ПЛАТФОРМА для grub-install, разница лишь в том, что для первого варианта нужно указать в качестве ПЛАТФОРМЫ i386-pc, для второго – x86_64-efi. Я бы понял, если бы это были разные пакеты, как grub-legacy и grub2.

Почти, но сейчас, думаю, нет смысла монтировать ESP в /boot/efi, лучше просто в /efi. А конфиг grub-а пусть себе лежит в традиционном /boot/grub/grub.cfg.

$ sudo grub-install --target=x86_64-efi --boot-directory=/boot --efi-directory=/efi
$ sudo grub-mkconfig -o /boot/grub/grub.cfg

Ну и после создать в NVRAM пункт меню загрузки с помощью efibootmgr.

предыдущий загрузчик работает

В биосе приоритет загрузки выставлен? У меня по F9/F12 всегда было оба варианта загрузки флешки, как legacy и как uefi. В таком случае думаю и в разделе загрузки есть переключатель в каком режиме загружаться. Если грузится legacy, то сколько не исправляй цепочку загрузки uefi ничего не измениться. Она может уже работает, просто на неё надо переключить.

Почти, но сейчас, думаю, нет смысла монтировать ESP в /boot/efi, лучше просто в /efi.

Это я взял во внимание предыдущие шаги ТСа. Сам я монтирую esp в /boot, а в использовании grub-а смысла не вижу при наличии более простых альтернатив.

Уважаемый. Вы сами привели вывод того, что находится в том grub.cfg, что лежит в /boot/efi/EFI/BOOT.

Думалку включите, пожалуйста.

Я вам привёл вывод, как это реализовано в Centos: преобразование загрузки из legacy в uefi (комментарий)

По сути то же, что написали вы.

И до этого вам написал текстом:

В целом да, но обычно рядом с grub.efi или bootx64.efi файле от grub лежит минимальный конфиг, в котором прописан только search и установка корневой ФС для загрузчика.

Вот в него лучше прописать поиск ФС, которая монтируется в /boot и далее строчку загрузки конфига уже с корня, т.е. с /boot.

преобразование загрузки из legacy в uefi (комментарий)

Ещё раз, конфиг, что лежит в /boot/efi/EFI/BOOT, а точнее в ESP(EFI System Partition)/EFI/BOOT/grub.cfg - это минимальный конфиг, в котором прописывается конфигурация для поиска ФС с реальным grub.cfg, который у вас находится в /boot.

Нюанс ещё может быть в том, что grub.efi или он же, точнее копия его bootx64.efi - собирается с нескольких модулей, допустим, по аналогии: https://www.gnu.org/software/grub/manual/grub/grub.html#Secure-Boot-Advanced-Targeting

Собирается efi файл с помощью grub-mkimage / grub2-mkimage.

И в efi файл может быть встроена, а может быть - нет поддержка файловых систем.

Допустим, если у вас корневая файловая система XFS, то в выводе:

strings /boot/efi/EFI/centos/grubx64.efi | grep '^fs'
fs/archelp.c
fshelp
fshelp
fshelp
fs/fat.c
fshelp
fshelp
fs-uuid
fs/xfs.c
fshelp

Вы должны её увидеть. Из моего примера в grubx64.efi встроена поддержка только fat и xfs, других ФС в нём нет.

Т.е. основной конфиг загрузчика будет /boot/grub2.cfg / boot/grub.cfg, а не ESP/EFI/BOOT/grub.cfg. Конфиг в ESP/EFI/BOOT/grub.cfg только для загрузки основного и сам grub.efi должен быть собран с поддержкой ФС, на которой находится основной конфиг.

В Linux файловые системы регистрозависимые, указывать в точности так, как есть.

Почти, но сейчас, думаю, нет смысла монтировать ESP в /boot/efi, лучше просто в /efi. А конфиг grub-а пусть себе лежит в традиционном /boot/grub/grub.cfg.

хочу поставить параллельно, что бы и тот загрузчик остался и uefi

может, конечно, что-то не совсем догоняю....

Вывод приглашения grub - означает что он конфиг не нашёл. Если бы конфиг был незагружаемый - то он бы каие-то ошибки показал или echo прописанные в конфиге бы выполнил.

Если бы модули не нашёл - по идее бы ругнулся что нет модулей и есть только core

Где он в случае efi ищет конфиг сходу не скажу, но по идее где-то рядом собой на новом разделе, это главный вопрос, Где этот конфиг с точки зрения монтирования линукса дело десятое.

Конфиг автоматом не создался как раз потому что относительно низкоуровневый способ установки

Если что монтировать ESP раздел не обязательно, это просто доступ к файлам, не более.

что бы и тот загрузчик остался и uefi

legacy позволяет iso грузить с hdd/ssd для теста, для доступа, для чего угодно, а в uefi только с флешки с Ventoy.

Где он в случае efi ищет конфиг сходу не скажу,

Так там же UUID указан, который root`ом делается.

search --root-dev-only --set=root --fs-uuid тут_должен_быть_UUID_раздела_с_которого_грузится_конфиг
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

Если на машине только Linux, то ничто не мешает так сделать. ESP у вас уже есть, так? Тип разметки MBR, или GPT? Для Legacy-загрузки c диска в GPT нужно в начале диска иметь раздел bios-boot, но не создавать на нём никакой файловой системы. GRUB туда будет устанавливать основную часть себя. Для UEFI-загрузки c диска в MBR нужен ESP с типом EF, отформатированный в FAT32, как и для GPT ESP. Но перед этим разделом должно быть неразмеченное пространство размером 1-2 МиБ. Далее, делаешь

$ sudo grub-install --target=i386-pc /dev/ИМЯ_ДИСКА
$ sudo grub-install --target=x86_64-efi --boot-directory=/boot --efi-directory=/boot/efi
$ sudo grub-mkconfig -o /boot/grub/grub.cfg

# grub-install --target=x86_64-efi --boot-directory=/boot --efi-directory=/boot/efi
Выполняется установка для платформы x86_64-efi.
grub-install: предупреждение: EFI variables cannot be set on this system.
grub-install: предупреждение: You will have to complete the GRUB setup manually.
Установка завершена. Ошибок нет.

grub-install: предупреждение: EFI variables cannot be set on this system

[[ -d /sys/firmware/efi/ ]] && echo "EFI mode" || echo "Legacy mode"

?

Так он загружается в legacy режиме, чтоб настроить grub для работы под UEFI.

А, ну тогда нужно скопировать /boot/efi/EFI/grub/GRUBx64.EFI в ‘/boot/efi/EFI/BOOTx64.efi’, если последнего ещё нет, перезагрузиться уже в EFI-режиме и дать команду:

$ sudo efibootmgr -c -L "имя_по_вкусу" -l "\EFI\grub\GRUBx64.EFI"

Но можно и не делать этого, просто пользоваться скопированным BOOTx64.efi.

выполнил grub-install –target=x86_64-efi –efi-directory=/boot/efi –removable /dev/sda3

Неверно. Всё дальнейшее пошло этой неверной дорогой.

перенос Убунты (MBR -> UEFI)

так заработало

 $ sudo grub-install --target=x86_64-efi --boot-directory=/boot --efi-directory=/boot/efi 

вот возник вопрос, при обновлении, когда обновляется ядро и загрузчик, что именно будет обновляться, legacy или uefi?

Странный вопрос. На всякий случай, grub.cfg и grub.efi в efi разделе это не grub а загрузчик grub-а.

https://wiki.gentoo.org/wiki/GRUB#After_updating_sys-boot.2Fgrub

Насколько я понимаю - для deb-подобных выполняется обработчик нотификации изменений /usr/sbin/update-grub в коорый просто скрипт в котором написано обновить /boot/grub/grub.cfg

То есть это уже зависит от того что куда примонтировано.

Ещё как тут писали в примере несколько сообщений выше - может быть что путь поиска зашитый в grub находит конфиг-редиректор, который уже находит изменяемый из линукса конфиг. При таком сценарии наверное из обоих мест может в конечном счёте ссылаться на один конфиг.

Когда обновляется ядро, загрузчик не обновляется. GRUB это не требуется, в отличие от LILO, потому что он читает образ ядра в память как файл, а не в обход файловой системы (при условии, что образ ядра не меняет своë имя, естественно). После обновления пакета grub2, естественно, потребуется переустановка загрузчика. Пакет содежит послеустановочный сценарий (например, doinst.sh в Slackware, post-install в Debian), или та же функциональность реализуется на стороне менеджера пакетов (например, хуками pacman), который определяет режим загрузки системы и выполняет grub-install с нужными аргументами. Для того, чтобы обновлялись оба варианта загрузчика, нужно убедиться, что послеустановочный сценарий или хук имеют требуемую функциональность, при необходимости – внести правки. С хуками это проще.

Скопируй папку grub, что бы не случилось ты можешь новый загрузчик переименовать в grub1, а из архива взять старую версию вставить взамен.