fdisk жалуется: «Резервная таблица GPT повреждена, но основная таблица в порядке, поэтому она будет использована».

fdisk жалуется: «Резервная таблица GPT повреждена, но основная таблица в порядке, поэтому она будет использована».

Я недавно купил дваWestern Digital(ВД)EasystoreВнешние USB-накопители емкостью 8 ТБ длячушьих и используйте WD RedНАНвнутренние диски в моем компьютере (Арч Линукс). Первым оказался диск WD White Label (WD80EMAZ-00WJTA0), а вторым действительно оказался Red (WD80EFAX-68LHPN0).

Я установил White, и все, казалось, было в порядке. Я скопировал около 5 ТБ данных без проблем, но позже я заметил сообщение оГПТошибка при использованииGPartedна другом диске, над которым я работал. Мои данные, похоже, доступны, поэтому я пока ничего не сделал.

Сегодня я установил красный диск, и я получаю точно такую ​​же ошибку на этом диске, как и до любого разбиения на разделы или форматирования. Я искал решения и думаю, что это как-то связано с наличиемохраняемая территория(HPA), но я не знаю, как это проверить наверняка, или что делать, если это так. Можно ли это исправить, сохранив мои данные на белом диске? Я могу поэкспериментировать на красном диске, но я не уверен, что попробовать.

sudo gdisk /dev/sdb

Выход:

GPT fdisk (gdisk) version 1.0.3

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

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.
****************************************************************************

Command (? for help): p
Disk /dev/sdb: 15628053168 sectors, 7.3 TiB
Model: WDC WD80EMAZ-00W
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 6837F2B2-3A65-4260-B87E-B4682BAEE5FF
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 15628052446
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048     15628050431   7.3 TiB     0700  WD_8TB

Command (? for help): v

Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

Identified 1 problems!

и..

sudo hdparm -N /dev/sdb

Выход:

/dev/sdb:
max sectors   = 15628053168/15628053168, HPA is disabled

решение1

Ваш hdparmвывод показывает, что HPAнеполноценный,так что проблема не в этом.

Наиболее распространенной причиной этой проблемы, судя по похожим проблемам, которые я видел здесь и на других форумах, является использование программного RAID на основе материнской платы (иногда называемого «поддельным RAID», хотя это обманчивый термин). Проблема с этим типом программного RAID в том, что он требует, чтобы по крайней мере два программных компонента согласовали используемые структуры данных — встроенное ПО и ОС. В случае многозагрузочного компьютера все ОС должны понимать одни и те же структуры данных RAID, поэтому вам понадобятся три или более конфигураций для соответствия. В любом случае, если встроенное ПО считает, что диск использует программный RAID на основе материнской платы, а ОС — нет, результатом, скорее всего, будет повреждение резервных структур данных GPT. Причина в том, что эти структуры данных занимают последние несколько секторов диска, и именно там программный RAID на основе материнской платы обычно хранитегоструктуры данных. Таким образом, один набор структур данных уничтожит другой. Возникает безумие. (Однако см. ниже.) Когда все синхронизировано, это прозрачно; материнская плата помещает свои структуры данных в конец диска, ОС понимает это и скрывает эту часть диска, и вам не нужно об этом беспокоиться.

Однако если вы не создали таблицу разделов, возможно, проблема вызвана не такой неправильной настройкой с вашей стороны, а скорее со стороны производителя диска или, возможно, кого-то, кто обращался с диском в промежутке (например, если диск был продан кому-то другому, а затем возвращен, и вы получили его из корзины возвратов). В этом случае выполнение in wдолжно gdiskпереписать таблицу разделов, в результате чего сообщение об ошибке исчезнет. Это хорошая идея, поскольку структуры данных резервного копирования GPT существуют не просто так — онирезервное копирование,для использования в случае, если некоторые типы ошибок, ошибки пользователя или аппаратные сбои повредят первичные структуры данных (хранящиеся в начале диска). Большинство ОС и инструментов будут нормально загружаться при отсутствии резервных структур данных, но отказ от них означает, что вы отказываетесь от их преимуществ. Кроме того, есть вероятность, что какой-то инструмент запутается из-за повреждения и сделает что-то плохое. (Я не знаю таких примеров, но новые инструменты пишутся постоянно, а старые могут вырабатывать новые ошибки, так что вероятность такой ошибки всегда присутствует.)

Еще один момент: gdisk's vуказывает на то, что данные раздела резервной копии отсутствуют в конце диска, где они должны быть. Чтобы исправить это, вы можете ввести , xчтобы попасть в меню экспертов, а затем eпереместить структуры данных резервной копии. Эта неуместная таблица разделов резервной копии согласуется с использованием программного RAID на основе материнской платы в прошивке, но не с ОС или с различными другими проблемами (например, с аппаратным массивом RAID, который был расширен, или с диском, который был клонирован с меньшего на больший диск). Перемещение структур данных резервной копии, как правило, является хорошей идеей, и в некоторых случаях необходимо использовать полную емкость диска. (В вашем случае вы восстановите только около 2000 секторов, так что это не большая проблема с точки зрения емкости.) Однако обратите внимание, что если ваша материнская плата настроена на использование своего программного RAID, перемещение структур данных резервной копии сотрет данные программного RAID. Это может сбить с толку материнскую плату, и она, скорее всего, перезапишет свои данные, что приведет к повреждению GPT при следующей перезагрузке. Решение состоит в том, чтобы отключить параметры программного RAID в средстве настройки прошивки, а затем переместить структуры данных GPT с помощью gdiskили какого-либо другого инструмента.

решение2

Контроллер корпусов WD Easystore по какой-то причине "крадет" небольшое количество блоков в конце диска. В результате этого "конец" диска меняется. Если вы разбиваете диск с помощью GPT, пока он еще находится в корпусе, резервная таблица разделов будет записана в место, которое не совсемнастоящийконец пути, поскольку украденные блоки скрыты от глаз.

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

Самое простое решение, если на диске ничего нет, — это переразбить его на новый GPT. Я полагаю, что есть некоторые ручные подходы к решению проблемы путем ручного копирования резервной копии GPT в правильное место, после чего вы можете решить, следует ли увеличивать последний раздел, чтобы использовать новое доступное пространство. Но поскольку объем изменения, вероятно, даже не 1 МБ, это может того не стоить.

Связанный контент