Кроме того, при загрузке с live cd для восстановления может случиться так, что вам не хватает пакета grub-efi-amd64-bin, а затем строка

"grub-install --target=x86_64-efi /dev/sdb" 

выдает сообщение об ошибке: "grub -install: error: /usr/lib/grub/x86_64-efi/modinfo.sh не существует. Укажите --target или --directory. "

В этом случае запустите это вне chroot

sudo apt get grub-efi-amd64-bin

и затем добавьте / usr / lib / grub / x86_64-efi в chroot mounts.

Кстати, параметр "/ dev / sdb" устарел и игнорируется.

таким образом, мое предположение является причиной проблемы, то, что установка Ubuntu не монтирует efi раздел, если fstab. и обновляет личинку. на обновлении.

в дополнение к ответу ci-netbox.
Если версия ОС вашего подвесного диска не совпадает с версией, установленной на диске, то при установке grub-install могут возникнуть трудности с определением правильной установки grub:

$ sudo chroot /mnt
# grub-install /dev/sdX
grub-install: error: /usr/lib/grub/i386-pc/modinfo.sh doesn't exist. 
Please specify --target or --directory.

Попробуйте определить установку вручную с помощью

# ls /usr/lib/grub/
grub-mkconfig_lib  x86_64-efi  x86_64-efi-signed

Затем перезапустите grub-install :

# grub-install --target=x86_64-efi /dev/sdX 
Installing for x86_64-efi platform.
Installation finished. No error reported.

Спасибо @ cl-netbox за инструкции!

После обновления (Linux Mint 18.2 Sonya до 18.3 Sylvia) моя система не загружалась, поэтому я выполнил инструкции выше, но все равно нет успех. Однако я заметил, что у моей машины / boot в отдельном разделе (возможно, потому, что я использую LVM), поэтому мой слегка измененный процесс был:

sudo mount /dev/sdXXX /mnt
sudo mount /dev/sdXY /mnt/boot
sudo mount /dev/sdXX /mnt/boot/efi
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
sudo chroot /mnt
grub-install /dev/sdX
update-grub 

Примечание: sdX = disk | sdXX = раздел efi | sdXY = загрузочный раздел | sdXXX = системный раздел

Если вы потеряете свой раздел EFI, его легко вернуть. Вы можете использовать инструмент разметки, такой как fdisk или parted , чтобы создать новый раздел sdXY (например, sda1) с типом «EFI partition (1)» и отформатировать его с помощью:

sudo mkfs.msdos /dev/sdXY

затем смонтируйте его с помощью:

sudo mount /dev/sdXY /boot/efi

, и вы можете переустановить GRUB, запустив:

sudo grub-install --efi-directory=/boot/efi

, как указано в других решениях.

это единственный способ, который работал для меня: (System: sdb8, boot: sdb6, efi: sdb2)

sudo mount /dev/sdb8 /mnt 
sudo mount /dev/sdb6 /mnt/boot 
sudo mount /dev/sdb2 /mnt/boot/efi

sudo mount --bind /dev /mnt/dev &&
sudo mount --bind /dev/pts /mnt/dev/pts &&
sudo mount --bind /proc /mnt/proc &&
sudo mount --bind /sys /mnt/sys

sudo chroot /mnt

grub-install --target=x86_64-efi /dev/sdb

grub-install --recheck /dev/sdb

exit &&
sudo umount /mnt/sys &&
sudo umount /mnt/proc &&
sudo umount /mnt/dev/pts &&
sudo umount /mnt/dev &&
sudo umount /mnt

Я не могу комментировать (недостаточно репутации), но ответ @Chilu Pereira - это способ пойти в ситуации EFi или мультизагрузки. Это похоже на подход в gentoo-guide. Они используют несколько иной подход: Вместо mount --bind они используют mount --rbind , за которым следует mount --make-rslave для sys и dev, и proc снова просто монтируется. В gentoo я использовал для создания монтировок из live-системы, например:

mount -t proc /proc /mnt/proc
mount --rbind /sys /mnt/sys
mount --make-rslave /mnt/sys
mount --rbind /dev /mnt/dev
mount --make-rslave /mnt/dev 
chmod 1777 /mnt/dev/shm

(Кто-нибудь знает, в чем разница между - bind и - rbind / --make-rslave кстати?)

Но сегодня я получил две ошибки в chroot от grub2, с которыми я никогда раньше не сталкивался:

 connect: No such file or directory
   Please make sure that the zfs-fuse daemon is running

и

grub-install: warning: Cannot read EFI Boot* variables.
grub-install: warning: read_file: could not read from file: Input/output error.

Ошибка zfs-fuse, похоже, не имеет значения, но для Efivars мне пришлось добавить еще одно крепление :

mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars

Думаю, / sys / firmware / efi / efivars не существует в chroot или, возможно, он доступен только для чтения - но в любом случае это сработало

Вот как я сделал это на стандартном рабочем столе x86_amd64 EFI без chroot, предполагая, что на вашем жестком диске есть раздел, содержащий Ubuntu, и, возможно, раздел EFI, на который следует установить GRUB.

# boot on a live Ubuntu, I used 18.04 but more recent should work

# if you have currently no EFI partition (maybe it was deleted,
# or you are migrating to a new drive):
# sudo gparted
# - create a FAT 32 partition of around 100 MB on the disk of your choice
# (in general the one that host the Ubuntu partition). If you plan to
# move or resize some paritions, anticipate that (for instance by
# creating the EFI partition at the end of the free space).
# - set the flag esp on this partition (the flag boot will also be selected)

# now assuming that the Ubuntu partition is `/dev/sda2` and the (possibly new) EFI partition is `/dev/sda1`
sudo apt install grub-efi
sudo mkdir /media/root && sudo mount /dev/sda2 /media/root
sudo mkdir /media/efi && sudo mount /dev/sda1 /media/efi
sudo grub-install --target=x86_64-efi /dev/sda --efi-directory=/media/efi --boot-directory=/media/root/boot

Это должно дать:

Установка для платформы x86_64-efi.

Установка завершена. Об ошибках не сообщалось.

Затем перезагрузитесь, и все готово. Возможно, вам придется указать в BIOS, какой диск использовать, или какой раздел EFI использовать, или какой двоичный файл EFI использовать.

Если вы создали новый раздел EFI, вам, возможно, придется добавить его в / etc / fstab , чтобы update-grub работал правильно.

Для получения дополнительной информации: https: // wiki.archlinux.org/index.php/Multiboot_USB_drive#Hybrid_UEFI_GPT_+_BIOS_GPT/MBR_boot

Самым простым для меня было использование этого небольшого инструмента (20 Мб), который позволит вам загрузить сломанную систему grub (я использовал Ventoy для загрузки инструмента):

https://www.supergrubdisk.org/category/download/supergrub2diskdownload/

И как только инструмент сделал свое волшебство и загрузил вашу систему linux, сделайте:

sudo grub-install /dev/nvme0n1
sudo update-grub

Только что использовал этот инструмент https://help.ubuntu.com/community/Boot-Repair в Ubuntu. Это был самый простой способ, и все происходило автоматически.

Что в первую очередь вызвало потерю меню Grub2?

Универсальный ответ 112 ( cl-netbox сентябрь 2016 г., декабрь 2020 г.) всегда должен работать, чтобы переустановить grub. . Лабиринт необходимых шагов не ответит на этот мучительный вопрос , который задает почти каждый.

Пример

Предположим, что рабочий Ubuntu установлен на gpt SSD , за которым год спустя была установлена ​​новая версия Ubuntu на вращающемся диске gpt . Загрузитесь после того, как новая установка потеряла меню grub2 SSD и вместо этого загружается на вращающийся диск.

Из любопытства иногда можно больше узнать о том, как работает grub2. Изучение примера происходит следующим образом. Предположим, что в дальнейшем вращающийся диск загружает Ubuntu.

Sudo mount the EFI partition of the SSD on /mnt 
Open a terminal on /mnt
cd to /mnt/EFI/ubuntu and open grub.cfg in a text editor like xed

Содержимое grub.cfg выглядит следующим образом:

search.fs_uuid 0caa0215-f19c-4cbf-8b27-1ffd0984bef8 root hd1,gpt12 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg**strong text**

Обратите внимание, что имя файла grub.cfg также используется grub2 в папке / boot / grub в Ubuntu ext4 раздел. Два файла имеют совершенно разное содержимое.

uuid = 0caa0215-f19c-4cbf-8b27-1ffd0984bef8 - ключ к раскрытию того, что произошло. В другом терминале проверьте вывод команды blkid , чтобы увидеть, имеет ли вращающийся диск указанный выше uuid.

Что в первую очередь вызвало потерю меню Grub2? Если uuid принадлежит вращающемуся диску, а не ssd, то новая установка ubuntu перезаписывает информацию в EFI раздел. Затем файл EFI ubuntu grub.cfg заставляет прошивку EFI обращаться к вращающемуся диску вместо ssd (медленнее, чем ssd, неправильное меню grub).

Ярлык ? Детали ответа 112 зависят от нескольких навыков волшебника, которыми еще не владеют новички. Возможен ли ярлык, например, изменение UUID на экране выше на правильный UUID? Grub2 использует раздел EFI vfat для загрузки ubuntu, целевой раздел для загрузки, заданный тремя пунктами, выделенными жирным шрифтом ниже. Редактирование трех элементов может восстановить загрузку ssd в примере. Но прямое редактирование может привести к тому, что система не загружается, что объясняет, почему ответ 112 - это инструмент, который нужно изучить, независимо от ярлыков что иногда работают . Если вы носите шляпу волшебника, то идея ярлыка - еще один инструмент.

search.fs_uuid 0caa0215-f19c-4cbf-8b27-1ffd0984bef8 root hd1 , gpt12