Kopieren einer kompletten Partition, wie?
Hallo, nach dem ich ja lange mit SuSE 8.2 zufrieden war, habe ich mir nun doch mal SuSE 10.0 installiert, und zwar auf einer neuen (geliehenen Festplatte) (/dev/hdc1). Nach dem ich nun alles dort eingerichtet habe, möchte ich mich gern von meiner 8.2 trennen (verteilt auf /dev/hde und /dev/hdf). Frage: Nach dem ich hde und hdf neu partitioniert habe, wie übertrage ich dann am besten das komplette SuSE 10 auf eine der beiden Platten? Gehe ich recht in der Annahme, dass ich das am besten über knoppix etc. realisiere? Google empfiehlt sowohl cp als auch tar. dd hilft mir wohl in diesem Fall gar nicht weiter? Den Bootloader (grub im mbr) muss ich dann natürlich auch noch anpassen. Grüße, Jürgen
Frage: Nach dem ich hde und hdf neu partitioniert habe, wie übertrage ich dann am besten das komplette SuSE 10 auf eine der beiden Platten? Gehe ich recht in der Annahme, dass ich das am besten über knoppix etc. realisiere? Google empfiehlt sowohl cp als auch tar. dd hilft mir wohl in diesem Fall gar nicht weiter? Den Bootloader (grub im mbr) muss ich dann natürlich auch noch anpassen.
rsync -a -v /quelle /ziel sollte das tun, was du willst
Hallo, On Dec 1 15:27 Juergen Pabst wrote (shortened):
Nach dem ich hde und hdf neu partitioniert habe, wie übertrage ich dann am besten das komplette SuSE 10 auf eine der beiden Platten?
http://portal.suse.com/sdb/de/1997/09/maddin_kopieren.html ist zwar uralt, aber vom Grundprinzip her sollte das noch immer so in der Art funktionieren. Gruss, Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: jsmeix@suse.de 90409 Nuernberg, Germany WWW: http://www.suse.de/
Hallo, vielen Dank schon mal für die Tipps. Ist es denn egal, ob man es mit tar, rsync oder cp macht, getreu dem Motto "Viele Wege führen nach Rom"? Oder gibt es da jeweils Vor- und Nachteile, deren Kenntnisnahme vielleicht gut wäre? Grüße, Jürgen
Hi, Juergen Pabst schrieb:
[ ... ] Ist es denn egal, ob man es mit tar, rsync oder cp macht, getreu dem Motto "Viele Wege führen nach Rom"? Oder gibt es da jeweils Vor- und Nachteile, deren Kenntnisnahme vielleicht gut wäre?
Wenn es um eine ganze Partition geht, ist es aus Gründen der Datensicherheit IMHO empfehlenswert, einen Partitionsmanager auf bootfähiger CD zu verwenden, der sein eigenes Betriebssystem mitbringt und keine der Festplatten als Programm interpretiert, sondern alle als reine Daten. Habe z.B. mit Acronis PartitionExpert 2003 ausgezeichnete Erfahrungen gemacht, dagegen einige negative mit dem Kopieren innerhalb von Linux-Systemen, insbesondere mit "tar", weil die Daten dabei verändert werden. Bei "cp" kriegt man ggf. Rekursivitätsprobleme und "dd" dauert eine Ewigkeit; "rsync" habe ich erst gar nicht ausprobiert. MfG Wolfgang Gruhn
Wolfgang Gruhn, Donnerstag, 1. Dezember 2005 18:19:
Wenn es um eine ganze Partition geht, ist es aus Gründen der Datensicherheit IMHO empfehlenswert, einen Partitionsmanager auf bootfähiger CD zu verwenden, der sein eigenes Betriebssystem mitbringt und keine der Festplatten als Programm interpretiert,
Wer interpretiert denn Festplatten als Programme?
sondern alle als reine Daten.
Das tut Linux eigentlich immer, außer man will die Root-Partition wegkopieren. Dann sind es zwar immer noch reine Daten, aber man bekommt keine konstistente Kopie von manchen Dateien, weil sie sich ändern, während sie ausgelesen werden, oder evtl. auch gegen das Auslesen geschützt sind.
Habe z.B. mit Acronis PartitionExpert 2003 ausgezeichnete Erfahrungen gemacht, dagegen einige negative mit dem Kopieren innerhalb von Linux-Systemen,
Wenn Du von einer Knoppix bootest, dann kannste alles munter in der Gegend herumkopieren. Ebenso kannst Du alle Dinge umherkopieren, die gerade nicht in Gebrauch sind. Wenn Du also von einer anderen Partition gebootet hast als der, die Du kopieren willst, dann ist das überhaupt kein Problem.
insbesondere mit "tar", weil die Daten dabei verändert werden.
Kann tar nix dafür, wenn Du in Gebrauch befindliche Dateien kopierst, s.o.
Bei "cp" kriegt man ggf. Rekursivitätsprobleme und "dd" dauert eine Ewigkeit; "rsync" habe ich erst gar nicht ausprobiert.
dd ist denkbar ungeeignet, weil für einen ganz anderen Zweck konzipiert. tar ist gut, rsync auch. Dein oben vorgeschlagener "Partitionsmanager" tuts evtl. auch, aber v.a. deswegen, weil er wie jede Knoppix usw. von CD und eben nicht von der zu bearbeitenden Partition gestartet wurde. Aber ich wiederhole mich... Kann Dein Partitionsmanager auch mit allen Dateisystemen wie xfs, reiser, jfs usw. umgehen? -- Andre Tann
Wolfgang Gruhn wrote:
Erfahrungen gemacht, dagegen einige negative mit dem Kopieren innerhalb von Linux-Systemen, insbesondere mit "tar", weil die Daten dabei verändert werden. Bei "cp" kriegt man ggf. Rekursivitätsprobleme und "dd" dauert eine Ewigkeit; "rsync" habe ich erst gar nicht ausprobiert.
Aus dem hohlen Kopf heraus gesprochen: tar und cp ignorieren hardlinks, das kann den verwendeten Platz aufblähen. dd ist da (auch wenn langsam) besser, allerdings sollten die Partitionsgrössen übereinstimmen (wegen Platz und wegen der Blockgröße, wenn das Dateisystem mit veränderlicher Blockgröße arbeitet). Ob tar und cp Sonderfiles wie Pipes richtig kopieren, ist auch ne Frage (zumindest vor ein paar Jahren konnten sie es noch nicht, inzwischen hat sich da aber was getan). Und insbesondere bei den virtuellen Dateisystemen wie /proc und /sys (und /dev unter Linux, falls das inzwischen auch virtuell ist) könnte Mist herauskommen, aber die nutzlosen Kopien (wenn sie nicht zu gross sind, um die Platte zu verstopfen) werden vermutlich vom neuen virtuellen Dateisystem überdeckt. Aber die kann man ja auch vom Kopieren ausnehmen. rsync ist garnicht mal so schlecht, denn es kann mit hard links und devices umgehen, und vermutlich auch mit Rekursion. Wenn der Bootblock der Partition mitkopiert werden soll, kommt auch nur dd in Frage, oder man macht es hinterher per Hand Holger.
Holger Hellmuth wrote:
Wolfgang Gruhn wrote:
Erfahrungen gemacht, dagegen einige negative mit dem Kopieren innerhalb von Linux-Systemen, insbesondere mit "tar", weil die Daten dabei verändert werden. Bei "cp" kriegt man ggf. Rekursivitätsprobleme und "dd" dauert eine Ewigkeit; "rsync" habe ich erst gar nicht ausprobiert.
Aus dem hohlen Kopf heraus gesprochen: tar und cp ignorieren hardlinks, das kann den verwendeten Platz aufblähen. dd ist da (auch wenn langsam) besser, allerdings sollten die Partitionsgrössen übereinstimmen (wegen Platz und wegen der Blockgröße, wenn das Dateisystem mit veränderlicher Blockgröße arbeitet).
Ob tar und cp Sonderfiles wie Pipes richtig kopieren, ist auch ne Frage (zumindest vor ein paar Jahren konnten sie es noch nicht, inzwischen hat sich da aber was getan). Und insbesondere bei den virtuellen Dateisystemen wie /proc und /sys (und /dev unter Linux, falls das inzwischen auch virtuell ist) könnte Mist herauskommen, aber die nutzlosen Kopien (wenn sie nicht zu gross sind, um die Platte zu verstopfen) werden vermutlich vom neuen virtuellen Dateisystem überdeckt. Aber die kann man ja auch vom Kopieren ausnehmen.
rsync ist garnicht mal so schlecht, denn es kann mit hard links und devices umgehen, und vermutlich auch mit Rekursion.
Wenn der Bootblock der Partition mitkopiert werden soll, kommt auch nur dd in Frage, oder man macht es hinterher per Hand
Also, ick wees nich, watt ihr habt ... Ich habe kürzlich meine Installtion per tar von 3 Festplatten auf eine neue Große kopiert. Das einzige, was ich dann noch machen mußte war, die /etc/fstab anzupassen und den Bootloader zu reparieren. War also überhaupt kein Problem und läuft seitdem "immer noch" problemlos und besser als vorher. Gruß Martin
Hallo Holger, hallo Wolfgang, hallo Jürgen, hallo Leute, ich schick erstmal einen Link vorweg: 6.5. Wie kann ich einen kompletten Verzeichnisbaum auf eine andere Partition kopieren? http://suse-linux-faq.koehntopp.de/q/q-filesystems-kopieren.html Am Donnerstag, 1. Dezember 2005 19:16 schrieb Holger Hellmuth:
Wolfgang Gruhn wrote:
Erfahrungen gemacht, dagegen einige negative mit dem Kopieren innerhalb von Linux-Systemen, insbesondere mit "tar", weil die Daten dabei verändert werden.
Ich stimme der Vermutung von Andre zu, dass die Dateien beim Umkopieren gerade in Gebrauch waren - das ist aber nicht tar anzulasten. Wenn man z. B. /var/ oder gar / umkopieren will, empfiehlt sich das Booten eines Rettungssystems oder eine Knoppix.
Bei "cp" kriegt man ggf. Rekursivitätsprobleme
Nicht nur das - es ist eben nicht für diese Zwecke gedacht/geeignet. Ein weiteres Stichwort, das cp fehlt, ist --atime-preserve (siehe unten).
Aus dem hohlen Kopf heraus gesprochen: tar und cp ignorieren hardlinks, das kann den verwendeten Platz aufblähen.
Da bin ich anderer Meinung - ich habe vor kurzem mit tar eine Partition umkopiert, auf der mit StoreBackup eine Datensicherung erfolgt. Wer StoreBackup kennt, weiß, dass es bei unveränderten Dateien lediglich einen Hardlink erstellt. (Wer es nicht kennt, sollte sich mal 7.3. Storebackup: Backup auf Festplatte http://suse-linux-faq.koehntopp.de/q/q-backup-storebackup.html durchlesen ;-) Jedenfalls hatte die Partition einen Haufen Hardlinks und die Dateien belegten nach dem Kopieren auch nicht mehr Platz als vorher.
dd ist da (auch wenn langsam) besser, allerdings sollten die Partitionsgrössen übereinstimmen (wegen Platz und wegen der Blockgröße, wenn das Dateisystem mit veränderlicher Blockgröße arbeitet).
dd arbeitet eben komplett anders - es kopiert das komplette Dateisystem und nicht einzelne Dateien.
Ob tar und cp Sonderfiles wie Pipes richtig kopieren, ist auch ne Frage (zumindest vor ein paar Jahren konnten sie es noch nicht, inzwischen hat sich da aber was getan).
Ich hatte jedenfalls noch keine Probleme damit.
Und insbesondere bei den virtuellen Dateisystemen wie /proc und /sys (und /dev unter Linux, falls das inzwischen auch virtuell ist) könnte Mist herauskommen, aber die nutzlosen Kopien (wenn sie nicht zu gross sind, um die Platte zu verstopfen) werden vermutlich vom neuen virtuellen Dateisystem überdeckt. Aber die kann man ja auch vom Kopieren ausnehmen.
Eben. Oder man kopiert von einem Rettungssystem aus (ist beim Umkopieren des kompletten Systems sowieso sinnvoll), da sind solche Kandidaten erst gar nicht gemountet.
rsync ist garnicht mal so schlecht, denn es kann mit hard links und devices umgehen, und vermutlich auch mit Rekursion.
Die Frage ist, ob es auch sowas wie --atime-preserve (siehe tar) kann. Ansonsten wird es im Newsspool lebhaft zugehen... (@David: plauderst Du dazu ein wenig aus dem Nähkästchen? ;-)
Wenn der Bootblock der Partition mitkopiert werden soll, kommt auch nur dd in Frage, oder man macht es hinterher per Hand
Ich tendiere zu letzterem - ein Aufruf von grub-install ist nicht schwer und _deutlich_ angenehmer als ein Vertipper beim dd-Aufruf *g* Gruß Christian Boltz --
Auch meinen Namen aus der Liste streichen... Wollen wir mal darueber abstimmen, ob es fuer Linux von Vorteil war, von einem Produkt der Verstaendigen zum Produkt fuer den Massenkonsum zu werden? (-; [Bodo Kaelberer in suse-security]
Hallo, Am Donnerstag, 1. Dezember 2005 23:35 schrieb Christian Boltz:
Hallo Holger, hallo Wolfgang, hallo Jürgen, hallo Leute,
Am Donnerstag, 1. Dezember 2005 19:16 schrieb Holger Hellmuth:
Wolfgang Gruhn wrote:
Bei "cp" kriegt man ggf. Rekursivitätsprobleme
Keine Ahnung was "Rekursivitätsprobleme" sind. mit cp -x bleibt es im Filesystem
Nicht nur das - es ist eben nicht für diese Zwecke gedacht/geeignet. Ein weiteres Stichwort, das cp fehlt, ist --atime-preserve (siehe unten).
Laut info cp: cp -p /* Using `--preserve' with no ATTRIBUTE_LIST is equivalent to `--preserve=mode,ownership,timestamps'. */ Funktioniert das nicht? Gruß Harald
Hallo, On Friday 02 December 2005 00:16, Harald Huthmann wrote:
Bei "cp" kriegt man ggf. Rekursivitätsprobleme
Keine Ahnung was "Rekursivitätsprobleme" sind. mit cp -x bleibt es im Filesystem
Nicht nur das - es ist eben nicht für diese Zwecke gedacht/geeignet. Ein weiteres Stichwort, das cp fehlt, ist --atime-preserve (siehe unten).
Laut info cp: cp -p /* Using `--preserve' with no ATTRIBUTE_LIST is equivalent to `--preserve=mode,ownership,timestamps'. */
Funktioniert das nicht?
Also ich verwende immer cp -a <Quelle> <Ziel> wenn ich komplette Partitionen kopieren will. "cp -av ..." wenn ich sehen will was er gerade so treibt. Gruss Petric
Hallo, Am Fri, 02 Dec 2005, Petric Frank schrieb:
On Friday 02 December 2005 00:16, Harald Huthmann wrote:
Laut info cp: cp -p /* Using `--preserve' with no ATTRIBUTE_LIST is equivalent to `--preserve=mode,ownership,timestamps'. */
Hm. Weiss nicht ob das reicht. ACLs sind da wohl nicht dabei, aber ich weiss nicht, ob neuere (SuSE-)GNU-Tars ACLs koennen...
Funktioniert das nicht?
Also ich verwende immer cp -a <Quelle> <Ziel>
Ist aequivalent zu 'cp -dpR' und AFAIK nicht ausreichend. Siehe meine mail nach C. Boltz und die FAQ. Ich habe jedenfalls mit 'cp -a' keine guten Erfahrungen gemacht. -dnh --
Dann wird aber alles daran gesetzt worden sein, dass da kein Bourne Again Shell (/bin/bush) drauf läuft. Ein Blick nach Faludscha sagt mir, dass es sich bei der /bin/bush eher um eine sogenannte "Burn again"-Shell handelt. [aus de.comp.security.misc]
Hallo, Am Thu, 01 Dec 2005, Christian Boltz schrieb:
6.5. Wie kann ich einen kompletten Verzeichnisbaum auf eine andere Partition kopieren? http://suse-linux-faq.koehntopp.de/q/q-filesystems-kopieren.html
Jup. LEUTE, BITTE LEST DIE FAQ!!! Wir haben da zwar noch ne kleine interne Diskussion (zu den Gruenden, s.u.), aber ich war in letzter Zeit nicht fit genug, da was zu zu schreiben. Ich bemuehe mich das zu ergaenzen, insbesondere zu: ==== Zitat aus der FAQ q-filesystems-kopieren.html ==== Die in den oben genannten Befehlen verwendeten Optionen weichen etwas von den in der SDB genannten ab. Gründe hierfür: * --numeric-owner ist beim lokalen Kopieren überflüssig und kann bei Kopieren über SSH u. U. sogar unerwünscht sein, falls die User-IDs abweichen * -S (--sparse) hat in Einzelfällen (laut David Haller) schon zu kaputten Dateien geführt. ==== Apropos: ich werde mich auch bemuehen, das mit der SDB zu synchronisieren (zu lassen) (d.h. mit diesen beiden Artikeln: http://portal.suse.com/sdb/de/1997/09/maddin_kopieren.html http://portal.suse.com/sdb/de/1999/04/neue_hd.html ). Konkret zu "-S": mir hat's da mal mit '-S' ne Datei total verzwirbelt ich weiss aber leider nicht mehr ob das ne spezielle (device, fifo, socket) oder ne sparse-Datei war oder ne normale... Naja, ich habe sowieso praktisch keine "sparse" Dateien auf meinen Platten... Speziell bei Interesse werde ich das aber mal versuchen nachzustellen. Das ist aber eben recht aufwaendig. Das mit dem "verzwirbeln" koennte allerdings auch ein Bug in meinem uralt tar sein, der inzwischen behoben wurde, das wuerde ich dann unter der auch installierten SuSE 9.1 testen. Man kann '-S' aber wohl durchaus verwenden, sollte dann aber sicherheitshalber wohl Quell- und Zieldateien vergleichen. Hilfe beim austesten waere nett ;) Achso, mein "Urteil" erlaube ich mir - obwohl ich nur ext2/3 sowie reiserfs verwende(t habe), bei XFS/JFS/... koennen ggfs. andere Tools noch relevant sein (xfsdump z.B.). Bzgl. der Standardtools, speziell 'cp' und die diversen Dateimanager wie konqueror, mc usw. gilt meine Erfahrung aber. - weil ich mein nach wie vor laufendes System seit Sommer '99 (also seit ~6 1/2 Jahren) auf inzwischen die IIRC (mind.) 6te Festplatte umgezogen habe, und dabei sogar noch oefter die /-Partition gewechselt habe. Von anderen Partitionen (u.a. /var, /usr) ganz zu schweigen... Und inzwischen ist das System auch problemlos auf zwei 160 GB Festplatten verteilt, allerdings eben schon laenger mit 2.4.2[45]er Kernelversionen[1] statt dem urspruenglichen 2.2.10. Mein BIOS ist uebrigens "Release: 11/17/99"... (und das System hatte ich noch auf der alten HW installiert, MoBo, CPU, RAM habe ich IIRC im Sommer '00 gekauft)...
Am Donnerstag, 1. Dezember 2005 19:16 schrieb Holger Hellmuth:
Wolfgang Gruhn wrote:
Erfahrungen gemacht, dagegen einige negative mit dem Kopieren innerhalb von Linux-Systemen, insbesondere mit "tar", weil die Daten dabei verändert werden.
Ich stimme der Vermutung von Andre zu, dass die Dateien beim Umkopieren gerade in Gebrauch waren - das ist aber nicht tar anzulasten.
Wenn man z. B. /var/ oder gar / umkopieren will, empfiehlt sich das Booten eines Rettungssystems oder eine Knoppix.
ACK. Es geht zwar auch "so", in dem man in den Single-User bootet und '/' nur ro mounten laesst (und alles andere erst gar nicht) und dazu dann nur die Zielpartition fuer's neue '/' dazu mounted... Bei '/var' gilt das gleiche sogar noch verschaerft (wg. /v/l/m z.B.). Das sollte man aber nur machen, wenn man weiss was man tut. Und wenn man ein getestetes(!!!) Backup hat. Kurz: man sollte es vom Rettungs- oder einem Live-System wie Knoppix aus machen. Und in der Ramdisk dieser System kann man ja auch voellig ungeniert in / Mountpunkte, z.B. /OLD und /NEW erstellen ;) 'sync; sync' nach dem kopieren und 'umount' hinterher nicht vergessen... (Hm, das 'sync; sync' sollte auch in die FAQ ;)
dd ist da (auch wenn langsam) besser, allerdings sollten die Partitionsgrössen übereinstimmen (wegen Platz und wegen der Blockgröße, wenn das Dateisystem mit veränderlicher Blockgröße arbeitet).
dd arbeitet eben komplett anders - es kopiert das komplette Dateisystem und nicht einzelne Dateien.
Von dd kann ich fuer o.g. Zweck auch nur abraten. Einfach wg. der voellig ungeeigneten Funktionsweise. Stichwort "know thy tools" ;)
Ob tar und cp Sonderfiles wie Pipes richtig kopieren, ist auch ne Frage (zumindest vor ein paar Jahren konnten sie es noch nicht, inzwischen hat sich da aber was getan).
Ich hatte jedenfalls noch keine Probleme damit.
Dito. s.o. tar ist IMO das Tool der Wahl. BTW: $ tar --version tar (GNU tar) 1.12 $ fmt='%{name}-%{version} %{distribution} %{installtime:date}\n' $ rpm -q --queryformat "$fmt" -f `which tar` base-99.8.7 SuSE Linux 6.2 (i386) Sat 04 Dec 1999 06:58:05 PM CET $ unset fmt (Ja, das "base"-RPM hab ich nochmal nachinstalliert, ich hab damals noch _SEHR_ viel gebastelt ;) Jedenfalls: mit diesem "uralt" tar habe ich bisher alles "umgezogen". Hm. Ne >2G Datei aber IIRC noch nicht, ich hab bisher nur eine (ein Image meiner /home-Partition...) Sollte ich mal testen ;). Aber keine Sorge: auf allen Linux-Distris, wo es nicht sowieso nur Probleme mit grossen Dateien gibt, wo also z.B. 'ls' usw. schon die korrekten Dateigroessen angeben, dort sollte das jew. tar mit diesen Dateien auch korrekt umgehen. Das zu testen schadet allerdings nicht. Aber tar ist ja per default "nicht-destruktiv" und die u.a. in der FAQ genannte Vorgehensweise empfiehlt ja auch, die Quellen erst zu loeschen, wenn man die Ziele ueberprueft hat.
Eben. Oder man kopiert von einem Rettungssystem aus (ist beim Umkopieren des kompletten Systems sowieso sinnvoll), da sind solche Kandidaten erst gar nicht gemountet.
ACK.
rsync ist garnicht mal so schlecht, denn es kann mit hard links und devices umgehen, und vermutlich auch mit Rekursion.
Die Frage ist, ob es auch sowas wie --atime-preserve (siehe tar) kann.
Kann das mal jemand ausprobieren, ob rsync die atimes veraendert? Die man- und infopage von rsync schreiben nix zu 'atime'... /foo/bar/baz $ TZ=UTC touch -amc -d 19700101 EINE_INSEL /foo/bar/baz $ TZ=UTC ls -l --full-time --time=atime EINE_INSEL [Hier jetzt mir rsync die Datei /foo/bar/baz/EINE_INSEL mit rsync woanders hin kopieren -- da ich rsync nicht verwende ... ] /woanders/blubb $ TZ=UTC ls -l --full-time --time=atime EINE_INSEL
Ansonsten wird es im Newsspool lebhaft zugehen... (@David: plauderst Du dazu ein wenig aus dem Nähkästchen? ;-)
Man nehme einen leafnode-newsspool in /var/spool/news, mit einigen Gruppen, vorzugsweise mit vieel Traffic (dana z.B.), in die man mal reingelesen hat, und die man mit einer langen Haltezeit ("expire" / "groupexpire" hoch) versehen hat, so dass man von diesen Gruppen noch ein paar (1 reicht) Nachrichten uebrig hat, z.B. von vor einem halben Jahr... Dass man die Gruppe mal hatte hat man natuerlich schon laengst vergessen, denn aktiv wird die Gruppe natuerlich schon lange nicht mehr gelesen... So. Und dann kopiert man den newsspool mal eben um... Ohne o.g. bzgl. '--atime-preserve' zu beachten, z.B. mittels 'mc' oder 'cp -a'... Und beim naechsten holen von Gruppen wundert man sich, warum das so lange dauert... Und bis man's kapiert hat man schonmal ne Einwahl und einige MB Traffic vergeudet... Weil alle Gruppen, von denen noch was im newsspools war, auf einmal wegen der frisch gesetzten atime durchs kopieren wieder auf "Gruppe wird gelesen" (aka "active") sind... Und auch bei Gruppen, die man aktiv liest kommen (IIRC) u.U. auf einmal wieder viele schon gelesene Nachrichten neu... Generell gilt IMO beim "Umziehen", dass man _alle_ Zeitstempel unangetastet lassen sollte. Denn man will die Dateien "logisch" ja nicht angefassen (wie z.B. mit nem 'less' oder per newsreader), sondern will sie nur moeglichst ohne jede Nebenwirkungen, "voellig unbemerkt" in eine andere Partition bewegen. Oder? Beim Backup _kann_ eine geaenderte atime allerdings gewuenscht sein (als Auswahlkriterium fuer den naechsten Backup-Lauf)... Es sollte also auf jeden Fall per Option steuerbar sein.
Wenn der Bootblock der Partition mitkopiert werden soll, kommt auch nur dd in Frage, oder man macht es hinterher per Hand
Bootbloecke per dd kopieren zu wollen ist (mit Verlaub) eine extrem daemliche Idee. Ja, der Wunsch und die Umsetzung scheinen nahe zu liegen. Aber es ist eigentlich immer Unfug (mal mehr, mal etwas weniger grober)... (Details/Argumentation auf Nachfrage) Jeder Bootmanager/-loader der diese Bezeichnung verdient (also der von DOS/Windows[2] nicht) laesst sich auch woanders als nur im MBR installieren. \begin{WavyLines} Ich habe IIRC (kann sein, dass ich noch welche vergessen habe): - Grub im MBR (also /dev/hda) (mein altes LILO scheint die neuen >127 GB Platten nicht zu moegen), das Grub ist neuer. Eigentlich gehoert da ein LILO hin, bzw. war dort bis der dann die neuen 160 GB Platten (die erste als hdc, die zweite als hdb eingebaut) nicht mehr booten wollte - Grub in /dev/hdc (Config von der SuSE 9.1) - Grub in /dev/hdcX ('/' der 9.1) - Grub in /dev/hdb (Config von habbich vergessen) - ... (noch diverse LILOs/GRUBs mehr an diversen freien Stellen ;) Oder so aehnlich ;) Die drei erstgenannten koennen sich alle gegenseitig via 'chainloader' laden ;) Ich kann also (endlos) durch die verschiedenen "GRUBs" huepfen... BIOS -> GRUB(hda) -> GRUB(hdb) -> GRUB(hdc) -> GRUB(hda) -> GRUB(hdc) -> GRUB(hdb) -> GRUB(hda) -> ... bis einem langweilig wird... ... oder bis die Kiste verreckt... *tuedelluet* Aeh, die GRUBs haben natuerlich alle auch andere Eintraege als die jew. anderen GRUBs... Und nicht jede Variante ist von jedem GRUB aus zu erreichen... Bei der Inst. der 9.1 habe ich Yast den Grub nur in deren /-Partition schreiben lassen, hab mir die Orte/Parameter dort abgeschaut und in den Haupt-Grub kopiert (mit Anpassungen)... Oder ist das der GRUB in hdb? oder hdc? Jedenfalls war der Ziel-BR leer ;) Ja, alles "leicht" chaotisch, historisch bedingt, aber egal. Et löppt. Ich blick durch (mit nachschauen (ggfs. per 'dd if=/dev/hdXY | hexdump' *hehe*)... Und ggfs. editiere ich eben irgendne Config... Oder starte Grub auf dessen Kommandozeile beim booten passend... *g* Meine zweite Bootconfig mit Linux war (IIRC): a) Vamos + DOS + LOADLIN und parallel dazu: b) Vamos + LILO in /dev/hdb4(!) und '/' in /dev/hdb6... (hdb5 war swap). Ja, ich hatte in den ersten Sektoren der erweiterten Partition hdb5 (Typ 0x05) eben den Platz fuer LILO und Vamos konnte den LILO dort starten. YAST konnte mir dieses Setup allerdings nicht einrichten. ...oder war die Kombi-Loesung mit Loadlin die mit Debilian 1.3 ein Jahr frueher??? \end{WavyLines} *hihi* *pfeif* *floet* \begin{mode}[DURCHSAGE] *DING DOINNG DONNNGGGGG* ACHTUNG! WIR BITTEN UM IHRE AUFMERKSAMKEIT! Dies ist eine Warnung zur Wahrung Ihrer geistigen Gesundheit! OBIGES (\begin{WavyLines} bis \end{WavyLines}) IST NICHT UND IN KEINSTER WEISE ZUR NACHAHMUNG EMPFOHLEN!!! ES GEFAEHRDET IHRE GEISTIGE GESUNDHEIT! Vielen Dank fuer Ihre Aufmerksamkeit. *DING DOINNG DONNNGGGGG* \end{mode} *ueberrascht und gaaanz unschuldig guck* Bei Interesse kann ich auf Details eingehen, aber da bitte ich darum die LILO-Doku (user.{txt,dvi} und tech.{txt,dvi}) und Grub Doku (info grub) zu lesen... Vorweg: ja, es gibt Sonderfaelle wo man _TEILE_ von Bootcode auslesen/kopieren sollte. Man sollte aber _GENAU_ wissen was man wie und wann wohin kopiert...
Ich tendiere zu letzterem - ein Aufruf von grub-install ist nicht schwer und _deutlich_ angenehmer als ein Vertipper beim dd-Aufruf *g*
ACK. Und ein 'lilo -v' ist auch einfach ;) Die /etc/fstab, die /etc/lilo.conf bzw. die /boot/grub/menu.lst und ggfs. /boot/grub/device.map muss man ja sowieso anpassen. -dnh, die passende sig rausgreppend [1] 2.4.0-test4 seit Aug 3 2000, 2.4.16 seit Dec 14 2001, 2.4.24 seit Jan 28 2004 und 2.4.25 seit Mar 2 2004. IIRC war der Umstieg .16 auf .24 wegen der ersten 160GBer Festplatte. Davor gab's _einige_ 2.2.12 und .14 Versionen (ausgeloest durch den MoBo/CPU-Tausch)... [2] wie's da mit dem von NT/2k/XP aussieht weiss ich nicht, AFAIR ist der zwar wesentlich weitgehender konfigurierbar aber nach wie vor nur in den MBR installierbar. -- Naja, zumindest war Maxtor "weitsichtig": mit einer 48bit-Adressierung kann man 134217728 GB (128 Petabyte) ansprechen, das sollte eigentlich fuer ein paar Jaehrchen reichen, oder? ;)) [David Haller in suse-linux]
Hallo David, Respekt, wozu du morgens um 5 Uhr so in der Lage bist! ;-)
LEUTE, BITTE LEST DIE FAQ!!!
Geht klar, deren Existenz war mir nur kurzzeitig nicht mehr präsent. Mich interessiert nur eine Sache noch kurz, und zwar:
Kurz: man sollte es vom Rettungs- oder einem Live-System wie Knoppix aus machen. Und in der Ramdisk dieser System kann man ja auch voellig ungeniert in / Mountpunkte, z.B. /OLD und /NEW erstellen ;)
'sync; sync' nach dem kopieren und 'umount' hinterher nicht vergessen... (Hm, das 'sync; sync' sollte auch in die FAQ ;)
Was hat es denn mit "sync; sync" auf sich? Vor allem die Syntax verwundert mich ein wenig. Grüße, Jürgen
Am Freitag, 2. Dezember 2005 14:17 schrieb Juergen Pabst:
Hallo David,
Respekt, wozu du morgens um 5 Uhr so in der Lage bist! ;-)
LEUTE, BITTE LEST DIE FAQ!!!
Geht klar, deren Existenz war mir nur kurzzeitig nicht mehr präsent.
Mich interessiert nur eine Sache noch kurz, und zwar:
Kurz: man sollte es vom Rettungs- oder einem Live-System wie Knoppix aus machen. Und in der Ramdisk dieser System kann man ja auch voellig ungeniert in / Mountpunkte, z.B. /OLD und /NEW erstellen ;)
'sync; sync' nach dem kopieren und 'umount' hinterher nicht vergessen... (Hm, das 'sync; sync' sollte auch in die FAQ ;)
Was hat es denn mit "sync; sync" auf sich? Vor allem die Syntax verwundert mich ein wenig.
nun ja ein "sync" sollte reichen. Es zwingt das Betriebsystem die Dateisytem-Puffer auf die Platte zu schreiben. sync;sync hier werden einfach nur 2 Sync's hintereinander gemacht. Etwas für die ängstlichen unter uns :-) Zur Syntax: cmd1 ; cmd2 führt das Programm cmd1 aus, und nach dessen Ende cmd2 (s. man bash) Bye Jürgen -- Dr.rer.nat. Juergen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de Internet-Telefonie: www.skype.com Benutzer: juergen.vollmer
participants (13)
-
Andre Tann -
Christian Boltz -
David Haller -
Dominik Klein -
Dr. Jürgen Vollmer -
Harald Huthmann -
Holger Hellmuth -
Johannes Meixner -
Juergen Pabst -
Martin Deppe -
Petric Frank -
Philipp Thomas -
Wolfgang Gruhn