Newsgroup: it.comp.os.linux.iniziare
Titolo: Attenzione con Buster e precedenti nuove funzioni e vecchie abitudini

Una volta per clonare un disco su uno nuovo, si faceva:
 
dd if=/dev/sdx5 of=/dev/sdy5
 
senza tanti complimenti e non c'erano particolari cautele da
usare. Per esempio, uno poteva farlo per le prime partizioni,
tenendole "di riserva", senza usarle, anche nel mentre si
usava il resto del disco, in modo da recuperare rapidamente
in caso di un evento disastro (o anche come prima misura nel
caso di dubbio di essere stati "infettati"), tipo con il
commando:
 
dd if=/dev/sdy5 of=/dev/sdx5
 
l'installazione del sistema operativo, invece della tediosa
procedura di una nuova installazione.
 
Ovviamente e' inteso che, ad esempio, nella partizione "5"
ci sia solo e nient'altro che il sistema operativo,
ponendo le proprie cose personale in partizioni linkate
alla directory /home che si trova nel sistema operativo.
 
PS: chiaro che si hanno sempre abbondanti backup, perche'
usare "dd" in questo modo puo', in caso di svista,
radervi a zero tutto il vostro lavoro.
 
Quindi, salvo si sia un maniaco dell'installare sempre nuove
applicazioni e aggiornamenti, un ritorno "espresso"
alle origine e' molto comodo farlo in questo modo.
 
Ma oggi nel /etc/fstab ci sono queste UUID ed altri programmi,
come /sbin/mdadm usano le UUID.
 
Ecco cosa mi e' accaduto: faccio la solita opera di clonaggio
e poi un reboot per sistemare il nuovo disco prima di tornare
operativo. Ad un certo punto mi accorgo con il "df" che
le partizioni montate non sono tutte del disco
"originale", ma, ad esempio, quella di /boot e' presa dal
disco nuovo. Ops!
 
Cosa era successo: il disco originale era in posizione "2"
nella catena "hardware" (unita b) mentre quello nuovo
fisicamente era in posizione "1" (unita' a).
Avendo fatto il clone dell'inizio del disco, era stato
ovviamente "clonato" anche la UUID.
 
E cosi' al riavvio, il boot a quanto pare ha cercato la sua
UUID a partire dal disco "a" trovandolo e quindi montandolo.
 
Mi e' toccato cambiare la UUID del filesystem montato
sotto /boot (partizione sua) e riavviare, per ripristinare
le cose.
 
La cosa piu' diventare delicata se nel calcolo del numero
di settori da clonare con "dd", finite per debordare sulla
partizione successiva (ad esempio, proprio quella che
contiene la vostra "home" e tutto il lavoro).
 
Cosa accaduto a me, che per essere sicuro di pigliare tutta
la partizione del sistema operativo, ho leggermente superato il
confine.
 
Risultato, avevo clonato anche l'inizio della partizione
sotto /home/utente con il pezzo del filesystem contenente
la UUID. Identica a quella sul disco originale.
Non avevo spinto la clonazione oltre, perche' nelle mie
intenzione cio' che si trovava dopo la partizione 5
doveva essere ripartizionato per un uso diverso.
 
E cosi' al riavvio (per fortuna ho una user apposita per le
manipolazioni sul sistema, che non si appoggia alla /home/utente),
al comando "df" ho notato che anche la partizione montata
per "/home/utente" era sul disco nuovo. Solo che in questo
caso non c'era quasi niente (l'operazione di copia non era
andata oltre) ed infatti per curiosita', ho visto che mancavano
  quasi tutti file personali.
Se non mi fossi accorto del piccolo problema con la cartella
di /boot, probabilmente sarei finito nel panico, senza capire
cosa era accaduto :-)
Mi sono limitato a radere con zeri l'inizio della partizione 6
ed al riavvio i dati sono apparsi tutti (ovviamente la partizione
/home/utente era nuovamente montata sul disco originale).
 
Insomma, dovro' studiare un nuovo modo per clonare il sistema.
 
Quindi, attenti agli UUID duplicati, potreste fare dei macelli sui
vostri dati, se non vi accorgete.
 
E fare sempre il backup (anche se non ne ho avuto bisogno
nel caso citato).

 citato).
 
Da che lavoro in ambiente Unix io uso esclusivamente tar per fare copie 
di un disco, anche se questo mi obbliga a creare prima le partizioni.
usare dd è voler cercarsi grane.
 
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   < 
http://giovanni.homelinux.net/
 >

 dd if=/dev/sdx5 of=/dev/sdy5
 
ma diciamo pure anche no.
un disco si clona in questo modo:
 
dd if=/dev/sdx of=/dev/sdy
 
così stai clonando una partizione, che è una operazione fondamentalmente 
stupida perché le partizioni non hanno alcuna necessità di essere 
clonate. una partizione si formatta, si copia a livello di fs con rsync e 
si monta al posto della precedente.
 
clonando a basso livello una partizione è chiaro ti tiri dietro tutta una 
serie di effetti collaterali indesiderati se il tuo intento è quello di 
trasferire un sistema da un disco all'altro.

 nel caso citato).
 
Se devi fare comunque un backup, fallo dell'intera partizione o 
dell'intero disco (es. con Clonezilla) e te ne cagafotti della 
clonazione...

 trasferire un sistema da un disco all'altro.
 
Esatto.
 
In pratica, volevo avere gia' la tabella della partizioni belle e' 
pronta, con tanto di boot valido. Alla fine ci avrei messo meno a fare
le cose a manina.
 
Cio', nonostante e' stata una esperienza interessante, che mi ha 
insegnato svariati "caveat". Come si diceva una volta ? Sbagliando si
impara. Ove l'imparare e' inteso che sbagliando si imparano anche cose
a cui non si era pensato.
 
 
 
 

 le cose a manina.
 
è una operazione che si fa regolarmente, es. per creare un disco bootable 
usb o sd (il fatto che il sorgente sia un file image o un block device 
non cambia nulla) o per creare più macchine identiche.
non so cosa tu abbia imbastito ma sicuramente hai fatto qualcosa di 
sbagliato. per esempio, se hai impostato il count dei blocchi con un 
numero a caso avrai corrotto il file system di destinazione con una copia 
parziale. 

 parziale.
 
Non c'era nulla da corrompere visto che il disco era nuovo.
 

 Non c'era nulla da corrompere visto che il disco era nuovo.
 
se copi un dato parziale ovviamente la copia di destinazione sarà 
corrotta. 

 corrotta.
 
Se il dato parziale e' irrilevante (partizione dati senza interesse
al sistema operativo), e poi soppiantata , cosa me ne frega ?
 
 
A chi legge (non lei, perche' ormai e' diventato insultante e non
capisco le sue ragioni), ecco un esempio pratico della tecnica che ho
appena menzionato.
 
Ieri stavo per passare alla fase finale, quella dell'installazione
di un paio di giochi, tra cui Freecol (qualche ora di svago meritato).
Ma prima ho verificato le vulnerabilita' e scoperto che lo java su
cui si appoggia Freecol ha un paio di "buchi di sicurezza".
 
Avendo visto la facilita' con cui posso cambiare i dischi con il
nuovo cassetto, ho optato per una installazione dedicata su un vecchio
disco da 160 GB (che prima era un disco di lavoro per il sistema, ma
oggi con terabyte di capacita' dei nuovi dischi non mi serve piu').
 
Avendo strutturato 32 GB iniziali della partizione per un sistema
operativo completamente autoincluso, con tutte le sue partizioni
come da manuale (/boot etc.) mi e' bastato un:
 
dd if=/dev/sdb of=/dev/sda count=67108864
 
Volendo, potevo anche stare "corto", tipo 67108862, perche' in coda
non c'e' nulla di degno di attenzione da copiare (l'ultima partizione
non e' piena), cioe' il mio timore per cui avevo sovrascritto il primo
paio di blocchi della partizione "che non mi serviva", era insostanziato.
 
Ma il numero e' giusto ? Basta leggere dalla guida di "dd":
---------------------------------------------------------
read and write up to BYTES bytes at a time (default: 512)
---------------------------------------------------------
Il "default" e' cio che ci interessa. Se non dite nulla a "dd",
da quando ho memoria, la sua unita' di lavoro e'  il settore
(o "blocco" come oggi pare essere di moda) da 512 bytes.
 
In ogni caso, se avete dal vostro fdisk la riga:
------------------------------------------------------
Sector size (logical/physical): 512 bytes / 4096 bytes
------------------------------------------------------
basta che aggiungete al "dd" il paramentro bs=4096
ed usate il conteggio indicato da "fdisk", se indicato
in settori fisici (a voi la verifica, sapendo la dimensione
di una partizione e verificando il conteggio indicato di settori)
 
In ogni caso, finita la copia, spenti gli altri dischi, e
lanciando il disco da 160 GB da solo, funziona al primo colpo.
A questo punto basta creare la partizione di lavoro (tutto
quello che resta del disco da 160 GB) ed installare i giochi.
Pero' il limite della partizione estesa e' indicata ben oltre
la capacita' del disco da 160 GB, quindi come si fa ?
Lavoro inutile ? Tutto da rifare ?
Ma no! :-)
 
Fdisk manipola solo le partizioni e non i dati nei dischi,
ed anche se avete gia' partizioni secondarie, non c'e'
problema.
 
Aprite "fdisk", cancellate la partizioni secondaria che
contiene il "prezioso" sistema operativo gia' preinstallato,
cancellate la partizione estesa e poi ricreate la partizione
estesa con la giusta dimensione del disco ben piu' piccolo.
E poi ricreate la partizione secondaria con la stessa
identica capacita' di prima.
 
E, miracolo, avete un disco-sistema perfettamente funzionale
ma con la partizione estesa del giusto valore, cosi da
potere creare la successiva partizione secondaria "di lavoro"
(o in questo caso, "di gioco" ;-)
 
Tempo per un:
 
"fdisk" per copiare-incollare il valore da dare al "count"
"dd" per fare la copia fino al count="incollato qui"
"fdisk" per cancellare partizione secondaria ("d")
         cancellare partizione estesa
         ricreare partizione estesa
         ricreare partizione secondaria su cui c'e' il SO
         creare partizione secondaria che prende il resto
         della partizione estesa
 
da paragonare ad un creazione ad hoc delle partizioni
ed una completa installazione.
 
Dimenticavo, non mi fido delle installazioni on-line al
volo, voglio fare installazione senza alcuna connessione
alla rete (tutti e tre i dischi binari a disposizione e
che vengono richiesti ogni volta che voglio aggiungere
una applicazione). Sara' piu' scomodo, ma almeno ho un
certo controllo di cio' che entra.
 
E le vulnerabilita' ? Vero, senza costanti aggiornamenti
ci possono essere esposizioni, ma anche l'abitudine ad
accettare agggiornamenti regolari espone a dei rischi.
Per ora Linux non e' ancora un colabrodo come Windows e poi
basta evitare Java ed uno dei buchi piu' grossi e' evitato.
Vorra' dire che faro' la dichiarazione dei redditi (che
richiede Java) sul disco dei "giochi".

 appena menzionato.
 
interessante, tutta roba che non serve ad un cazzo ma apprezzo tu abbia 
dedicato il tuo prezioso tempo per scriverlo :-)