(и добро пожаловать в новую ветку «давайте ненавидеть Microsoft»)
Ноутбук Asus с SSD-накопителем на 500 ГБ, с разделом Windows NTFS на 150 ГБ и разделом Ubuntu 20.04 на 350 ГБ (почти уверен, что это ext4). Двойная загрузка с приоритетом GRUB/Ubuntu над Windows. Важные данные в разделе Ubuntu, а не в разделе Windows.
После 1-часового обновления Windows без каких-либо происшествий (без отключения электроэнергии или чего-то еще) компьютер загружается в командную строку GRUB («grub>», а не «grub Rescue>»). Что еще более раздражает, это также происходит, когда подключен живой USB-ключ (18.04, проверено на другом ноутбуке). При использовании «выход» в приглашении Windows загружается правильно.
Это был обзор, а теперь подробности.С живым USB-ключом сначала быстро появляется экран, который читает
Не удалось открыть EFI\BOOT\grubx64.efi - не найдено
Не удалось загрузить образ EFI\BOOT\grubx64.efi - не найдено
start_image() вернул не найдено
затем через секунду появляется приглашение "grub>"
В приглашении «grub>» ls возвращает
(proc) (hd0) (hd0,msdos1) (hd1) (hd2) (hd2,gpt6) (hd2,gpt5) (hd2,gpt4) (hd2,gpt3) (hd2,gpt2) (hd2,gpt1)
ls (прок) возвращает
Устройство proc: Тип файловой системы procfs - Размер сектора 512B - Общий размер 0KiB
Живой USB - hd0, и, как и ожидалось, ls (hd0,1) возвращает
Раздел hd0, msdos1: Тип файловой системы fat — метка «Ubuntu 18_0», UUID 864E-2850 — начало раздела с 1024 КБ — общий размер 15150080 КБ
я не знаю, что такое hd1; в компьютере ранее был жесткий диск, который был заменен на твердотельный накопитель несколько лет назад, возможно, это следы этого. ls (hd1) возвращает
Устройство hd1: известная файловая система не обнаружена — размер сектора 2048 байт — общий размер 514 КБ
hd2 - это настоящий жесткий диск. ls (hd2) описывает устройство
Устройство hd2: известная файловая система не обнаружена — размер сектора 512 байт — общий размер 488386584 КБ
ls (hd2,xx) для xx= от 6 до 1 описывает разделы
Раздел hd2,6: не обнаружена известная файловая система - начало раздела с 14684736 КБ - общий размер 341580800 КБ
Раздел hd2,5: Тип файловой системы ntfs, UUID84127C1A127C1380 — начало раздела 146205696 КБ — общий размер 598016 КБ
Раздел hd2,4: Тип файловой системы ntfs, UUID22FE5C86FE5C53DF — начало раздела с 661504 КБ — общий размер 145543516 КБ
Раздел hd2,3: Неизвестная файловая система не обнаружена - Начало раздела с 645120 КБ - Общий размер 16384 КБ
Раздел hd2,2: Тип файловой системы fat, UUID 0057-5017 - Начало раздела 542720 КБ - Общий размер 102400 КБ
Раздел hd2,1: Тип файловой системы ntfs, метка «Rcupration» — начало раздела с 1024 КБ — общий размер 541696 КБ
hd2,6 кажется разделом Ubuntu на 350 ГБ. Насколько я могу судить, он не должен говорить «Известная файловая система не обнаружена», на другом ноутбуке структура ext правильно определяется командой grub ls.
hd2,4 кажется разделом Windows.
У hd2,1 странное имя, потому что акценты во французском языке не отображаются.
Когда я пытаюсь загрузиться с раздела Linux, используя
установить префикс=(hd2,gpt6)/boot/grub
установить корень = (hd2, gpt6)
инсмод нормальный
нормальный
ничего не происходит (я полагаю, это ожидается, если он не может определить файловую систему). Когда я пытаюсь загрузить ключ, используя
установить префикс=(hd0,1)/boot/grub
установить корень = (hd0,1)
инсмод нормальный
нормальный
Я получаю живое приглашение USB, но затем, когда я выбираю «Попробовать Ubuntu без установки» или любой другой вариант, я получаю
ошибка: /casper/vmlinuz имеет неверную подпись.
ошибка: сначала нужно загрузить ядро.
Нажмите любую клавишу чтобы продолжить...
затем вернитесь в меню живых ключей, застрявшее в цикле. Это немного странно, потому что ранее он предупреждал меня, что grubx64.efi не найден, и из того, что я понял (Обновление Windows 8 сломало мой GRUB) то что он не запросил shimx64.efi значит что Secure Boot отключен, но тогда что это за сигнатура? В любом случае, отсутствие правильной загрузки на живом USB-ключе не позволяет мне использовать обычные инструменты восстановления.
Теперь я все еще могу набрать «выход», и тогда Windows загружается нормально. В Windows я попытался загрузить Testdisk. Testdisk правильно определяет раздел Linux следующим образом:
Начальный и конечный размер раздела в секторах
1 P Windows Recovery Env 2048 1085439 1083392 [Раздел основных данных]
2 P Система EFI 1085440 1290239 204800 [системный раздел EFI]
Нет маркеров FAT, NTFS, ext2, JFS, Reiser, cramfs или XFS.
3 P MS зарезервировано 1290240 1323007 32768 [зарезервированный раздел Microsoft]
3 P MS зарезервировано 1290240 1323007 32768 [зарезервированный раздел Microsoft]
4 P MS Data 1323008 292410039 291087032 [Основной раздел данных]
5 P Окно восстановления Windows 292411392 293607423 1196032
6 P файловая система Linux. данные 293609472 976771071 683161600
Однако, когда я захожу в этот раздел (с Advanced Utils) и пытаюсь перечислить файлы, я получаю
Поддержка этой файловой системы не была включена во время компиляции
Только винда загружается нормально, поэтому другой версии под рукой нет, чтобы попробовать поработать на разделе ext4. Кроме того, я просто скачал .exe и не стал его компилировать, так как у меня недостаточно опыта для этого.
Некоторые темы на форумах Testdisk намекают, что когда раздел указан дважды как 3 выше, это означает, что есть проблема.
Так...
Моя главная цель — получить доступ к файлам раздела Ubuntu, хотя восстановить все, как было вчера, было бы очень неплохо. Я вижу несколько возможных путей:
- каким-то образом заставить GRUB загрузить раздел Ubuntu, прочитав его как ext4.
- заставить GRUB правильно загрузить живой USB-ключ (с этой подписью), а затем использовать инструменты восстановления оттуда
- используйте Testdisk (в Windows) для восстановления раздела ext4, чтобы GRUB мог его правильно увидеть, или другой аналогичный инструмент в Windows
- используйте любой инструмент, чтобы прочитать раздел Ubuntu как ext4, извлечь файлы и выбросить компьютер из окна.
У кого-нибудь есть идея?
В любом случае, спасибо за чтение!
