Установленная Ubuntu 17.04 от usb, но теперь не может загрузиться

У меня был тот же компьютер, за исключением 4 ГБ ОЗУ. У меня была такая же проблема с загрузкой EFI. Я бы не нашел загрузочное устройство найдено.

В моей системе сначала был раздел восстановления системы, а затем раздел EFI. Для меня было исправлено использование диска восстановления Windows для разбиения диска. Затем удалите все разделы, кроме первого (рекавери). Затем установка Ubuntu.
Моя система также загружалась только с устройства (без загрузки ОС), поэтому необходимо было создать путь к носителю по умолчанию. Скопируйте /EFI/ubuntu/shimx64.efi в / EFI / BOOT / и переименуйте его в BOOTx64.efi, сработало отлично.

Попробуйте создать раздел NTFS в начале диска и пометить его как восстановление системы. И раздел FAT32, помеченный как ESP. затем установка Ubuntu.

С одной оговоркой, сообщение об ошибке, о котором вы сообщаете, похоже, пришло от Шима (shimx64.efi), что означает, что компьютер запускает процесс загрузки. Предостережение заключается в следующем: вы сообщили следующее сообщение об ошибке:

Failed to open \EFI\BOOT\shimx.efi - Not Found

Это сообщение принимает форму сообщений от Шима; однако Шим запускает GRUB, и поэтому должен жаловаться, что не может найти grubx64.efi, а не shimx64.efi. Вы также говорите, что он жаловался на то, что не смог найти MokManager, что дополнительно поясняет, что это должно быть сообщение Shim - AFAIK, ни один EFI не ищет MokManager, а Shim делает. Поскольку это сообщение Шима, я предполагаю, что вы неправильно сообщили об этой детали. Если нет, то вы столкнулись с чем-то новым и странным, что может усложнить мой анализ ниже - но, возможно, это все еще применимо даже тогда ...

Выходные данные вашего Boot Repair показывают, что shimx64.efi и grubx64.efi присутствуют в EFI/ubuntu на ESP. В вашем каталоге EFI/BOOT есть файл bootx64.efi, но неясно, что это из одних только выводов Boot Repair. Однако, как указано в сообщении об ошибке EFI/BOOT, вполне вероятно, что EFI/BOOT является копией Shim и что этот двоичный файл работает. Если это так, и если в этом каталоге больше ничего не существует, то сообщение об ошибке имеет смысл, по крайней мере, если оно действительно ссылается на grubx64.efi.

Учитывая все это, вероятно, самое простое решение - скопировать EFI/ubuntu/grubx64.efi и EFI/ubuntu/grub.cfg в EFI/BOOT на ESP (/dev/sda1 в вашем случае). После того, как эти файлы скопированы, Шим должен иметь возможность запускать GRUB, хотя из EFI/BOOT, а не из EFI/ubuntu. Это должно быть довольно просто исправить. Это имеет тот недостаток, что будущие обновления GRUB и Shim не будут полностью установлены - или, если быть более точными, они будут установлены, но никогда не будут работать.

Еще один возможный вариант исправления предлагается из вашего вывода Boot Repair:

=================== efibootmgr -v
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0000,0002,0001,0003
Boot0000* ubuntu    VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0001* UEFI: IP4 Realtek PCIe FE Family Controller   PciRoot(0x0)/Pci(0x1c,0x2)/Pci(0x0,0x0)/MAC(f8a96315c2b0,0)/IPv4(0.0.0.0:0<->0.0.0.0:0,0,0)..BO
Boot0002* UEFI: IP6 Realtek PCIe FE Family Controller   PciRoot(0x0)/Pci(0x1c,0x2)/Pci(0x0,0x0)/MAC(f8a96315c2b0,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot0003* UEFI:  USB Flash Memory1.00   PciRoot(0x0)/Pci(0x14,0x0)/USB(2,0)..BO

Этот вывод требует некоторого опыта для анализа, но строка ubuntu странная. Обычно это должно выглядеть примерно так:

Boot0000* ubuntu    HD(2,GPT,6e49fcaf-d054-47c9-ba69-a668c5ee8192,0xc00,0x114000)/File(\EFI\ubuntu\shimx64.efi)

Детали, и особенно все шестнадцатеричные числа, могут отличаться, но обычно это будет запись HD(...), которая ссылается на EFI\ubuntu\shimx64.efi. Таким образом, вы можете попробовать это:

1. Загрузите аварийный диск.
2. Открыть окно терминала.
3. Тип sudo efibootmgr -c -l \\EFI\\ubuntu\\shimx64.efi -L ubuntu.
4. Введите sudo efibootmgr -v, чтобы просмотреть новый список порядка загрузки. Вы должны увидеть что-то вроде записи, которую я показал выше, и она должна быть первой в строке BootOrder.

Тем не менее, и установщик Ubuntu, и Boot Repair делают это в основном за кулисами, и ваша система все еще имеет эту проблему. Таким образом, может случиться так, что вы смотрите на ошибку, либо в прошивке вашего компьютера, либо в чем-то в Ubuntu (вероятно, efibootmgr, но, возможно, ядро ​​или что-то еще). Известно, что некоторые Toshibas имеют нестабильные EFI, поэтому ошибка в вашей прошивке вполне возможна. (Возможно, стоит попробовать обновить прошивку до последней версии, если она еще не установлена.)

Еще один подход заключается в использовании fallback.efi (он же fbx64.efi), который вы устанавливаете в EFI/BOOT. ] вместе с файлом с именем BOOT.CSV в каталоге EFI/ubuntu. Это немного утомительно для настройки, хотя. См. на этой странице документации по rEFInd для получения подробной информации о том, как это сделать с помощью rEFInd, но вам нужно немного подправить детали, чтобы заставить его работать с Ubuntu. Я не вижу никаких признаков fallback.efi или fbx64.efi в выводе Boot Repair, поэтому он может быть не установлен в вашей системе.