fdisk se queja: "La tabla GPT de respaldo está corrupta, pero la principal parece estar bien, por lo que se usará".

fdisk se queja: "La tabla GPT de respaldo está corrupta, pero la principal parece estar bien, por lo que se usará".

Hace poco compré dosOccidente digital(WD)tienda fácilUnidades USB externas de 8 TB paravainaellos y use el WD RedNASunidades internas en mi computadora (Arco Linux). El primero terminó siendo un disco WD de marca blanca (WD80EMAZ-00WJTA0), y el segundo era efectivamente un disco rojo (WD80EFAX-68LHPN0).

Instalé el blanco y todo parecía estar bien. Copié cerca de 5 TB de datos sin problemas, pero luego noté el mensaje sobre elGPTerror al usarGpartidoen otro disco en el que estaba trabajando. Mis datos parecen accesibles, así que no he hecho nada todavía.

Hoy instalé la unidad roja y recibo exactamente el mismo error en esa unidad antes de particionar o formatear. He estado buscando soluciones y creo que tiene algo que ver con tener unárea protegida del anfitrión(HPA), pero no sé cómo verificarlo con certeza, ni qué hacer al respecto si es así. ¿Se puede solucionar esto con mis datos intactos en la unidad blanca? Puedo experimentar con el disco rojo, pero no estoy seguro de qué probar.

sudo gdisk /dev/sdb

Producción:

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!

y..

sudo hdparm -N /dev/sdb

Producción:

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

Respuesta1

Su hdparmresultado indica que HPA esdesactivado,entonces el problema no tiene relación con eso.

La causa más común de este problema, a juzgar por problemas similares que he visto publicados aquí y en otros foros, es el uso de software RAID basado en la placa base (a veces llamado "RAID falso", aunque es un término engañoso). El problema con este tipo de RAID de software es que requiere al menos dos componentes de software para acordar las estructuras de datos que se utilizarán: el firmware y el sistema operativo. En el caso de una computadora con arranque múltiple, todos los sistemas operativos deben comprender las mismas estructuras de datos RAID, por lo que necesitarás tres o más configuraciones para que coincidan. En cualquier caso, si el firmware cree que el disco utiliza software RAID basado en la placa base pero el sistema operativo no lo hace, es probable que el resultado sea un daño a las estructuras de datos GPT de respaldo. La razón es que estas estructuras de datos ocupan los últimos sectores del disco, y aquí también es exactamente donde el software RAID basado en la placa base suele almacenaresestructuras de datos. Por lo tanto, un conjunto de estructuras de datos eliminará al otro. Sobreviene la locura. (Sin embargo, consulte a continuación). Cuando todo está sincronizado, es transparente; la placa base coloca sus estructuras de datos al final del disco, el sistema operativo entiende esto y oculta esa parte del disco, y usted no necesita preocuparse por eso.

Sin embargo, si no creó la tabla de particiones, es posible que el problema no se deba a una mala configuración de su parte, sino más bien por parte del fabricante del disco, o quizás de alguien que manejó el disco intermedio (por ejemplo , si el disco se vendió a otra persona y luego se devolvió, y usted lo obtuvo de un contenedor de devoluciones). En este caso, al realizar una wentrada gdiskse debería volver a escribir la tabla de particiones, lo que provocaría que el mensaje de error desapareciera. Hacer esto es una buena idea, ya que las estructuras de datos de respaldo de GPT existen por una razón: son unarespaldo,para usarse en caso de que algunos tipos de errores, errores de usuario o fallas de hardware dañen las estructuras de datos primarias (almacenadas al comienzo del disco). La mayoría de los sistemas operativos y herramientas arrancan bien sin las estructuras de datos de respaldo, pero no tenerlas significa que estás renunciando a sus beneficios. Además, existe la posibilidad de que alguna herramienta se confunda por el daño y haga algo malo. (No conozco ningún ejemplo de esto, pero constantemente se escriben nuevas herramientas y las antiguas pueden desarrollar nuevos errores, por lo que la posibilidad de que se produzca un error de este tipo está siempre presente).

Un punto más: gdisk's vindica que los datos de la partición de respaldo no existen al final del disco, donde deberían. Para solucionar este problema, puede escribir xpara acceder al menú de expertos y luego ereubicar las estructuras de datos de respaldo. Esta tabla de particiones de respaldo mal ubicada es consistente con el uso de software RAID basado en la placa base en el firmware, pero no por el sistema operativo, o con varios otros problemas (como una matriz RAID de hardware que se ha ampliado o un disco que se ha clonado de un formato más pequeño a uno más pequeño). disco más grande). Reubicar las estructuras de datos de respaldo generalmente es una buena idea y, en algunos casos, es necesario utilizar toda la capacidad del disco. (En su caso, recuperará sólo unos 2000 sectores, por lo que no es gran cosa en términos de capacidad). Sin embargo, tenga en cuenta que si su placa base está configurada para usar su software RAID, mover las estructuras de datos de respaldo se borrará. los datos RAID del software. Esto podría confundir a la placa base y es probable que ésta reescriba sus datos, lo que provocaría que el GPT se dañe la próxima vez que reinicie. La solución es deshabilitar las opciones de RAID de software en la herramienta de configuración del firmware y luego mover las estructuras de datos GPT usando gdiskalguna otra herramienta.

Respuesta2

El controlador de los gabinetes WD Easystore "roba" una pequeña cantidad de bloques al final del disco por alguna razón. El efecto de esto es que cambia el "final" del recorrido. Si particiona la unidad con GPT mientras aún está en el gabinete, la tabla de particiones de respaldo se escribirá en una ubicación que no es exactamente la misma.realfinal del recorrido, ya que los bloques robados están ocultos a la vista.

Una vez que retiras la unidad, se puede acceder al extremo real de la unidad y, dado que la copia de seguridad GPT no está allí, parece un problema. Los detalles se discuten enun hilo de Reddit.

La solución más sencilla, si no hay nada en el disco, es volver a particionar con un nuevo GPT. Supongo que existen algunos enfoques manuales para solucionar el problema copiando manualmente el GPT de respaldo en su ubicación correcta, momento en el cual puede decidir si desea ampliar la última partición para usar el espacio recién accesible. Pero dado que la cantidad del cambio probablemente no sea ni siquiera 1 MB, es posible que no valga la pena.

información relacionada