Mancata corrispondenza delle dimensioni GPT GPT dopo il clone dd

13

Sto migrando il mio sistema di avvio EFI Ubuntu su un hdd più grande. Ho usato il comando

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

Non ho smontato il file di input prima di copiarlo e il file di output era uno spazio non partizionato nuovo. Ho avviato con successo dal nuovo hdd più grande.

fdisk -l rapporti:

Mancata corrispondenza delle dimensioni GPT PMBR
gdisk riporta le vecchie dimensioni dell'unità (200 GB) e
PMBR segnala la nuova dimensione del disco rigido (2 TB).

Il gdisk wcomando (scrittura) degli stati di errore funzionerà, tuttavia gdisk help consiglia il comando xe(riposizionare il backup alla fine del disco).

Il mio obiettivo è rimuovere la vecchia unità e utilizzare la nuova unità come disco di avvio principale con la mia vecchia installazione di grub intatta.

Devo solo andare avanti per espandere le partizioni o dovrei usare uno di questi comandi?

hard-drive gpt dd migration

— Zakri Kneebone
fonte

10

Fare come gdisksuggerisce il prompt: utilizzare l' eopzione nel xmenu degli esperti ( ) per spostare le strutture di dati alla fine del disco. Puoi realizzare la stessa cosa partedo iniziare GPart se preferisci. IIRC, lo fanno in modo semi-automatico, anche se chiedono conferma.

Dopo aver spostato le strutture dei dati di backup GPT, puoi ridimensionare le tue partizioni usando GParted.

— Rod Smith
fonte

4

Dovresti credere a questo ragazzo - ha scrittogdisk .

— Mikeserv,

Ho finito usando gparted da un live usb. Ho rimosso le partizioni e riscritto la tabella delle partizioni sulla nuova unità. Da lì, ho scritto i passaggi del robot: gparted ha copiato la struttura delle partizioni del vecchio disco e nel frattempo ha anche ridimensionato le partizioni e i dati copiati per il nuovo disco. Ha fatto tutto mentre dormivo.

— Zakri Kneebone

1

@ZakriKneebone: Dal momento che non vedo il "perché dovresti farlo" spiegato qui: poiché il GPT viene archiviato sul primo e sull'ultimo settore del disco nel caso in cui quello sul primo settore fallisca, ha ancora un dorso -up ... (e un voto!)

— Fabby

1

@RodSmith Anche una soluzione alternativa non interattiva sarebbe il benvenuto. Dopo aver clonato usando ddun'unità più grande questo problema ritorna sempre. Comodo se lo script clone può correggere il "backup GPT" errato. Non riesco a trovare un'opzione di trasferimento in fdisk GPT (sgdisk) versione 1.0.3. Non importa superuser.com/questions/905756/… dice che -e|--move-second-headerè l'opzione sgdisk.

— Pro Backup

1

Voglio pubblicare una spiegazione estesa delle mie prove ed errori per coloro che provano lo stesso poiché la documentazione è piuttosto frammentata e indica diverse tecniche diverse. Ho finito usando gparted da un live usb. Ho rimosso le partizioni e riscritto la tabella delle partizioni sulla nuova unità. Gparted ha uno step sequencer: ha copiato la struttura delle partizioni del vecchio disco e nel frattempo ha anche ridimensionato le partizioni e i dati copiati per il nuovo disco. Ha fatto tutto mentre dormivo. L'uso di dd ha richiesto anche un aggiornamento manuale del file fstab che ho ignorato. Ho quindi provato ddrescue (dal pacchetto Universo tramite Synaptic, non Software Center) da live usb che ha riferito che non funzionava con gpt. Mi riferiva a Gparted.

— Zakri Kneebone
fonte

Anche buono! Molte persone impareranno da queste domande e

— risposte

0

Solo un altro dato, mi sono imbattuto in questo oggi ridimensionando un volume EBS sulla mia istanza EC2. L'ho risolto eseguendo growpart /dev/nvme0n1 1, che ha ridimensionato correttamente la mia partizione.

— Aaron R.
fonte