Newsgroup: it.comp.os.linux.iniziare
Titolo: e' possibile trasferire un sistema operativo linux

linux da un disco a un altro... cosi' bellamente?
Supponiamo abbia una suse su un sda1 e voglio "trasferirla" su hda1, 
basta fare un dd e modificare i parametri del grub e dell'fstab o, come 
temo, non c'e' proprio speranza?
Grazie per l'attenzione e a chiunque voglia rispondermi,
l.

 temo, non c'e' proprio speranza?
  Meglio usare dump(8) e restore(8) che dd.  Molto meglio.  dd va bene solo
se hai dispositivi veramente identici.
  Ciao,
-- 
Alessandro Selli, 
http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.
Chiave PGP/GPG: EC885A8B

 temo, non c'e' proprio speranza?
Si fa tranquillamente.
Lascia perdere dd, non c'è bisogno di tali complicazioni.
Ti bastano tar e mount.
Monti /dev/hda1 in un punto del filesystem di /dev/sda1, che supponiamo
sia quello root.
Quindi mount /dev/hda1 /mnt/disconuovo
tar cf - /path1 | (cd /dest ; tar xf - )
Per quelle directory che ti interessano e che vuoi spostare.
Finito questo, chroot /mnt/disconuovo, modifichi grub e /etc/fstab, fai
update di grub (ah, quanto era comodo il buon vecchio lilo in questi
casi!) e via che puoi riavviare col nuovo disco.
Con questo metodo ci ho già clonato due volte il mio sistema da un disco
a uno nuovo :-)
-- 
Massimo Bacilieri AKA Crononauta

 casi!) e via che puoi riavviare col nuovo disco.
Poi se hai una distro che usa i label o gli uuid in /etc/fstab 
(praticamente tutte negli ultimi 2 anni) non ti parte una sega :)



Teoricamente, se la distro e' su una partizione che non occupa tutto il 
disco, e' possibile (clonando la partizione).
Oppure con tar, come gia' suggerito, cmq puoi prendere spunti da qui
http://www.thinkwiki.org/wiki/How_to_copy_a_Linux_installation
-- 
[cRuncH] - and....yes, we crunch
 
Messaggio di servizio:
	Puoi leggere questi fortune anche con lo screensaver/xlock
	"Marquee".


In fstab puoi sempre dichiarare i mountpoint come /dev/sda1, funziona
oggi come ieri. Il problema è se hai dei kernel che vedono i dischi come
sdX e altri che li vedono come hdX e li vuoi usare alternativamente per
fare esperimenti, allora usare gli uuid in fstab è risolutivo anziché
doverlo cambiare prima di ogni avvio.
Stabilito che usi un kernel che riconosce i dischi come sdX, in fstab ci
puoi scrivere tranquillamente /dev/sda1 anche coi nuovi kernel, quindi
non succede proprio nulla.



Beh insomma... se il sistema assegna nomi che cambiano ad ogni boot
qualcosina cambia.
http://wiki.archlinux.org/index.php/Persistent_block_device_naming_%28Italiano%29

 temo, non c'e' proprio speranza?
Usa rsync, e modifica grub e fstab per il nuovo sistema. Probabilmente
dovrai anche reinstallare grub sul nuovo disco.
-- 
Cio' che si vede, e'.

 se hai dispositivi veramente identici.
Potresti spiegarmi quali complicazioni potrebbero
saltar fuori se i dispositivi non fossero identici, ti
riferisci solo alle dimensioni o c'č di piů?

trottalemme ha sentenziato:

  Con dd occhio soprattutto alle dimensioni della destinazione (deve 
contenere la sorgente), di contro non ti serve modificare grub e fstab se 
usi uuid.
  Altri metodi invece (clonezilla, partimage, cp, tar ...) è invece 
necessario rivedere i file di configurazione.
-- 
Non pretendo che comprendiate il significato di quello che ho scritto senza 
averlo riletto un certo numero di volte. Personalmente, vi riterrei degli 
stupidi se lo faceste. Io l'ho letto sei volte ed ancora non l'ho capito.

 Sì ma gli UUID sono nettamente meglio. 
Senza dubbio, ma per fare la migrazione del sistema e farlo ripartire
sul disco nuovo, direi che puoi temporaneamente sopportare anche il
/dev/sda1 ;-)


 se hai dispositivi veramente identici.
A me dump fa paura.
Dump lavora a livello di filesystem, diversamente dd usa una minore 
astrazione da cui deriva una garanzia di affidabilità pressoché assoluta.
Personalmente preferisco dd in ogni caso in cui il disco di destinazione 
sia di dimensione uguale o superiore all'originale, altrimenti mi affido 
piuttosto a tar, che lavora a livello del singolo file.
Comunque la diatriba dump/tar/cpio/dd ecc. è da sempre infinita...

 sempre infinita...
Perchè non metterci dentro anche "cp -a"?
C'è un motivo per cui no l'hai nominato?

JohnnyNewbie ha scritto:

Come "non l'hai nominato"?
E' compreso dentro la parola "ecc."!
Se dovevo scrivere tutti i possibili modi di fare un backup ero ancora 
adesso a pigiare tasti.
Comunque, per inciso, cp non è un comando che mi piace per un backup, è 
pieno di eccezioni e può generare risultati "bizzarri".

 pieno di eccezioni e può generare risultati "bizzarri".
Esattamente il contrario, altrimenti anche il normale uso e manutenzione del 
sistema sarebbe soggetto  a eccezioni e a risultati bizzarri.
E' l'uso di tar o altri sistemi di backup che può portare a perdite di 
alcuni attributi dei file.

Santo Capolozo wrote:


Scusa ne approfitto, se io do:
#: cp -a /var /mnt/pippo/
la directory var in /mnt/pippo e' indistinguibile da /var
anche per quanto riguarda i file speciali? per dire se io
dovessi farlo con /dev ho vaghi ricordi di altri comandi
e/o opzioni.
(devo proprio spostare delle directory di sistema da una
partizione a un'altra e sto temporeggiando)
-- 
Saluti, Dalet

 
La risposta è si, non conosco casi che cp -a fallisca (naturalmente i file 
non devono essere in uso, altrimenti qualsiasi tipo di copia può copiare 
dati non coerenti).
Comunque per prudenza conviene sempre mantenere la directory originale  
(copiata, rinominata), non si sa mai.

 alcuni attributi dei file.
Mi spiace doverti contraddire (d'altronde l'avevo premesso che questa è 
una delle diatribe infinite...)
Se devi copiare un file, ("normale uso e manutenzione del sistema") cp è 
lì apposta.
Per copiare un intero disco, cp è farcito di effetti collaterali, 
provare per credere, dalla ricorsività alla gestione dei file speciali, 
hard links, FIFO e chi ne ha più ne metta.
Non che cp sia il male assoluto ma va, per così dire, "curato troppo".
Strano che ancora non si sia sentito qualche sostenitore di rsync (che 
comunque apprezzo, eh!) :)

 Comunque per prudenza conviene sempre mantenere la directory originale  
Chiedo venia ma faccio notare che questa è una contraddizione.

Dalet wrote:


Thx, be' /var l'ho copiata adesso per prova da una seconda
distro, poi ho dato diff ed ecco cosa dice, ma non credo che
possa essere un problema anche se non capisco cosa vuol dire:
#: cp -a /mnt/sid/var /tmp/
#: diff -qr /mnt/sid/var /tmp/var
File /mnt/sid/var/run/acpid.socket è un socket mentre file
/tmp/var/run/acpid.socket è un socket
File /mnt/sid/var/run/dbus/system_bus_socket è un socket
mentre file /tmp/var/run/dbus/system_bus_socket è un socket
#:
-- 
Saluti, Dalet

Il 04-10-2010, Santo Capolozo dice:



Be' perche'? e' solo una misura di sicurezza che avrei cmq
sempre fatto di mia iniziativa.. tranne il fatto che mi
attira molto il comando mv, se non fosse che la directory
da spostare e' su un fs separato non avrei esitato a
scegliere mv, ma su partizioni differenti non ci vedo molto
chiaro su cosa fa mv: copia controlla cancella? e i socket?
-- 
Saluti, Dalet

 
Che diff non può usare per il confronto file speciali tipo i socket, come 
potrebbe confrontarne il contenuto?

 
Non è possibile spostare entità tra filesystem differenti, è possibile solo 
copiare/replicare.

 hard links, FIFO e chi ne ha più ne metta.
]zac[
Liberissimo di scrivere e credere quello che vuoi, ma ribadisco che cp -a ha 
un comportamento ''perfetto'' per la copi, mentre tar non è per niente 
infrequente che non gestisca tutto le proprietà delle entità presenti sul un 
filesystem linux.

Dalet wrote:


Ah ho capito THX!
-- 
Saluti, Dalet

 filesystem linux.
Quali non gestirebbe, per esempio? Ho clonato più volte il disco a colpi
di tar e non ho mai avuto problemi.
In compenso, con cp -a, raccontami cosa ti succede se hai degli hardlink
di mezzo...


 Comunque la diatriba dump/tar/cpio/dd ecc. è da sempre infinita...
  E sarebbe infatti ora di farla finita: o dump o killall!  :-D
  Ciao,
-- 
Alessandro Selli 
http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

 a uno nuovo :-)
Un dubbio.
Ho fatto proprio ieri il trasferimanto di una debian, da un hd da 160g pieno ad
uno da 320g, usando la tua versione del comando tar tramite una live (trk
3.4).
Non so se sia colpa della live o del tar, ma mi sono trovato /root e /sbin con
accesso persino al mondo di quark!
Ho visto in un'altro post su un altro gruppo, un procedimento praticamente
identico, tranne nelle opzioni del comando tar:
tar psc --numeric-owner * | tar psx --numeric-owner -C /destinazione
Non é micca meglio usare queste ultime opzioni?
-- 
+---------------------------------------------------------------------------+
|I puristi ritengono inopportuno utilizzare driver proprietari sutto Linux, |
|i masochisti amano utilizzare driver Windows sotto Linux... Twisted Evil   |
+-----#19--------------------Campagna contro le pubblicita` idiote.---------+