LINUX.ORG.RU

Перестал грузиться линукс с диска с GPT

 


0

1

История слегка длинная, пока сижу в шоке, искренне надеюсь на помощь.

  1. На ПК до недавнего времени работал raid из двух HDD.
  2. Дня 4 назад я купил SSD, подключил его, выбрал загрузку с него и установил на него линукс Manjaro, выбрав в качестве способа разметки GPT и разбив диск на 3 раздела (root, home, data). Всё работало ОК.
  3. В связи с тем, что raid больше не нужен, зашёл в «биос», «удалил» raid. Убедился, что Manjaro с SSD по-прежнему грузится (он к raid никакого отношения не имел)
  4. Вытащил один из двух HDD из системного блока, нормально загрузился в Manjaro.
  5. Решил на оставшийся HDD установить WinXP (зачем - не суть). Причём, чтобы грузился WinХР независимо от SSD, чтобы SSD отключить и загружаться с HDD в WinXP. Но физически отключать пока SSD не стал, просто поменял в «биос» приоритет загрузки жестких дисков. В редакторе разделов в Manjaro сделал пару разделов на HDD без файловой системы.
  6. Стал устанавливать WinXP с оптического диска. Вылетел BSOD. До разметки дисков дело не дошло, так что, надеюсь, данные на SSD остались нетронутыми.
  7. С оптического диска запустил Partition Magic и увидел и SSD и HDD без разметок с метками «BAD» или что-то там. Решил, что Partition Magic чего-то не понимает и решил разметить HDD с его помощью.
  8. SSD физически отключил, чтобы не поломать чего-нибудь на нём по ошибке. Попытался разметить HDD 2 разными программами, ничего не вышло. Решил разметить HDD из под Manjaro повторно, с созданием файловых систем на нём.
  9. Подключил SSD, стал с него грузиться - и тут увидел «grub rescue», не грузится с SSD ничего. Отключил HDD и оптический привод во избежание ошибок, но Manjaro почему-то не грузится.
  10. Загрузился сейчас с флешки с тем же Manjaro. В /dev/disk/ видно SSD, но в редакторе разделов нет ни одного жёсткого почему-то (может из-за GPT)

Сижу пока в шоке, стараюсь не делать резких движений и думаю, как не потерять данные с SSD - там вообще все мои данные. Прошу разумных советов. UPDATE. Выполнив sudo fdisk -l увидел: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Чем такую портянку писать, лучше по пунктам:

  • что в биосе с загрузкой, UEFI или «old school»;
  • загрузиться с флешки/сидюка при подключенном ssd и показать его разметку.
vvn_black ★★★★★ ()
Ответ на: комментарий от Evenik

[code] [manjaro@manjaro ~]$ sudo gdisk -l /dev/sda GPT fdisk (gdisk) version 1.0.5

Caution: invalid main GPT header, but valid backup; regenerating main header from backup!

Warning: Invalid CRC on main header data; loaded backup partition table. Warning! Main and backup partition tables differ! Use the ‘c’ and ‘e’ options on the recovery & transformation menu to examine the two tables.

Warning! Main partition table CRC mismatch! Loaded backup partition table instead of main partition table!

Warning! One or more CRCs don’t match. You should repair the disk! Main header: ERROR Backup header: OK Main partition table: ERROR Backup partition table: OK

Partition table scan: MBR: protective BSD: not present APM: not present GPT: damaged


Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk verification and recovery are STRONGLY recommended.


Disk /dev/sda: 937703088 sectors, 447.1 GiB Model: TOSHIBA-TR200
Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): 962F08C4-77D0-054D-B0F0-94D7CDBAF7FA Partition table holds up to 128 entries Main partition table begins at sector 2016 and ends at sector 2047 First usable sector is 2048, last usable sector is 937703054 Partitions will be aligned on 2048-sector boundaries Total free space is 5103 sectors (2.5 MiB)

Number Start (sector) End (sector) Size Code Name 1 2048 83888127 40.0 GiB 8300
2 83888128 104859647 10.0 GiB 8300
3 104859648 937697951 397.1 GiB 0700 [/code]

PeleWin ()
Ответ на: комментарий от PeleWin

Снимай образ ssd на винт и давай, вперёд, эксперименттировать:

Warning: Invalid CRC on main header data; loaded backup partition table. Warning! Main and backup partition tables differ! Use the ‘c’ and ‘e’ options on the recovery & transformation menu to examine the two tables.

Или сделать бекап данных и заново переразметить.

vvn_black ★★★★★ ()
Последнее исправление: vvn_black (всего исправлений: 1)
Ответ на: комментарий от PeleWin

Если показанная таблица разделов соответствует ожиданиям, то:

$ sudo gdisk /dev/sda

gdisk shell will open now. Enter 'r' to select recovery option. From the recovery option, enter 'b', to recover GPT header from secondary (backup), and then enter 'c' to recover GPT partition table from secondary (backup). Then select 'v', and then 'w' to verify, and write to disk.

https://lihashgnis.blogspot.com/2016/07/recovering-from-corrupted-gpt-partiti...

Evenik ()
Последнее исправление: Evenik (всего исправлений: 5)
Ответ на: комментарий от vvn_black

Спасибо, так и сделаю. Всем спасибо за участие, пойду снимать образ и экспериментировать, раньше утра не появлюсь. Ещё раз всем спасибо!

PeleWin ()
Ответ на: комментарий от Evenik

Именно так и сделал, всё получилось! Большое всем спасибо! Тему закрываю.

PeleWin ()

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

amd_amd ★★★★ ()
Ответ на: комментарий от amd_amd

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

Здесь помог именно стандарт GPT с его запасной таблицей разделов.

Evenik ()
Ответ на: комментарий от anonymous

Можно подумать что икспи

можно подумать - что угодно! лично я думаю - что винда и линукс на одной машине это идиотизм, но для тех у кого «а на винде все работает» это пожалуй единственный выход...

amd_amd ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.