El tamaño de GPT PMBR no coincide después del clon dd

13

Estoy migrando mi sistema de arranque Ubuntu EFI a un disco duro más grande. Usé el comando

dd if=/dev/sdb of=/dev/sda

No desmonté el archivo de entrada antes de copiarlo y el archivo de salida era un espacio fresco sin particionar. He arrancado con éxito desde el nuevo disco duro más grande.

  • fdisk -l informes:

    El tamaño de GPT PMBR no coincide

  • gdisk informa el tamaño de la unidad anterior (200 GB) y

  • PMBR informa sobre el nuevo tamaño del disco duro (2 TB).

El gdisk wcomando de estados de error (escritura) funcionará, sin embargo, gdisk help recomienda el comando xe(reubicar la copia de seguridad al final del disco).

Mi objetivo es eliminar el disco viejo y usar el disco nuevo como disco de arranque primario con mi instalación grub intacta.

¿Debo seguir adelante y expandir las particiones o debo usar uno de estos comandos?

hard-drive gpt dd migration Rodillera Zakri
fuente

Respuestas:

10

Haga lo que gdiskindica el indicador: use la eopción en el xmenú de expertos ( ) para reubicar las estructuras de datos al final del disco. Puede lograr lo mismo en partedGParted si lo prefiere. IIRC, lo hacen de forma semiautomática, aunque piden confirmación.

Una vez que haya movido las estructuras de datos de respaldo de GPT, puede cambiar el tamaño de sus particiones usando GParted.

Rod Smith
fuente
44
Deberías creerle a este tipo , escribiógdisk .
mikeserv
Terminé usando gparted de un usb en vivo. Eliminé las particiones y reescribí la tabla de particiones en la nueva unidad. A partir de ahí, escribí los pasos del robot: gparted copió la estructura de partición del disco anterior y, mientras tanto, también redimensionó las particiones y copió datos para el nuevo disco. Hizo todo mientras dormía.
Zakri Kneebone
1
@ZakriKneebone: Como no veo el "por qué deberías hacer esto" explicado aquí: porque el GPT se almacena en el primer y último sector del disco en caso de que falle el primero, todavía tiene un respaldo -up ... (¡y un
voto positivo
1
@RodSmith También sería bienvenida una solución alternativa no interactiva . Después de clonar usando dduna unidad más grande, este problema siempre vuelve. Útil si el script de clonación puede corregir el "GPT de respaldo" incorrecto. No puedo encontrar una opción de reubicación en GPT fdisk (sgdisk) versión 1.0.3. No importa superuser.com/questions/905756/… dice que esa -e|--move-second-headeres la opción sgdisk.
Pro Backup
1

Quiero publicar una explicación ampliada de mis pruebas y errores para aquellos que intentan lo mismo, ya que la documentación está bastante fragmentada y apunta a varias técnicas diferentes. Terminé usando gparted de un usb en vivo. Eliminé las particiones y reescribí la tabla de particiones en la nueva unidad. Gparted tiene un secuenciador por pasos: copió la estructura de partición del disco anterior y, mientras tanto, también redimensionó las particiones y los datos copiados para el nuevo disco. Hizo todo mientras dormía. El uso de dd también requirió una actualización manual del archivo fstab que omití. Luego probé ddrescue (del paquete Universe a través de Synaptic, no Software Center) desde live usb que informó que no funcionaba con gpt. Me refirió a gparted.

Rodillera Zakri
fuente
¡Buena también! Mucha gente aprenderá de estas preguntas y respuestas ...
Fabby
0

Otro dato más, me encontré con esto hoy redimensionando un volumen EBS en mi instancia EC2. Lo resolví ejecutando growpart /dev/nvme0n1 1, lo que redimensionó mi partición correctamente.

Aaron R.
fuente