Перезаписал таблицу разделов загрузочного диска с помощью gdisk; как восстановить?

Question

Сегодня я установил новый жесткий диск на свой домашний сервер, перешел на форматирование его в gdisk (размером более 2 ТБ), установил изменения и записал их. Затем я заметил, что выбрал не тот диск, фактически я просто переписал таблицу разделов на своем загрузочном диске.

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

Можно ли как-нибудь восстановить старую таблицу разделов или хотя бы ее достаточно для безопасной перезагрузки?

У меня есть вывод 'p' от gdisk, до того как я переписал таблицу:

Command (? for help): p
Disk /dev/sdh: 125045424 sectors, 59.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): D0127C61-1349-42D1-A03F-46F604F3DD6C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 125045390
Partitions will be aligned on 2048-sector boundaries
Total free space is 4717 sectors (2.3 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       119883775   57.2 GiB    8300  Linux filesystem
   5       119885824       125044735   2.5 GiB     8200  Linux swap

Некоторые осложнения:

• Диск ранее был разбит на разделы в MBR, и, не проверяя наверняка, я не думаю, что этот конкретный ПК поддерживает UEFI/ загрузку из GPT.

• Я не уверен, что эта распечатка включает в себя всю информацию, необходимую для восстановления таблицы разделов. Возможно ли, что некоторые разделы спрятаны здесь? Или эта другая важная информация будет отсутствовать? Я знаю, например, что, поскольку gdisk/ GPT не имеет флага "загрузочного", эта распечатка не включает его.

• Я уже пытался записать эти разделы обратно с помощью fdisk, но я не могу понять, как получить fdisk для создания раздела с номером 5. Я полагаю, что если мой раздел подкачки "переместится" из sdh5 в sdh2, это не будет волшебным образом работать.

Я обнаружил похожую проблему, Recover Partition-Table, которая все еще присутствует в работающей системе, в отношении перезаписи таблицы разделов с помощью dd . Но в моем случае, поскольку я использовал gdisk (+ fdisk) для написания новой таблицы, я не уверен, что информация в /sys /block более точна.

Answer 1

Сегодня у меня наконец-то появился шанс удачно решить эту проблему, и, к счастью, решение было (в основном) более простым, чем я беспокоился.

В этом мне помогло немного больше узнать о том, как мой дистрибутив (Debian) настраивает разделы диска в управляемой установке (http://www.linuxbsdos.com/2011/02/15/debian-6-installation-and-disk -partitioning-guide/) и о том, как логические разделы создаются и указываются на диске (http://tldp.org/HOWTO/Partition/fdisk_partitioning.html#mixed).

Прочитав там заметки и перепроверив, я вернулся в fdisk и:

• Переписал MBR (o), чтобы начать сначала.
• Создано n p rimary раздел "1" с "sdh1" секторов отметили выход из Gdisk (в 2048 - 119883775).
• Создано n e Xtended раздел "2" , начиная с первого доступного сектора и охватывает остальную часть диска (119883776 - ...).
• Создано n l ogical раздел "5" с "sdh5" секторов отметили выход из Gdisk (в 119885824 - 125044735).
• Изменил тип (t) на разделе "5" на "Поменять местами" (код типа "82").
• Переключил флаг загрузки (a) на "sdh1".
• Написал мои изменения (w) и вышел.

Я перезагрузился, чтобы проверить эту таблицу разделов, и система не загрузилась. Отсюда мне пришлось отключить диск и смонтировать его на другом ПК. Но, к счастью, все, что я забыл сделать, это:

• Переустановите grub в (теперь переформатированный) MBR. После того, как диск был смонтирован на моем другом ПК, я использовал grub-install --root-directory=/path/to/mount/point /dev/sdX (где sdX был файлом устройства для смонтированного диска на моем другом ПК).
  • Если бы я сделал это до перезагрузки компьютера, я думаю, что это был бы grub-install --root-directory=/ /dev/sdh .

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

Один важный урок, который я извлек из этого, заключался в том, что данные /sys /block для расширенных разделов немного вводят в заблуждение. Информация /sys/block/.../size для "sdh2" требует только 2 блоков, которые исключают реальный размер раздела, необходимый для размещения внутри него "sdh5" (мой логический раздел / раздел подкачки).

РЕДАКТИРОВАТЬ Для удобства измерения текущий вывод fdisk -l на моем диске (который после перезагрузки теперь помечен как "sdi" вместо "sdh", как раньше):

Disk /dev/sdi: 64.0 GB, 64023257088 bytes
255 heads, 63 sectors/track, 7783 cylinders, total 125045424 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: <...>

   Device Boot      Start         End      Blocks   Id  System
/dev/sdi1   *        2048   119883775    59940864   83  Linux
/dev/sdi2       119883776   125045423     2580824    5  Extended
/dev/sdi5       119885824   125044735     2579456   82  Linux swap / Solaris