working copy einer installation auf neue HDD

D

DoomWarrior

Member
Hallo

ich habe eine neue Platte bekommen und möchte jetz die alte drauf "dd"-n soweit wäre das ganz einfach. Jedoch müßte ich das im laufenden Betrieb machen und da verweigert dd seinen dienst.
Also könnte ich einfach per cp die daten rüberschaufeln,
jedoch hab ich dann zwei probleme... wie lege ich einen bootsektor auf der "neuen" platte an und wie die Deviceknoten anlegen. Dort gibt es ja ein Skript MAKEDEV, Jedoch wenn ich das richtig verstehe, erzeugt er die knoten trotzdem im alten /dev ordner

Wäre für jeden tipp dankbar.

PS. nein es ist nicht möglich die Platte in einem anderen System zu dd'n. ohne finanziellen aufwand inform eines SCSI-Controller...
 
ich erstelle mit einem script bootbare images, welche ich dann auf eine compact-flash-karte mit dd schreibe. vielleicht kannst du daraus was nuetzliches ableiten, speziell was das bootfaehigmachen angeht:
Code: 
dd if=/dev/zero of=${BASE}/image bs=65536 count=1992
vnconfig -v vnd0 ${BASE}/image 512/32/16/498
disklabel -R -r vnd0 ${BASE}/label
newfs -O 2 /dev/rvnd0a
installboot -v -o console=com0 /dev/rvnd0d ${BASE}/dest/usr/mdec/bootxx_ffsv2
mount -o softdep /dev/vnd0a ${BASE}/mnt

# boot loader
cp -p ${BASE}/dest/usr/mdec/boot ${BASE}/mnt/

[...]

umount /dev/vnd0a
vnconfig -v -u vnd0

edit: ach ja, ich wuerde dann mit tar oder rsync das system uebertragen, wobei /proc z.b. ausgenommen werden sollte. tar und rsync koennen auch device nodes 1:1 kopieren.
 
Musst das wirklich im laufenden Betrieb geschehen?

Ansonsten wäre g4u wohl die einfachste Lösung.
 
Ich vermute, du hast nur einen Rechner -- deshalb muss es im laufenden Betrieb erfolgen ???
Wenn ja, könntest du von CD oder Diskette booten und dann dd ausführen

Stefan
 
Du brauchst g4u:
http://rfhs8012.fh-regensburg.de/~feyrer/g4u/

g4u ("ghost for unix") is a NetBSD-based bootfloppy/CD-ROM that allows easy cloning of PC harddisks to deploy a common setup on a number of PCs using FTP. The floppy/CD offers two functions. The first is to upload the compressed image of a local harddisk to a FTP server, the other is to restore that image via FTP, uncompress it and write it back to disk. Network configuration is fetched via DHCP. As the harddisk is processed as an image, any filesystem and operating system can be deployed using g4u. Easy cloning of local disks as well as partitions is also supported.
Zum Vergrößern anklicken....
 
kaishakunin schrieb:
Du brauchst g4u:
Zum Vergrößern anklicken....
ziemlich voreilige analyse. ich schaetze mal, wenn doomwarrior sagt, dass er eine neue platte hat, dann besteht zu 99% die chance, dass die geometrie unterschiedlich ist. dass er zuerst dd benutzen wollte, heisst nicht, dass ein 1:1 image die richtige loesung ist.

generell ist 1) einrichten der platte (disklabel, newfs, installboot etc.) und 2) uebertragen des system auf dateiebene der bessere weg.
 
TCM schrieb:
ziemlich voreilige analyse. ich schaetze mal, wenn doomwarrior sagt, dass er eine neue platte hat, dann besteht zu 99% die chance, dass die geometrie unterschiedlich ist. dass er zuerst dd benutzen wollte, heisst nicht, dass ein 1:1 image die richtige loesung ist.
Zum Vergrößern anklicken....

Nicht zwangsläufig. g4u bzw. dd kann problemlos eine kleine Platte auf eine große bringen. Der Rest (also der überschüsssige Platz) kann dann als neues Slice erstellt werden. Habe erst vor 3 Wochen so von einer 3GB auf eine 12GB IDE Platte migriert und die restlichen 9GB als /home/ initialisiert. Lief problemlos.
Von groß auf klein wird aber so nicht gehen.


Noch was:
wenn du nicht von Floppy/CD/USB wasweißich booten kannst, dann boote in den singleusermode (boot -s am bootselektor), dann werden die Slices erstmal nicht gemountet und können dd-ed werden.
 
das problem hat sich gerade von selbst "gelöst", ich trantüte habe statt, "cp" "rm" gemacht... nun komme ich um eine neuinstallation eh nicht mehr herum. Aber trotzdem danke für die tipps, werde sicher nocheinmal in die selbe verlegenheit kommen und dann bin ich schlauer
 
hehe schlauer im sinne von: "jaa nicht versuchen mit rm dateien zu kopieren!"? :) *kleiner spass*

Aergert dich das ueberhaupt nicht oder hast du irgendwo eine working copy deines /etc, /usr/pkg/etc und deines /home verzeichnisses?
 
nein ist nicht so wichtig, die Kiste ist nicht mein Arbeits-Rechner, sondern nur mein Spielzeug, von daher war eh nicht viel drauf abgesehen davon war es "nur" der usr/ Ordner ;) den rest habe ich dann nachträglich wieder überspielt
 
nur mal als randbemerkung: rm kennt zb kein -p, welches du mit cp aber mindestens haettest verwenden sollen.

cp(1) is eine ganz schlechte wahl, um ein komplettes system 1:1 zu kopieren, da es ohne -p rechte und user:group nicht uebernimmt. wie es mit device nodes und sonstigem umgeht, weiss ich nicht aus dem stehgreif, weil cp(1) dafuer wie gesagt eh das falsche tool ist und man fuer sowas tar oder rsync nimmt.
 
Hmm, kann mich nicht mehr wirklich dran erinnern, aber so hab ich das glaub ich gemacht:

  1. 1. mit fdisk neue platte erstellen
  2. 2. mit disklabel -i neue partition zum disklabel hinzufügen
  3. 3. neue partition mounten z.b. unter /backup
  4. 4. alle dateien mit cp -r -p nach /backup kopieren - ausser /backup, /dev, /kern, /proc,
  5. 5. die nicht kopierten verzeichnisse - ausser /backup - unter /backup als leere verzeichnisse anlegen, mit den korrekten zugriffsrechten
  6. 6. /dev/MAKEDEV nach /backup/dev kopieren
  7. 7. /backup/dev/MAKEDEV all aufrufen (sollte aber eigentlich auch automatisch beim starten von der /backup partition gehen)
  8. 8. /backup/etc/fstab anpassen

alles AFAIR
 
cp ist imho auch nicht so ganz der hit.
ich verwende für sowas gerne cpio, allerdings macht man solche aktionen sinnvollerweise im singleuser-mode, um sicher zu gehen. wie schon von tenco beschrieben, platte vorbereiten und hinmounten, wenns mehrere filesysteme sind, dann die mountpoints in /backup anlegen und den ganzen krempel dahin mounten, dann

find / -print | grep -v /backup/ | cpio -pvmud /backup

auf die art mach ich immer meine gespiegelten RAIDframe-geschichten. spiegel auf zweiter platte komplett einrichten, wie oben alles rüberkopieren, raid autoconf rein, inkl. roto-flag, wos gebraucht wird, reboot, erste platte fürs raid labeln, devices dann ans raid anflanschen, rebuild, fertig.
gebootet wird dann von einem kleinen non-raid-filesystem wo nur booter und kernel drin sind, das muss man noch auf beiden platten manuell pflegen.

und die letzte alternative: backup/restore. kann man gleich von seiner installation die backup-files archivieren, ne install-cd basteln und die images mit drauf tun, dann kann man jederzeit from scratch die kiste in wenigen minuten hochziehen.
 
tenco schrieb:
Hmm, kann mich nicht mehr wirklich dran erinnern, aber so hab ich das glaub ich gemacht:

  1. 1. mit fdisk neue platte erstellen
  2. 2. mit disklabel -i neue partition zum disklabel hinzufügen
  3. 3. neue partition mounten z.b. unter /backup
  4. 4. alle dateien mit cp -r -p nach /backup kopieren - ausser /backup, /dev, /kern, /proc,
  5. 5. die nicht kopierten verzeichnisse - ausser /backup - unter /backup als leere verzeichnisse anlegen, mit den korrekten zugriffsrechten
  6. 6. /dev/MAKEDEV nach /backup/dev kopieren
  7. 7. /backup/dev/MAKEDEV all aufrufen (sollte aber eigentlich auch automatisch beim starten von der /backup partition gehen)
  8. 8. /backup/etc/fstab anpassen

alles AFAIR
Zum Vergrößern anklicken....

wie is das da dann mit dem bootmanager?
würd mich jetzt mal stark interessieren, da ich das evtl. auch bald vor mir hab.
 
für den bootmanager ist fdisk zuständig. der kann den installieren (-c) und konfigurieren (-B). steht alles in der manpage drin. die netbsd-partition dann noch bootfähig machen geht mit installboot, auch gute manpage.

gilt natuerlich an dieser stelle nur fuer i386 und amd64, andere plattformen, andere sitten.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben