Ubuntu загрузочный менеджер eep отсутствует (краткое описание загрузки)

На самом деле сервер Ubuntu совпадает с Ubuntu Desktop с некоторыми изменениями в предустановленных встроенных пакетах и ​​некоторой конфигурацией для серверных инструментов

проверьте эту ссылку и другую ссылку на то, что нового для ubuntu Server в любом случае.

0
задан 30 June 2017 в 01:37

2 ответа

Файлы, которые отсутствуют в сообщении, присутствуют в соответствии с выходом Boot Repair. Этот тип несогласованности может возникнуть в результате использования FAT16 или низкоуровневого FAT32 на некоторых компьютерах с не очень большими драйверами файловой системы FAT. Большинство таких EFI довольно старые (с 2012 года или раньше, по предположению). Однако чаще всего причиной является отказ отключить Fast Startup и Hibernate в Windows. Когда они активны, эти функции Windows вызывают повреждение файловой системы на разделяемых разделах, включая системный раздел EFI (ESP), где находятся загрузчики. Отключение этих функций (как описано в предыдущих ссылках) и перезагрузка Windows несколько раз могут решить проблему. Обратите внимание, что функция быстрого запуска Windows не совпадает с функцией с похожим именем во многих EFI; функция EFI использует ярлыки при инициализации аппаратного обеспечения, но не влияет на то, как Windows обрабатывает свои операции выключения (что делает Fast Startup и Hibernate, они включают операции выключения в операции приостановки на диск, что ускоряет процесс загрузки за счет что делает конфигурации с двумя загрузками намного более рискованными).

Если проблема не устранена, вам может потребоваться принять более радикальные корректирующие меры. В качестве первого шага я рекомендую вам создать резервную копию ESP (/dev/sda2 в вашем случае). Вы можете сделать это в Windows или в Ubuntu, но я описываю только процедуры Ubuntu, потому что я больше знаком с ними, и я хочу свести к минимуму беспорядок в этом ответе. Вы можете загрузиться в Ubuntu, используя мой Fast Startup на USB-накопителе или CD-R для загрузки вашей существующей установки или загрузки установщика Ubuntu в режиме «попробуйте до установки». В первом случае ESP должен быть установлен на /boot/efi; в последнем случае вам необходимо установить ESP вручную. Однако вы делаете это, резервное копирование на уровне файлов (с использованием cp, zip, tar или аналогичных инструментов на уровне файлов) должно быть адекватным - но убедитесь, что файлы, отмеченные при неудаче загрузки, будут скопированы.

При резервном копировании попытка восстановления первого уровня должна выполнить проверку и восстановление файловой системы. Вы сделаете это с помощью dosfsck в Ubuntu. Файловая система должна быть отключена, и вы должны передать параметр -a, как в sudo dosfsck -a /dev/sda2. Это не устраняет проблему, но в редких случаях это может нанести дополнительный урон, что потребует дальнейшего; и если это не сработает, вам, возможно, придется пойти дальше ...

Если ремонт файловой системы не работает, то следующая вещь, которую нужно попробовать, - создать новую файловую систему и восстановить резервные копии к нему. В Ubuntu раздел должен быть размонтирован, и вы должны использовать sudo mkdosfs -F32 /dev/sda2 для создания файловой системы. (Будьте осторожны с этой командой: если вы укажете неправильное имя файла устройства, вы можете уничтожить установку Windows или Ubuntu!). После восстановления файловой системы вы затем восстановите резервную копию, созданную вами ранее. Обратите внимание: если вы это сделаете, и вы сможете отредактировать /etc/fstab в Ubuntu: найдите строку /boot/efi и измените значение UUID= для новой файловой системы. (Вы можете узнать это значение, набрав sudo blkid /dev/sda2.) Если вы не внесете это изменение, ESP не будет автоматически смонтирован, а это значит, что будущие обновления GRUB могут быть недоступны.

Использование Boot Repair, как предположил oldfred, - это другой подход; но если вы сделаете это без предварительного отключения функций быстрого запуска Windows и Hibernate, проблема может повториться. Хуже того, любая попытка записать в ESP из Ubuntu до того, как эти функции отключены, может привести к дальнейшему повреждению файловой системы, что может вызвать еще более серьезные проблемы (возможно, new будет загружаться, например). Если в файловой системе уже есть серьезные проблемы, использование Boot Repair может ухудшить ситуацию. Таким образом, ни один подход к решению проблемы не является абсолютно безрисковым и легким. IMHO, вероятно, лучше начать с отключения Fast Startup и Hibernate (эта часть относительно безопасна) и проверка файловой системы (также относительно безопасная). Если этого недостаточно, вам придется решить, какие риски предпринять - резервное копирование и повторное создание ESP или с помощью Boot Repair. Наличие резервной копии ваших пользовательских файлов - хорошая идея; хотя шансы повредить их довольно тонкие, последствия, если вы это сделаете, очевидно, будут разрушительными.

0
ответ дан 18 July 2018 в 10:55

Файлы, которые отсутствуют в сообщении, присутствуют в соответствии с выходом Boot Repair. Этот тип несогласованности может возникнуть в результате использования FAT16 или низкоуровневого FAT32 на некоторых компьютерах с не очень большими драйверами файловой системы FAT. Большинство таких EFI довольно старые (с 2012 года или раньше, по предположению). Однако чаще всего причиной является отказ отключить Fast Startup и Hibernate в Windows. Когда они активны, эти функции Windows вызывают повреждение файловой системы на разделяемых разделах, включая системный раздел EFI (ESP), где находятся загрузчики. Отключение этих функций (как описано в предыдущих ссылках) и перезагрузка Windows несколько раз могут решить проблему. Обратите внимание, что функция быстрого запуска Windows не совпадает с функцией с похожим именем во многих EFI; функция EFI использует ярлыки при инициализации аппаратного обеспечения, но не влияет на то, как Windows обрабатывает свои операции выключения (что делает Fast Startup и Hibernate, они включают операции выключения в операции приостановки на диск, что ускоряет процесс загрузки за счет что делает конфигурации с двумя загрузками намного более рискованными).

Если проблема не устранена, вам может потребоваться принять более радикальные корректирующие меры. В качестве первого шага я рекомендую вам создать резервную копию ESP (/dev/sda2 в вашем случае). Вы можете сделать это в Windows или в Ubuntu, но я описываю только процедуры Ubuntu, потому что я больше знаком с ними, и я хочу свести к минимуму беспорядок в этом ответе. Вы можете загрузиться в Ubuntu, используя мой Fast Startup на USB-накопителе или CD-R для загрузки вашей существующей установки или загрузки установщика Ubuntu в режиме «попробуйте до установки». В первом случае ESP должен быть установлен на /boot/efi; в последнем случае вам необходимо установить ESP вручную. Однако вы делаете это, резервное копирование на уровне файлов (с использованием cp, zip, tar или аналогичных инструментов на уровне файлов) должно быть адекватным - но убедитесь, что файлы, отмеченные при неудаче загрузки, будут скопированы.

При резервном копировании попытка восстановления первого уровня должна выполнить проверку и восстановление файловой системы. Вы сделаете это с помощью dosfsck в Ubuntu. Файловая система должна быть отключена, и вы должны передать параметр -a, как в sudo dosfsck -a /dev/sda2. Это не устраняет проблему, но в редких случаях это может нанести дополнительный урон, что потребует дальнейшего; и если это не сработает, вам, возможно, придется пойти дальше ...

Если ремонт файловой системы не работает, то следующая вещь, которую нужно попробовать, - создать новую файловую систему и восстановить резервные копии к нему. В Ubuntu раздел должен быть размонтирован, и вы должны использовать sudo mkdosfs -F32 /dev/sda2 для создания файловой системы. (Будьте осторожны с этой командой: если вы укажете неправильное имя файла устройства, вы можете уничтожить установку Windows или Ubuntu!). После восстановления файловой системы вы затем восстановите резервную копию, созданную вами ранее. Обратите внимание: если вы это сделаете, и вы сможете отредактировать /etc/fstab в Ubuntu: найдите строку /boot/efi и измените значение UUID= для новой файловой системы. (Вы можете узнать это значение, набрав sudo blkid /dev/sda2.) Если вы не внесете это изменение, ESP не будет автоматически смонтирован, а это значит, что будущие обновления GRUB могут быть недоступны.

Использование Boot Repair, как предположил oldfred, - это другой подход; но если вы сделаете это без предварительного отключения функций быстрого запуска Windows и Hibernate, проблема может повториться. Хуже того, любая попытка записать в ESP из Ubuntu до того, как эти функции отключены, может привести к дальнейшему повреждению файловой системы, что может вызвать еще более серьезные проблемы (возможно, new будет загружаться, например). Если в файловой системе уже есть серьезные проблемы, использование Boot Repair может ухудшить ситуацию. Таким образом, ни один подход к решению проблемы не является абсолютно безрисковым и легким. IMHO, вероятно, лучше начать с отключения Fast Startup и Hibernate (эта часть относительно безопасна) и проверка файловой системы (также относительно безопасная). Если этого недостаточно, вам придется решить, какие риски предпринять - резервное копирование и повторное создание ESP или с помощью Boot Repair. Наличие резервной копии ваших пользовательских файлов - хорошая идея; хотя шансы повредить их довольно тонкие, последствия, если вы это сделаете, очевидно, будут разрушительными.

0
ответ дан 24 July 2018 в 19:41
  • 1
    Большое вам спасибо, я забыл добавить этот комментарий. Я закончил переустановку всей системы и исправил ее. – sihyeondev 19 July 2017 в 19:46

Другие вопросы по тегам:

Похожие вопросы: