He seguido Consejos de David Anderson y descubrí que la partición (según la descripción de GPT) es 3584 bytes (7 bloques LBA) más grande que el volumen físico de almacenamiento del núcleo. Usando esta información, logré reducir el volumen para añadir una segunda partición.

El proceso es, sin embargo, bastante aterrador: implica un pánico del kernel, y luego algunos más crípticos, inútiles y sin solución diskutil errores, y luego algunos fallos más espantosos.

Y que esto sea una antirespuesta:

• si se trata de un sistema de archivos diseñado por Apple (como HFS y APFS),
• y no tienes conocimiento profesional de su funcionamiento interno,
• y encuentras tu volumen en un estado inconsistente - debe considerarse inconsistente tan pronto como la Utilidad de Discos comience a quejarse -
• y sin embargo el volumen sigue siendo utilizable de alguna manera (puedes ver tus archivos y demás):

Entonces, por amor a tus datos y a tu bienestar, en lugar de intentar arreglar el problema metiéndote con la cabecera del volumen o la tabla de particiones (como hice yo),

Sólo hay que mover todo y reformatear.

Al final no perdí ningún dato. Este es mi proceso. Espero que personas más conocedoras que yo puedan señalar todos los errores que cometí.

Nota: 1 bloque son 512 bytes.

• (En primer lugar, hice una copia de los primeros 512 bytes de la partición, que contiene el encabezado del volumen, utilizando dd ).

• Utilizando el gpt me enteré de que mi segunda partición GPT (la partición principal) tiene un tamaño de 27344355255 bloques; después de esto especificación de Core Storage (que es la capa de abstracción que permite el cifrado HFS), examiné la cabecera del volumen de la partición y me enteré de que el volumen físico de almacenamiento del núcleo sólo ocupa 27344355248 bloques. Esto significa que había un espacio extra de 7 bloques.

• Entonces decidí liberar estos 7 bloques recreando la tabla GPT (usando el gpt ), marcando también el tipo de la nueva partición como Bota de Apple .

• Intenté crear un volumen HFS+ en la nueva partición utilizando diskutil . Esto no es posible porque un volumen HFS+ requiere un mínimo de 512 KB.

• Con la partición de arranque de Apple sin formatear, hice el arriesgado movimiento de pedir a la Utilidad de Discos que redimensionara la partición de 14 TB. Esta vez, la Utilidad de Discos no se quejó de que faltaban arrancadores. Sin embargo, antes de que terminara el redimensionamiento, se produjo un pánico en el núcleo.

• Después de reiniciar, diskutil informó que la partición original de 14 TB es ahora de 12 TB, todavía intacta. La partición de arranque de Apple de 7 bloques ocupaba ahora los 2 TB de espacio libre restantes, todavía sin formatear.

• Luego, volví a modificar la tabla GPT, esta vez añadiendo un 262144 -bloqueo de la partición de arranque de Apple después de la partición de ahora 12 TB, y otra partición de almacenamiento del núcleo que ocupa el espacio restante.

• En este momento, tanto la partición de 12 TB como la de 2 TB aparecen en la Utilidad de Discos. Al reformatear la partición de 2 TB como un volumen encriptado JHFS+ (para que también tenga un booter), ambas particiones pueden ser redimensionadas libremente usando la Utilidad de Discos sin errores.

• La única advertencia fue que el uso de los Primeros Auxilios ( diskutil verifyVolume ) en el volumen de 12 TB ahora reporta persistentemente el error "Tamaño incorrecto para el volumen" (justo después de decir que el volumen "parece estar bien", también). Esto no se ha podido arreglar con ningún diskutil de mando. Pero a pesar del error, los dos volúmenes pueden ser redimensionados y montados normalmente.

• Llegados a este punto, parece que mi pregunta original ha quedado resuelta, en gran medida.

Este es el aspecto que tiene ahora el esquema de partición:

   #:                       TYPE NAME                    SIZE       IDENTIFIER 
   0:      GUID_partition_scheme                        *14.0 TB    disk2 
   1:                        EFI EFI                     209.7 MB   disk2s1 
   2:          Apple_CoreStorage - Main Partition -      12.0 TB    disk2s2 
   3:                 Apple_Boot Boot OS X               134.2 MB   disk2s3 
   4:          Apple_CoreStorage Time Machine            2.0 TB     disk2s4 
   5:                 Apple_Boot Boot OS X               134.2 MB   disk2s5 

(El resto es que no sé lo que estoy haciendo).

• Después de esto, se me ocurrió la hipótesis de que el error "Tamaño de volumen incorrecto" del que se quejaba la Utilidad de Discos era sobre el Volumen Lógico, y no sobre el Volumen Físico.

  • Core Storage tiene muchas capas de abstracción, cuyo orden es Volumen físico → Grupo de volúmenes lógicos → Familia de volúmenes lógicos → Volumen lógico.
  • Si lo estoy entendiendo bien, PV es lo más parecido a la partición GPT, LVF es donde se produce el cifrado de FileVault, y LV es el volumen que los usuarios pueden ver.

• Para probarlo, borré la partición de 2 TB mediante la Utilidad de Discos. No hubo ningún problema. El disco duro ahora contenía EFI, la partición de 14 TB y el booter de 134,2 MB.

• Intenté usar diskutil cs resizeVolume para redimensionar sólo el Volumen Lógico a 12 TB, y no el Volumen Físico. El redimensionamiento no ha podido llevarse a cabo debido al error "Tamaño de volumen incorrecto". (Lo mismo ocurrió con diskutil cs resizeStack ).

• Entonces tuve la horrible idea de revertir no sólo la tabla GPT, sino también la cabecera del volumen Core Storage, al estado en que se encontraba cuando se publicó esta pregunta.

  • Esto es con la esperanza de que diskutil verifyVolume se ajustará automáticamente el tamaño del volumen, y entonces puedo empezar de nuevo el proceso, pero redimensionando primero el Volumen Lógico.
  • Hice una copia de seguridad de la cabecera del volumen actual, y luego dd reescribió los primeros 512 bytes del volumen utilizando la copia de seguridad .img archivo que hice de la cabecera al principio de esta respuesta.
  • Después de hacerlo, el volumen de 14 TB volvió a ser imposible de montar. Todo diskutil las operaciones fracasarían en este punto.

• Intenté revertir este cambio escribiendo de nuevo la cabecera de volumen de 512 bytes. Entonces, se produjo otro pánico en el núcleo.

• Esta vez, las cosas se pusieron mucho más serias. Durante las siguientes horas, cada vez que conectaba el disco duro a mi portátil, el kernel de MacOS entraba inmediatamente en pánico, ya fuera en modo normal, recuperación, modo seguro o modo de usuario único.

• Intenté arrancar en Ubuntu desde el USB, y examinar y manipular el Volume Header desde allí, sin éxito.

• Casi perdí la esperanza, cuando recordé que, cuando la partición falló por primera vez, ejecuté dd a través de los primeros GBs de la partición y la guardé como una imagen, la cual fue borrada desde entonces. La recuperé usando Disk Drill, y después de comparar dolorosamente los volcados hexadecimales, Decidí copiar el primer 62500 bloques (32 MB) del archivo de imagen a la partición.

  • Mi idea era que esto haría que MacOS reconociera el volumen de la misma manera que reconoció el volumen original de 14 TB cuando falló por primera vez, y entonces si volvía a hacer los pasos que describí en la pregunta (recreando la tabla GPT), podría recuperar el volumen por segunda vez, y pensé que lo peor que podría pasar es que perdería todos los cambios de archivos desde que la partición falló por primera vez.

• Sorprendentemente, esto no sólo recuperó la partición, sino que todos los archivos que estaban en el disco duro antes de que rompiera la partición la segunda vez siguen ahí.

• Ahora estoy en el proceso de hacer una copia de seguridad de todo para poder empezar el disco duro de nuevo.

Para reiterar: ante la menor duda, ¡respaldo!