Спасибо @Time4Tea за помощь.Как оказалось, для этого было ОЧЕНЬ ОЧЕНЬ ПРОСТОЕ решение. Файл grub.cfg, который я разместил ранее, который находился в (hd0,1)/EFI/ubuntu/grub.cfg, также известном как /dev/sda1/EFI/ubuntu/grub.cfg, просто нуждался в изменении префикса с (hd0,gpt5)на (hd0,8), где находился файл grub.cfg, который я создал с помощью sudo update-grub2. расположены. Я перезаписал его с помощью nano и сохранил, смонтировав /dev/sda1/из Ubuntu (после ручного использования терминала grub для загрузки в Ubuntu ). Ниже представлен новый файл с одним небольшим изменением:

search.fs_uuid 7e076866-97b4-4d3c-b864-491137212645 root hd0,gpt5
set prefix=(hd0,8)'/boot/grub'
configfile $prefix/grub.cfg

Как я уже упоминал в комментариях, я не совсем понимаю, для чего предназначен раздел «BIOS boot» и почему у вас есть несколько разных файлов grub.cfg, разбросанных по разным разделам. Я думаю, что все, что вам нужно, это один файл grub.cfg, из которого вы сможете загрузить как Linux, так и Windows.

Еще один момент — убедиться, что действующий USB-накопитель, с которого выполняется обновление, был создан и загружен в режиме EFI, а не в устаревшем режиме загрузки BIOS. Простой способ проверить это — загрузиться с USB и проверить, существует ли файл /sys/firmware/efi. Если это не так, значит, он не был загружен в режиме EFI.

У меня довольно похожая двойная -загрузочная система с Windows/Linux. Я проверил это и обнаружил только один файл grub.cfgв корневом разделе системы Linux в папке /boot/grub. Системный раздел EFI монтируется в /boot/efi во время загрузки.

Что касается вашего вопроса об изменении grub.cfgв разделе EFI :, это не должно причинить вреда. На самом деле, если вам по какой-то причине нужно несколько grub.cfgфайлов, вероятно, будет лучше поддерживать файлы самостоятельно (, а не надеяться, что инструмент автоматического обновления справится с этим правильно ). Я бы сначала создал резервную копию -автоматически -созданного файла, и вы также можете протестировать команды загрузки в командной строке grub перед изменением файла. Худшее, что может случиться, если вы что-то испортите, — это то, что вы попадете в командную строку GRUB, где вам придется вводить команды загрузки вручную. Если вы не знаете, как это сделать, возможно, вам придется загрузиться с живого USB и исправить/восстановить файл.

Другое дело, что если вы внесете изменения в grub.cfgвручную, они могут быть перезаписаны в следующий раз, когда GRUB выполнит автоматическое -обновление (. В этом случае я, вероятно, отключу update-grub command. ] в вашем дистрибутиве Linux ).

Для тех, кто обнаружит этот вопрос в будущем и использует облако -init на своем сервере (либо на выделенных серверах, например. через MAAS или виртуальные серверы (VPS )через любое программное обеспечение для виртуализации или «облачных» провайдеров ), есть очень простое решение.

Как я столкнулся с этой проблемой

Я перенес rootfs на одной из своих виртуальных машин с исходного корневого раздела на новый диск -и обнаружил, что update-grubбудет продолжать использовать PARTUUID исходных rootfs. Сначала я предположил, что это просто проблема, связанная с его запуском в chroot, поэтому я вручную исправил UUID в /boot/grub/grub.cfgи перезагрузился.

После загрузки в новый раздел rootfs я запустил update-grub, надеясь, что запуск его из реальной системы, работающей на новом диске, теперь будет использовать правильные UUID -, к сожалению, нет.

Я поискал в Интернете и наткнулся на этот вопрос StackExchange. В одном ответе рекомендовалось проверить /boot/efiлюбые дополнительные файлы конфигурации, которые могут быть полезными. Конечно же, я нашел /boot/efi/boot/grub/grub.cfg, который, по-видимому, содержал жестко закодированный UUID FS :

root@host ~ # cat /boot/efi/boot/grub/grub.cfg
# CLOUD_IMG: This file was created/modified by the Cloud Image build process
search.fs_uuid 897a358a-acba-4b07-867c-33d1ca3b28dc root hd0,gpt1
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

Я исправил fs_uuid, но это все еще не полностью исправило update-grubустановку неправильного PARTUUID в /boot/grub/grub.cfg.

Однако в конце концов я заметил подозрительный файл конфигурации в журналах команды update-grub:

root@host ~ # update-grub
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/40-force-partuuid.cfg'
Sourcing file `/etc/default/grub.d/50-cloudimg-settings.cfg'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file...
Found linux image: /boot/vmlinuz-5.4.0-71-generic
Found initrd image: /boot/initrd.img-5.4.0-71-generic
Found linux image: /boot/vmlinuz-5.4.0-24-generic
Found initrd image: /boot/initrd.img-5.4.0-24-generic
done

Окончательное решение проблемы

Хм...Sourcing file '/etc/default/grub.d/40-force-partuuid.cfg'-force partuuid? Выглядел виновником.

root@host ~ # cat /etc/default/grub.d/40-force-partuuid.cfg
GRUB_FORCE_PARTUUID=897a358a-acba-4b07-867c-33d1ca3b28dc

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

После изменения GRUB_FORCE_PARTUUIDна PARTUUID моего раздела rootfs и повторного -запуска update-grubон, наконец, использовал правильный PARTUUID в grub.cfg:)

Резюме

Чтобы устранить эту проблему в системах, использующих cloud-init, сначала вам нужно записать как UUID файловой системы (UUID=), так и UUID раздела(PARTUUID=)для вашей корневой файловой системы (и/или, возможно, вашей загрузки. раздел если у вас отдельный )от blkidкоманда:

root@host ~ # blkid
/dev/sda1: UUID="wcrpSm-QCZu-VN3A-I503-sQqQ-5xfw-76r5bd" TYPE="LVM2_member" PARTUUID="bec389fc-4274-5245-babb-7d90674f1662"
/dev/sdb2: LABEL_FATBOOT="UEFI" LABEL="UEFI" UUID="072E-C819" TYPE="vfat" PARTUUID="78730ead-03d3-e14d-b4fe-ee0abf4f0ad5"
/dev/sdb3: UUID="6cea6786-510a-4fba-871b-7811b63b3453" TYPE="xfs" PARTUUID="530c353b-0be8-e34e-affb-bd5c2332abc7"

В моем случае /dev/sdb3— это и rootfs, и загрузочный раздел.

Теперь откройте /boot/efi/boot/grub/grub.cfgв редакторе по вашему выбору (, например. nanoилиvim)и замените часть UUID fs_uuid XXXX-XXXXна UUID вашей файловой системы, например, в моем случае это6cea6786-510a-4fba-871b-7811b63b3453

Затем откройте /etc/default/grub.d/40-force-partuuid.cfgи замените значение UUID GRUB_FORCE_PARTUUID=на UUID вашего PARTITION (PARTUUID ), который в моем случае 530c353b-0be8-e34e-affb-bd5c2332abc7.

Наконец, запустите update-grub-, а затем проверьте /boot/grub/grub.cfgи убедитесь, что теперь он использует правильный UUID FS + PARTUUID.

Теперь вы сможете обновить конфигурацию GRUB и спокойно перезагрузиться, не застревая в initramfs из-за неверных UUID:)

Если вы пришли сюда после очень долгого поиска, пытаясь заставить облачный образ Ubuntu работать с менеджером Virt -, потому что вы получаете сообщение об ошибке «GRUB _FORCE _PARTUUID, попытка загрузки без загрузки» см. здесь :https://askubuntu.com/questions/1375589/what-are-the-different-versions-available-as-ubuntu-cloud-images