hej Florian,

schnelle Antwort, danke.
An einer um ein paar MB’s unterschiedlichen Grösse sollte es nicht liegen, denn vor ca. 1 Jahr hat es mit 2 Seagates unterschiedlichen Herstellerdatums auch geklappert.
Acronis kann mit den modernen fs wie reiser, ext2/3 umgehen, es kopiert einfach Sektor für Sektor rüber.
Deinen Tipp, die Device-Angabe auf …sda6 zu setzen probiere ich evtl. noch heute Abend aus und werde berichten. Ansonsten kann ja schiefgehen was will, ist derzeit ja keine Produktivplatte….
Werner

so, bin nun mit knoppix fromhd unterwegs…
die fstab habe ich geändert, hier wimmelt es von Samsung-Einträgen. Ich habe nur die sda6 für / , sda7 für /swap und die sda8 für /home umgeschrieben, den Rest würde ich später mit YAST erledigen.
Nach dem booten kamen recht bald die selben dummen Fragen wie vorher…
Vielleicht sollte ich nun deinen Tipp mit den labels versuchen, sehe aber wenig Erfolg wenn schon eine völlig “normal” aussehende fstab nichts bringt.

Das Problem scheint mir genereller Natur zu sein, egal ob mit Acronis oder dem unix Befehl dd klont: es werden immer ungleiche Plattendaten vorliegen, es sei denn, man hat 2 exakt gleiche.

Wenn alle Stricke reissen wende ich meine Methode an, mit der ich Neuinstalltionen durchführe: vom aktuellen System eine komplette Dasi incl. aller /.xyz, die werden sofort nach Neuinstalltion wieder ins /home/xyz/. kopiert, und ratzfatz sind alle Anwendungen konfiguriert. D.h. der ganze Zauber dauert ca. 1 Stunde.

Hi Werner,

Du solltest zum eine alle Einträge ändern, da macht YaST auch nichts anders. Anschließend solltest Du evtl. noch die initrd einträge mit mkinitrd aktualisieren.

Ciao
Ulf

hej Florian und Ulf,

inzw. habe ich die fstab und die menu.lst manuell umgeschrieben, so wie man es schon zigmal gemacht hat, und siehe da, beim booten kommt Suse schon ein ganzes Stück weiter, bis dann doch wieder ein Heimweh nach Samsung kommt.
Per Knoppix habe ich mal die Partition /root nach dem Wort SAMSUNG durchsucht, puh, mir wurde schwindelig, und schlagartig verliess mich die Lust, die alle umzuschreiben, es müssten vorher diverse Dateirechte geändert werden usw.

Tabula rasa, ich habe Ubuntu7.10 auf sda10+11 installiert und schon 3/4 konfiguriert, 6+8 mit ext3 formatiert, da kommt demnächst DreamLinux 3.0 drauf, sda7 ist die zentrale swap. Auf DL freue ich mich besonders.

Zusammenfassung: offensichtlich ist es mit Bordmitteln nicht möglich, schnell mal eben eine Platte zu klonen, ausser sie sind absolut gleich.
Zukünftig werde ich beide Platten im vierteljährlichen Wechsel ranhängen und auf diese Weise frisch halten.
Ein Dank an euch beide für die spontanen Ideen,
Gruss
Werner

Hi Werner,

häää….??? Ich hatte beim Clonen (zwar nur erst ein paar mal gemacht aber) noch nie Probleme gehabt. Insbesondere nicht mit openSUSE 10.x. Einfach Clonen, fstab anpassen und im Extremfall mit der Installations-CD/DVD gebootet und dort in einem chroot mit anschließendem mkinitrd gestartet. Wenn Du Dir das nicht zutraust, kannst Du ja auch von der CD/DVD die Installation Prüfen lassen, dann ändert openSUSE automatisch die nicht passenden Einträge und Programme.

PS: Es lohnt sich um die Reperaturchangsen zu erhöhen im YaST unter System eine “Sicherungskopie der Systembereiche” durch zu führen. Anschließend steigen die Changsen ungemein ein madiges System wieder zum laufen zu bekommen. Hat mir auch schon gehelft ;-) …

Ciao
Ulf

richtig Ulf, ich habe es vor ca. 1 Jahr mit 0 Probs auch geschafft, damals waren beide Platten aus dem Stall Seagate.
Wie gesagt, ich habe gleich nach dem Clonen auch die Suse Rettungsroutinen benutzt, mit denen man normalerweise gute Erfolge erzielt, sie stiegen immer an der gleichen Stelle aus, das System blieb einfach stehen, 2 LED’s rechts auf dem keyboard blinken.
Ich kam also weder an das geclonte Suse noch Ubuntu heran, einzig mit knoppix fromhd konnte ich etwas erreichen.

Bei dieser Art meiner Dasi müsste ich den ganzen Kasperkram dann vierteljährlich machen, dazu habe ich einfach keine Lust. Ich richte jetzt die Reserveplatte zu Ende ein und werde sie abwechselnd ans mainboard hängen, das einfachste von der Welt.
Trotzdem werde ich eure Tipps aufbewahren und das ganze mal an einem Regentag wiederholen.
Danke
Werner

Bei mir ging das Klonen von einer 80GB auf eine 120GB HD ohne Probleme. Die Anzahl Heads und Sektoren war gleich, nur die Tracks unterschiedlich. Beide waren im erweiterten 48bit Adressierungsverhalten auch gleich.

hej Dieter,
du bist einer der Linux-Kapazitäten, hast du denn eine Idee, was bei mir falsch läuft? Die CHS-Werte liegen auch bei mir gleich.
Ich wiederhole, vor 1 Jahr, als beide Platten Seagate hiessen, ging’s, und jetzt stören sich Ubuntu & Susi an dem Wort SAMSUNG.
Gibt es einen geheimen Startparameter wie etwa “find new hd” oder so ähnlich?
Es sind ja ganz eindeutig die übertragenen falschen Plattennamen, die den Affentanz auslösen.
Eigentlich habe ich mich schon entschieden. Ausser dem perfekt geclonten XP kommen auf die Reserveplatte Ubuntu 8.. und Suse 11 zum Einsatz, auf der Produktivplatte wird Ubuntu 7.10 durch DreamLinux ersetzt, ferner kommt Suse 11 dazu.
Dann werden die Platten monatlich kurz ausgetauscht und aktuell gehalten, diese Kasperei will ich nicht wieder erleben.
Gruss
Werner

Hallo Werner,
kopiert hatte ich die Platten mit dd (als purist), die andere war über USB-IDE Adapter angeschlossen. Beide Samsung (mit einer anderen 160er ging es auch). Mein erster Versuch war beide Platten gleich zu Partitionieren. Mit fdisk zeigte sich, dass das nicht geht wegen ein paar kleinen Details in der Adressierung. Es ergeben sich kleine Lücken auf Grund Ganzzahligkeitsproblemen (Anzeige in 512byte Blöcken, wählen und dann eifrig vergleichen). Das hängt mit den Tricks zusammen größere Festplatten vom BIOS zu fassen. Es hängt mit dem CHS zusammen, das auch Linux mit verwendet. Auch testdisk verwendet die Parameter auch und konnte auf einer HD mit einem Fehler auch nicht weiter helfen. Diese hatte WinXP geschrottet, wegen einem Unterschied in der Adressierung, wo der letzte Cylinder nicht genutzt werden kann, nach Umsetzen in anderes Motherboard.
Ich habe die Festplatte komplett kopiert und damit hatte ich auch die Partitionstabelle 1:1 übertragen. Somit hatte die neue Festplatte dann auch nur noch 80GB statt 120GB. Ich habe hda1 2GB WinXP_Recovery_hidden, hda2 WinXP, hda4 erwPart, hda5..10 logPart. Da die beiden ersten primären Partitionen insgesamt unter der 32GB Grenze lagen, konnte ich mich aus der Problem herauswinden, indem ich die erweiterten Partitionen löschte und diese neu aufsetzte. In diese habe ich dann die einzelnen Partitionen mit dd hinüberkopiert. Aufgrund der kleinen Verschiebungen zeigt der Vektor im MBR dann nur wenige 512bytes daneben. Auf einer der freien neuen Partitionen (war ja ne größere Festplatte) installierte ich Ubuntu 6.06 (man kann sich auch mal mit Zweckenfremdung der SWAP behelfen, wenn man nur Minimalinstallation ohne jedigliche Grafik, und alle Pakete abwählt macht, wenn die Festplatte nicht größer ist) und dessen Grub. Dieser fand alle, das WinXP, und alle anderen Linuxe (9.3, 10.1) wieder. Diese kann ich nun wieder booten. In dem Zustand kann auch das Grub der anderen Linux wieder repariert werden. D.h. der MBR zeigt auf den Maschinencode des zuletzt installierten, bzw reparierten Linux-Grub. Das Repair ist aber oft nicht so leicht zu finden und funktioniert meist nur richtig in der Terminalsession (X11, KDE, Gnome beendet init 3 bei Suse, bei Debian unterschiedlich). das Filesystem muß mit einer Option, die das besonders efektivePacken von kleinen Dateien in Cluster abschaltet (-o notail,noatime, ggf auch das journaling abschalten) gemounted sein. Gleiches gilt für das editieren der menu.lst, devices von Grub. Oft passiert nichts, wenn die Datei danach nicht der nächsten 512byte Grenze zu nahe kommt.
Sorry habe etwas weit ausgeholt. Ich habe noch eine 160GB HD und da steht mir das bevor, wenn ich doch noch beschließe diese einzubauen.

[1] http://de.wikipedia.org/wiki/MBR
[2] http://de.wikipedia.org/wiki/Partitionstabelle
[3] http://de.wikipedia.org/wiki/Integrated_Drive_Electronics

Beim nochmal durchlesen – übersehen habe ich, dass bei mir ein etwas anderes Problem vorlag (größere Festplatte). Somit ist es etwas anders verlaufen.

Hi Werner,

Ubuntu und Susi stören sich nicht an dem Wort SAMSUNG – sondern an Deiner eindeutigen Platten ID. In der ist natürlich der Hersteller mit drin. Das wird auch nur zum Booten benötigt (also in der initrd), und nicht von Linux selber. Du must also nur die initrd neu erstellen.

Das Problem welches Dieter beschreibt liegt etwas anders, denn die Daten sollten im Image schon Hardware neutral vorliegen (dann kann man Sie auch per loopback mounten). Genau diese Hardwareschicht versucht man ja beim Bilden des Image zu neutralisieren.

Hast Du denn das mit dem von CD/DVD gebooteten Rescue System denn schon einer Reperatur zumindest auf die Susi gemacht? Das sollte eigentlich schon helfen, ansonsten wie gesagt initrd neu ersellen.

Ciao
Ulf

PS: Einen guten Artikel zu diesem Thema findest Du im übrigen in der c’t 06/2008 ab Seite 168 mit dem Titel Erste Hilfe – Daten retten und Dateisysteme reparieren mit Knoppix

hej Ulf,

ich habe mal die initrd von Ubuntu nach Suse rüberkopiert und dort zerlegt, ist ja hochinteressant was man da alles so wiederfindet, ich habe das zum erstenmal gemacht.
Z.B. die Device-Angaben von weiter oben:

ROOT=”/dev/disk/by-label/${ROOT#LABEL=}”
;;
UUID=*)
ROOT=”/dev/disk/by-uuid/${ROOT#UUID=}”

Das Wort Samsung findet sich nur in einer ellenlangen Geräteauflistung wieder, kann somit tatsächlich nicht der ursächliche Störenfried sein.
Nun habe ich folgenden Schlachtplan zurechtgelegt.
Ich werde das Spielchen jetzt nicht wiederholen, sondern die Reserveplatte, auf der aktuell nur XP funktioniert, aufrüsten mit Ubuntu 8 demnächst, DreamLinux oder Suse 11, je nach Reihenfolge des Erscheinens, alles komplett konfigurieren.
Knoppix fromhd ist schon drauf auf sda12.
Danach mit Acronis oder dem dd Befehl die fertige Reserveplatte auf die jetzt noch Produktivplatte clonen. Von dort werde ich vor dem Plattmachen die beiden initrd’s auf usb kopieren.
Dann geht es los.
Entweder diese initrd’s an die jeweils richtige Stelle kopieren, oder mit dem von dir oben gesagten Kommando mk initrd eine neu ramdisk erstellen usw.
Es sollte doch mit dem Teufel zugehen, wenn das nicht fluppt.
Für die Zeit danach, wenn’s denn gefluppt haben sollte, bin ich trotzdem daran gebunden, die Reserveplatte alle paar Wochen ranzuhängen….

Es sieht so aus, als wenn draussen jetzt erstmal Gartenarbeit angesagt ist, ich habe aber den kompletten Schriftverkehr hier gespeichert und komme später drauf zurück.
viele Grüsse
Dieter und dir
Werner

Hi Werner,

nach dem umziehen auf die neue Platte, musst Du eigentlich nur wie gesagt die /etc/fstab anpassen und ein erneutes mkinitrd durchführen. Dieses packt dann die neu Laufwerkszuordnung in die RAM-Disk. Danach sollte es eigentlich klappen.

OT / PS: Gartenarbeit? – Mußt Du dort Schneeschippen? – Bei uns liegt im Garten ca. 20cm Schnee ;-)

Ciao
Ulf

mit so viel Munition gehe ich an die Plattenarbeit, wird aber erst Anfang Mai…

OT: Schnee, wie furchtbar, dann musst du im Süden wohnen, was bei dir weiss ist, ist hier nördl. von HH grün: Moose satt…
ciao

Hi Dirk,

RAID ist eine feine Sache, fängt aber nur ein teil der Fehler ab. Ich habe mich eigentlich gegen RAID entschieden, da ich als Privatman keine 100% Verfügbarkeit benötige. Fahre momentan mit storeBackup ein recht Resorcen schonendes Backup welches (bei mir 30Tage) auch alle zwischenversionen Abspeichert. So kann man auch noch nach drei Tagen eine fälschlich gelöschte oder geänderte Datei zurück kopieren und evtl. noch entpacken. Ein super Tool, welches sich Bei mir über mehre Jahre und einige Festplattenkrashes bewährt hat. Siehe auch Diskusion auf [1] und in anderen Artikeln [2].

Ciao
Ulf

[1] https://www.linux-community.de/Neues/story?storyid=21883&commentid=56961&order=location#56961
[2] https://www.linux-community.de/Suche/dosearch?type=0&text=storeBackup&searchtitlebody=3&fromday=1&frommonth=1&fromyear=2000&today=31&tomonth=3&toyear=2008

Dass RAID kein Backup ersetzt, ist klar. Ich war nur der Meinung, dass du ein Image machst, weil du nach einem Systemcrash schnellstmöglich ohne großartige Neukonfiguration ein neues System inclusive Daten haben möchtest.
Für ein Daten-Backup ist ein Image ja eher schlecht zu gebrauchen, weil eben der “leere” Speicher immer mitkopiert wird. Da ist ein simples Rsync oder eben dein storeBackup besser geeignet. Aber da sag ich dir ja nix Neues :-)

Ich selber löse das bei mir so, dass ich alle paar Wochen mal die wichtigen Daten aus meinem Homeverzeichnis und das etc-Verzeichnis als Multivolume-Tar-Archiv auf DVD brenne…

hej Dirk,

mit RAID habe ich mich noch nicht intensiv beschäftigt, ein Nachbar hat damit immer wieder Ärger.
Meine Denke ist genau die von Ulf: nach einem crash schnell wieder flott sein, heutzutage ist man ja ohne solche Kiste aufgeschmissen. Diese Vorgehensweise habe ich als für mich optimal “erlernt”.
Wie gesagt, ca. im Mai werde ich das Spielchen wiederholen, hier empfohlene Tipps anwenden und berichten.

hej Ulf und Dieter,

ich habe umdisponiert und werde das “Experiment” derzeit nicht ausführen.
Der Grund ist einfach der, dass meine Arbeits-Festplatte sehr gut eingestellt ist, Ubuntu 7.10 und Suse 10.3 laufen hervorragend, XP ist mackenarm und wird wenig benutzt.
Diese Paltte wird meine Reserve-Platte sobald Suse 11 und Ubuntu 8.04 erscheinen, von DreamLinux werde ich vorerst Abstand nehmen, zuviel Startprobleme.
Wenn dann im Laufe des Mai (?) diese beiden OS eingerichtet sind, wird das meine Produktiv-Platte und die jetzt aktuelle der Reservist mit gelegentlicher Aktualisierung. Beim nächsten Distrowechsel geht dann der Zyklus von vorne los, hat den Vorteil, man bleibt gut im Training.
Wie gesagt, eure Tipps sind gespeichert für den Fall, dass mir mal eine 160er Platte vor die Füsse fällt.
Euch eine schöne Zeit
Werner.

so, das ist zwar schon alles etwas lange her, hat mich trotzdem nicht ruhen lassen.
Wenn man von einer Seagate auf eine Samsung (mein Fall) 1:1 kopiert, werden auf die Samsung die partitionsspezifischen uuid’s von der Seagate geschrieben.
Suse hat beim ersten Hochfahren sofort gemeckert, Ubuntu lief problemlos.
Das hat mich solange gewundert, bis irgendwann der fsck dran kam, danach hat auch Ubuntu gemault.
Inzwischen habe ich auf dieser Samsung die 11. Susi installiert.
Mit ls -l /dev/disk/by-uuid habe ich die Platte durchleuchtet, die Tabelle ausgedruckt und Altmeister Knoppix angeworfen.
Die /media/sda9 wurde schreibbar gemacht, die Ubuntu-fstab editiert, und siehe da, einige Partitionen hatten eine falsche uuid, die von der Seagate?
Richtig waren die / und /home, falsch die /swap und die /backup, meine zentrale backup Partition.
Nach den Korrekturen startete Ubuntu problemlos.

Schön, wieder etwas hinzugelernt….
Allen Helfern danke ich für die Ratschläge.