Spostamento dell'intera installazione Linux su un'altra unità

Ho Ubuntu 14.04 con molti pacchetti e cose relative al lavoro di cui sono molto contento. È installato sul mio disco SSD principale che è uno da 120 GB (avevo scelto "/" quando ho installato Ubuntu, quindi credo che tutto dovrebbe essere su questo disco). Si presenta come / dev / sda

Ora ho aggiunto un altro SSD al mio computer che è un 240Gb. Al momento non ho altri supporti di memorizzazione a portata di mano (ad es. Disco rigido esterno).

Poiché la nuova unità da 240 GB ha ovviamente più capacità ed è più veloce (una generazione più recente di quella da 120 GB), voglio spostare il mio Linux su questa nuova unità. Questa nuova unità si presenta come / dev / sdb e al momento non è formattata o altro (ho letteralmente decompresso e inserito nel mio PC in questo momento: P)

Come posso spostare in sicurezza la mia installazione di Linux sulla nuova unità?

Posso cambiare il cavo SATA in modo che la nuova unità mostri come / dev / sda se necessario.

Questo è l'output di "fdisk -l" se questo aiuta:

Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00076d7a

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   226064383   113031168   83  Linux
/dev/sda2       226066430   234440703     4187137    5  Extended
Partition 2 does not start on physical sector boundary.
/dev/sda5       226066432   234440703     4187136   82  Linux swap / Solaris

Disk /dev/sdb: 240.1 GB, 240057409536 bytes
255 heads, 63 sectors/track, 29185 cylinders, total 468862128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sdb doesn't contain a valid partition table

È possibile utilizzare CLONEZILLA per questo scopo.

Clonezilla è una partizione gratuita e uno strumento di imaging / clonazione del disco che può essere utilizzato per eseguire il backup di tutti i dati (interi dischi o partizioni) in modo altamente compresso e successivamente clonarli nuovamente sul disco rigido per riportarli esattamente nelle stesse condizioni. Questo è più veloce dell'installazione del sistema operativo la maggior parte delle volte.

• Scarica Clonezilla ISO stabile o Download diretto clonezilla-live-2.4.6-25-amd64.iso

• Crea un USB avviabile (live) usando Tuxboot 7.0 .

• Avvio dal supporto Clonezilla creato.

• Ora hai molte opzioni:

  1. Crea un'immagine di solo '/' (saveparts) e clonala su qualsiasi partizione dell'altro tuo SDD.
  2. Crea un'immagine dell'intero disco (saveisk) e clonala sul tuo nuovo SSD.

Nel tuo caso puoi usare anche l'opzione "dispositivo-dispositivo", ma non ne ho familiarità.

Puoi trovare una guida dettagliata su Clonezilla qui: http://clonezilla.org

Può essere fatto in alcuni modi. Ma il più semplice è semplicemente copiare tutti i file dal vecchio disco a quello nuovo.

1. Creare una partizione ext4 e una partizione di swap sulla nuova unità.

2. Avvio da LiveUSB.

3. Montare la vecchia partizione Ubuntu su una directory, montare la nuova su un'altra directory.

4. Copia tutti i file da quello vecchio a quello nuovo usando il cp -acomando.

5. Installa grub sulla nuova unità .

6. Aggiornamento /etc/fstabcon nuovi UUID.

Se qualcosa non è chiaro, posso aggiungere alcune spiegazioni.

Nel caso in cui tu abbia del tempo e vuoi andare al sicuro:

$ dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync

Spiegazione del comando:

• ifè l'input, ofla destinazione
• bsimposta la dimensione del blocco. È la dimensione dei blocchi che dd leggerà e scriverà. Le dimensioni più alte del blocco di solito significano prestazioni più elevate ma anche una maggiore corruzione dei dati se il disco di input ha errori, vedi qui: archwiki su dd
• noerror continua con errori r / w.
• sync sincronizza gli offset se si è verificato un errore.

Questo fondamentalmente creerà un'immagine del tuo disco sda e la scriverà su sdb (stesso layout di partizione ecc.) Ovviamente questo scriverà l'intero 120 GB poiché è indipendente dal file. Quindi molto sicuro, ma non il più veloce, se si utilizzano solo piccole parti del disco. Tuttavia, se il disco di input è piuttosto pieno, potrebbe anche essere più veloce.

MA:

• Dopodiché probabilmente vorrai ridimensionare le partizioni, altrimenti non potrai sfruttare lo spazio extra.
• In ogni caso potrebbe essere necessario modificare il file / etc / fstab.
  Questo è il caso se vengono utilizzati ID hardware per riconoscere i dischi.

A differenza delle altre risposte, ciò consente di clonare l'installazione di Linux e di averla aggiunta al menu di Grub con le installazioni correnti intatte. Inoltre si modifica automaticamente /etc/fstabper te e aggiorna grubil menu di avvio.

Viene fornito un menu per aiutarti a selezionare la partizione corretta su cui clonare. Il clone dalla partizione è la partizione avviata corrente.

rsyncviene utilizzato per una velocità ottimale se si sceglie di riposizionare la partizione. Ciò è utile se l'aggiornamento non riesce, si attende la correzione di bug e si desidera eseguire nuovamente l'aggiornamento. Allo stesso modo potresti aver scelto opzioni sbagliate durante l'aggiornamento e vuoi farlo di nuovo.

Lo script completo può essere trovato qui: script Bash per clonare Ubuntu su una nuova partizione per testare l'aggiornamento LTS 18.04 e questo è come appare lo schermo:

Il modo in cui lo faccio quando passo a un nuovo HDD è:

• creare il layout di partizione che voglio sulla nuova unità
• avviare da Live CD / USB o installare, salvare ecc.
• montare le vecchie partizioni del disco rigido da copiare, per esempio, /mnt/a
• montare le nuove partizioni del disco rigido su cui ricevere i file, per esempio /mnt/b
• cp -aoppure usa tar per copiare i file da /mnt/aa/mnt/b
• installare il boot loader (lilo o grub) sul nuovo disco ¹
• aggiorna il /etc/fstab(potresti voler usare blkidper identificare i nuovi UUID)
• riavviare e verificare se tutto è ok

Note¹:

Controllare tutto il disco rigido e le partizioni usando il comando seguente:

sudo fdisk -l 

Ora prendi nota della partizione su cui è installato Ubuntu che apparirà: /dev/sda1

Montare la partizione in cui è necessario installare GRUB 2 (partizione del disco rigido) e il file system appare in Nautilus. Ora dobbiamo montare la partizione del disco rigido corretta per apportare modifiche all'effettivo MBR del disco rigido. Per questo dobbiamo:

sudo mount /dev/sda1 /mnt
mount

Ora monta la partizione in una posizione alternativa

sudo mount /dev/sda1 /mnt/boot

Creare un collegamento infrangibile dalla /devcartella sull'immagine live da cui è stato avviato alla /devcartella sulla partizione in cui è stata montata/mnt

sudo mount --bind /dev /mnt/dev/

Ora dobbiamo cambiare il root dal root del CD live (/) al root della partizione montata

sudo chroot /mnt

Ora ti trovi in ​​una nuova shell di root, in cui la partizione montata è la nuova radice. È possibile verificare questa digitazione ls. Dato che ora siamo nella partizione montata, possiamo andare avanti e installare GRUB 2:

sudo grub-install /dev/sda 

Le installazioni dovrebbero terminare ora, senza errori

Esci dalla shell CHROOT, digitando exito premendo Ctrl+ D per tornare alla shell Live CD / USB

Smonta le partizioni che abbiamo montato prima di avere un riavvio pulito:

sudo umount /mnt/dev
sudo umount /mnt/boot
sudo umount /mnt

e riavviare dopo aver rimosso il Live CD o la chiavetta USB per l'avvio dal disco rigido:

sudo reboot

fonte

Ho deciso di fare un esperimento relativo a questo post.

Ho acquistato un Lenovo ThinkCentre. Aveva un SSD da 256 GB e un HDD da 1 TB (tipo a spinner - veloce, ma non veloce come un SSD).

Quando ho installato Linux Mint 19.2 (LM19.2), l'ho installato sull'unità da 1 TB. L'SSD ha finito per essere irrecuperabile e ho acquistato un nuovo SSD Kingston da 240 GB.

Stavo per installare LM19.2 sul nuovo SSD, ma sembrava che ci fosse un modo per trasferire la mia immagine LM19.2 ben sviluppata dall'unità da 1 TB sul nuovo SSD.

Ho trovato questo post e, sebbene ci siano alcuni solidi consigli sopra, ero in una modalità per sperimentare. Di seguito è riportato un resoconto di ciò che ho fatto e ha funzionato MOLTO bene.

1. Ho usato GParted per creare una tabella delle partizioni e una partizione sull'SSD dello stesso tipo di quelle sull'HDD da 1 TB.
2. Ho eseguito un'istantanea di TimeShift (nuovo strumento in Ubuntu / Linux Mint) di TUTTO sull'HDD LM19.2 da 1 TB.
3. Ho ripristinato quella istantanea sull'SSD.
4. Una volta completati i passaggi precedenti (puoi anche fare 1 in parallelo con 2 e 3), ho riavviato, assicurandomi che avrebbe scelto l'SSD.
5. L'unica cosa che era strana durante il riavvio era che la schermata iniziale di grub mi chiedeva se volevo avviare Ubuntu. Ho pensato che questo fosse peculiare del restauro TimeShift, e lo era.
6. Gli avvii successivi avviati normalmente come LM19.2.
7. Modificherò questa risposta dopo aver verificato che posso farlo con una nuova unità che pende dal PC esternamente (e sembra ovvio che funzionerà), perché ciò significherebbe che posso replicare rapidamente qualsiasi mia macchina LM al nuovo hardware.

La sola velocità di avvio ha reso questi semplici passaggi meritevoli dello sforzo. Anche Dropbox ha trasferito correttamente: voleva solo che accedessi di nuovo e ci è voluto tutto il tempo per indicizzare i file, ma ha funzionato benissimo.