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

773
user206468

Сегодня я установил новый жесткий диск на свой домашний сервер, перешел на форматирование его в 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 более точна.

0

1 ответ на вопрос

0
user206468

I finally had a chance today to take a good whack at this problem, and fortunately the solution was (mostly) more straightforward than I was worried about.

What helped me along was a little more learning about how my distro (Debian) sets up disk partitions in a guided installation (http://www.linuxbsdos.com/2011/02/15/debian-6-installation-and-disk-partitioning-guide/), and about how logical partitions are created and specified on the disk (http://tldp.org/HOWTO/Partition/fdisk_partitioning.html#mixed).

After reading the notes there, and re-checking, I went back into fdisk and:

  • Rewrote the MBR (o) to start over.
  • Created (n) a primary partition '1' with the "sdh1" sectors noted from gdisk's output (2048 - 119883775).
  • Created (n) an extended partition '2' starting from the first available sector and spanning the rest of the disk (119883776 - ...).
  • Created (n) a logical partition '5' with the "sdh5" sectors noted from gdisk's output (119885824 - 125044735).
  • Changed the type (t) on partition '5' to Swap (type code '82').
  • Toggled the bootable flag (a) on "sdh1".
  • Wrote my changes (w) and exited.

I rebooted to test this partition table out, and the system didn't boot. So from here I had to unplug the disk and mount it on another PC. But luckily, all I had forgotten to do was:

  • Re-install grub to the (now-reformatted) MBR. Once the disk was mounted in my other PC, I used grub-install --root-directory=/path/to/mount/point /dev/sdX (where sdX was the device file for the mounted disk on my other PC).
    • If I had done this before rebooting the machine, I imagine it would have been grub-install --root-directory=/ /dev/sdh.

The grub configuration on the disk was still fine, so reinstalling grub itself was all that was necessary. After plugging the disk back in and starting up, everything seems to be working perfectly so far.

One important lesson I took away from this was that /sys/block data for extended partitions is a bit misleading. The /sys/block/.../size info for "sdh2" only claimed 2 blocks, which excluded the real size of the partition, necessary to fit "sdh5" (my logical/swap partition) inside it.

EDIT For good measure, the current fdisk -l output on my disk (which, after rebooting, has now labeled itself "sdi" instead of "sdh" as before) is:

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

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