Я хотел бы поработать над sdb3 :

sudo fdisk -l

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
16 heads, 63 sectors/track, 1938021 cylinders, total 1953525168 sectors 
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x2052474d

   Device Boot      Start         End      Blocks   Id  System 
   /dev/sdb1              63   549971855   274985896+   7  HPFS/NTFS/exFAT 
   Partition 1 does not start on physical sector boundary.
   /dev/sdb2       549971856  1470063167   460045656    7  HPFS/NTFS/exFAT 
   /dev/sdb3   *  1470063168  1810175471   170056152    7  HPFS/NTFS/exFAT

Однако оба инструмента для создания разделов, которые я пробовал (gParted и KDE Partition Manager), не могут найти этот раздел:

Скриншот

Как я попал в эту ситуацию

Я делал операцию изменения размера раздела из KDE Part Manager. Через 10 секунд я вспомнил, что я также хотел, чтобы этот раздел был перенесен на другой диск. Нажмите Отмена, спустя 2 часа KDE Partition Manager все еще пытался отменить операцию. Я принудительно остановил его, затем с помощью Testdisk я смог восстановить 3 раздела sdb . Зашел в Windows XP и успешно запустил chkdsk /f на всех 3 NTFS-разделах sdb . Прямо сейчас они могут быть смонтированы и использованы в Linux и Windows, видимо, нормально.

Как мне сделать так, чтобы 3 раздела снова появлялись в программном обеспечении для создания разделов?

редактировать 1

kellogs-PC kellogs # lsblk /dev/sdb
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sdb      8:16   0 931,5G  0 disk 
├─sdb1   8:17   0 262,3G  0 part /media/kellogs/downloads 2
├─sdb2   8:18   0 438,8G  0 part /media/kellogs/para backup
└─sdb3   8:19   0 162,2G  0 part /media/kellogs/Win8

edit2

Ответ Камиля @ https://superuser.com/a/1225632/60373 не помог мне.

Забыл упомянуть о важном. Эта машина имеет 3 ОС

/dev/sda - Windows XP, Linux /dev/sdb - Windows 8.1

/dev/sda1 - это раздел Win XP, очевидно, с загрузчиком Win8: 

kellogs-PC kellogs # update-grub
Generating grub configuration file ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Found linux image: /boot/vmlinuz-3.13.0-24-generic
Found initrd image: /boot/initrd.img-3.13.0-24-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
  No volume groups found
Found Windows 8 (loader) on /dev/sda1
done

Это выглядит хорошо для меня, но ... Windows 8.1 не загружается. Опять же, раздел Win8 (он же sdb3) прекрасно монтируется из Win XP и Linux. Поиск в интернете кода ошибки "0xc000000e" не дает мне четкого ответа на мою проблему.

|источник

2 ответа2

1

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

(Редактирование заканчивается здесь, оригинальный ответ ниже).

Ваша ситуация может быть похожа на это, но несколько отличается. Я признаю, что не могу точно объяснить, как описанные вами действия могли быть причиной этого, тем не менее я думаю, что моя следующая теория правдоподобна

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

У вас есть действительная таблица разделов, и большинство программ должны обнаруживать ее (как это делает Windows). Тем не менее KDE Partition Manager считает, что ваш диск является суперфлоппи с файловой системой NTFS на всем устройстве. Похоже, что он пытается сначала обнаружить суперфлоппи файловую систему и, если это удастся, он пропускает дополнительные тесты. Я предполагаю, что некоторые части /dev/sdb MBR вводят в заблуждение ваш менеджер разделов.

Если вы не загружаетесь из /dev/sdb (т. Е. Код начальной загрузки там полностью не используется, вы загружаетесь только из /dev/sda и точно), вы можете записать нули в область кода начальной загрузки MBR /dev/sdb . В моем ответе на связанный вопрос есть диаграмма, которая сравнивает MBR с NTFS VBR:

    MBR    │ byte offset │  NTFS VBR
           │  hex / dec  │
───────────┼─────────────┼─────────────
           │ 0x000 / 000 │ mainly NTFS
 bootstrap │      …      │  metadata
   code    ├─────────────┼─────────────
           │ 0x054 / 084 │
           │      …      │  bootstrap
───────────┼─────────────┤    code
 partition │ 0x1BE / 446 │
   table   │      …      │
───────────┼─────────────┼─────────────
   0x55    │ 0x1FE / 510 │    0x55
   0xAA    │ 0x1FF / 511 │    0xAA
───────────┴─────────────┴─────────────

Этого должно быть достаточно для записи нулей в первые 84 байта диска, чтобы любой инструмент не мог найти подпись NTFS на (предполагаемой) суперфлоппи-диске.

В Linux:

# making backup of the entire MBR just in case
dd if=/dev/sdb of=~/sdb.mbr.backup bs=512 count=1

# zeroing alleged NTFS metadata, use 'bs=446' to zero the entire bootstrap code of MBR
dd if=/dev/zero of=/dev/sdb bs=84 count=1
sync

Затем (пере) запустите KDE Partition Manager и посмотрите, помогло ли это. Если этого не произошло, было бы разумно отменить изменение на тот случай, если вы допустили ошибку, считая, что загрузочный код в /dev/sdb не имеет значения.

# reverting
dd if=~/sdb.mbr.backup of=/dev/sdb
sync
|источник
1

Я думаю, что таблица разделов MBR сломана. Хотя fdisk может распознать разделы, сам parted застрял. Как KDE Partition Manager, так и GParted полагаются на libparted для обнаружения разделов, поэтому отображают неверную информацию.

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

Вы можете проверить мою попытку здесь: https://stikonas.eu/files/sdb.mbr.new

Также обратите внимание, что ваши разделы не выровнены по границам MiB. Вероятно, не имеет большого значения для старых жестких дисков, но это будет иметь значение для SSD.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .