Hallo, vorab: ich nutze hier Clonezilla schon seit vielen Jahren und habe schon etliche "Platte auf Platte" Backups erstellt. Arbeite dabei die Reihenfolge stets streng nach Checkliste ab. Bin aber kein Linux-Experte. Aktuell war auf einem Dual-Boot Notebook mit Windows/Ubuntu ein Backup auf eine baugleiche HDD zu machen. Beide Platten waren WD1600BEVT mit je 160 GB. Das letzte Backup wurde 2019 erstellt. Das Backup lief wie üblich ohne Probleme durch. Nach dem Neustart des Systems fiel dann auf, dass die Maus tot war und der Router nicht gefunden wurde. Als dann das Notebook noch die interne Festplatte als neue Hardware gefunden hatte, wusste ich, dass was faul war. Das Backup lief in die falsche Richtung, ich hatte jetzt das System von 2019. Zu der Zeit hatte ich eine andere Maus und einen anderen Router. Nachdem ich das System wieder aktualisiert hatte, habe ich erneut ein Backup angestoßen und mir diesmal vorab mittels CrystalDiskInfo die Nummern der Platten notiert und genau aufgepasst. Denn Clonezilla zeigt zu sda bzw. sdb auch die Nummern der Platten an. Und es ist so, dass sda nicht die Quellplatte ist und sdb nicht die Zielplatte, sda und sdb sind vertauscht. Habe dann von sdb nach sda kopiert und es hat gepasst. Die beiden zentralen Fragen wären: 1. Was ist da angebrannt? 2. Bekommt man das irgendwie repariert? Hans
Deshalb gibt es UUIDs. Die Reihenfolge sda, sdb ist lediglich diejenige, mit der die FP vom System gefunden wurden.
Klemm die Zielplatte an dem Menüpunkt an,
wo es dich dazu auffordert.
Das ist doch irgendwo auf "halbem Wege" der ganzen Enterdrückerei.
und dann
>> 5 Sekunden warten
Wenn die Quellplatte bereits beim Booten dran ist,
sollte die sda sein.
:
Bearbeitet durch User
.● Des|ntegrator ●. schrieb: > Klemm die Zielplatte an dem Menüpunkt an, > wo es dich dazu auffordert. /dev/sdx sind keine Platten am USB Port! SATA ist selten hotplugfähig. Noch was: Die UUID wird mitgeclont. Man sollte also nach dem clonen der Platte die UUID der Backuplatte ändern. Sonst hat man das nächste Mal wieder das gleiche Problem.
:
Bearbeitet durch User
Clonen verzeiht keine Irrtümer. Wenn Quelle und Ziel irrtümlich vertauscht wurden, hat man im schlimmsten Fall blitzschnell 2 leere Datenträger. Deswegen bevorzuge ich Images sofern möglich.
Klarheit verschafft stets ein:
1 | ~$ lsblk -oNAME,SIZE,MODEL,SERIAL|grep "sd[a-z] " |
2 | sda 232,9G Samsung_xxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxx |
3 | sdb 186,3G STxxxxxxxxx xxxxxxxx |
4 | sdc 931,5G SAMSUNG_xxxxxxx xxxxxxxxxxxxxx |
5 | sdd 1,4T SAMSUNG_xxxxxxx xxxxxxxxxxxxxx |
6 | sde 3,6T STxxxxxxxxx-xxxxxx xxxxxxxx |
7 | sdf 28,6G Ultraxxxx xxxxxxxxxxxxxxxxxxxx |
Darf man sich in ein bash script schreiben.
:
Bearbeitet durch User
Beitrag #8055208 wurde vom Autor gelöscht.
Lu schrieb: > Deswegen bevorzuge ich Images sofern möglich. so auch hier. und das Image muss man auch mit einer dritten Platte testen. Sprich nicht einfach nur Image erstellen und weg legen. Das wäre im Bedarfsfalle nicht der erste Fehler im Sinne von "Image kann nicht gelesen werden"
Andreas B. schrieb: > SATA ist selten hotplugfähig. Ich hatte noch keinen Rechner, wo es nicht hotplugfähig war. Tatsächlich ist das Teil der Spezifikation – gegebenenfalls muss man es im Firmware-Setup einstellen.
Lu schrieb: > Deswegen bevorzuge ich Images sofern möglich. > Die dann nicht gehen wenn du sie brauchst? Ich habe noch nie diesen Fehler beim klonen mit Clonezilla gehabt. Bei mir wird die Quellplatte richtig erkannt. Meine Quelle ist eine Toshiba, die Zielplatte eine Samsung. Alleine deswegen kann ich die gut auseinanderhalten. Natürlich muss man die Eintragung der Laufwerke überprüfen...immer. Früher hatte ich zwei baugleiche Laufwerke, die kann man nur über die Seriennummer auseinander halten.
Herbert Z. schrieb: > Ich habe noch nieee diesen Fehler beim klonen mit Clonezilla gehabt. Ich habe vor Jahren schon mal eine leere Diskette auf eine volle "gesichert" und viel dabei gelernt. *Sie waren dann beide leer!*
Hans H. schrieb: > Nach dem Neustart des > Systems fiel dann auf, dass die Maus tot war und der Router nicht > gefunden wurde. Neustart: Neue Zuteilung von sda und sdb zu den Platten möglich. Also: Hersteller/Typ/Grösse/ggf.Seriennummer checken!
Stephan S. schrieb: > Neustart: Neue Zuteilung von sda und sdb zu den Platten möglich. > Also: Hersteller/Typ/Grösse/ggf.Seriennummer checken! Nach dem Klonvorgang hat er entweder die Neue auf die alte Platte geschrieben. Dann sind beide gleich. Oder er hat die Alte auf die neue Platte geschrieben. Dann sind ebenfalls beide gleich. Also sollte es egal sein in welcher Reihenfolge die beiden Platten auf sda und sdb gemappt werden.
Man könnte ja auch ganz einfach selbst mal einen Blick auf die Daten werfen bevor man startet. Zur Not mtime auf /var/log/journal/*/*.journal oder pagefile.sys per Skript vergleichen oder sowas.
Man sollte immer wissen was man tut und den gröbsten aller Fehler durch "kontrolletti" ausschließen. Quelle und Ziel vertauschen ist echt schlecht...
Andreas B. schrieb: > Deshalb gibt es UUIDs. > Die Reihenfolge sda, sdb ist lediglich diejenige, mit der die FP vom > System gefunden wurden. Das ist die richtige Antwort. Bei allem, was durchnummeriert ist / keine UUID oder ähnliches hat, geht man am besten davon aus, dass die Reihenfolge zufällig ist. Zumindest als grobe Faustregel, auf manche Sachen, wie die Partitionsnummer, kann man sich natürlich schon verlassen.
Hans H. schrieb: > Was ist da angebrannt? Dein Fehler: Du hast nur auf die logische Platten-Bezeichnungen geschaut und irrtümlicherweise angenommen, dass die immer und ewig mit denselben physischen Platten verbunden sind. Sind sie aber nicht. > Bin aber kein Linux-Experte. Wenn du unter Windows D: nach E: kopierst, kann dir genau dasselbe Missgeschick passieren. > Arbeite dabei die Reihenfolge stets streng nach Checkliste ab. In der Checkliste fehlt der Punkt "Prüfe vor dem Starten des Kopierens zweimal, ob wirklich die richtige physische Platte als Zielplatte genutzt wird."
Beitrag #8055295 wurde vom Autor gelöscht.
Frank D. schrieb: > Andreas B. schrieb: >> /dev/sdx sind keine Platten am USB Port! > So pauschal einfach falsch. Stimmt, da habe ich was verwechselt.
Jack V. schrieb: > Andreas B. schrieb: >> SATA ist selten hotplugfähig. > > Ich hatte noch keinen Rechner, wo es nicht hotplugfähig war. Tatsächlich > ist das Teil der Spezifikation – gegebenenfalls muss man es im > Firmware-Setup einstellen. Meines Wissens braucht es dazu spezielle HW. Oder geht das mit diesen getrennten Steckern für Power & Daten?
"ls -lR /dev/disk/" liefert Platten in verschiedenen Geschmacksrichtungen Da ist für jeden was dabei. Und wenn man das Image als File in ein Filesystem schreibt besteht noch weniger Verwechslungsgefahr.
:
Bearbeitet durch User
Andreas B. schrieb: > Meines Wissens braucht es dazu spezielle HW. Oder geht das mit diesen > getrennten Steckern für Power & Daten? Das geht problemlos mit den normalen SATA Steckern (mit engen Grenzen für die Anzahl der Steckvorgänge). Wenn man's oft machen will, dafür gibt es extra eSATA Steckanschlüsse zB. für die Slotblende.
G. K. schrieb: > "ls -lR /dev/disk/" liefert Platten in verschiedenen > Geschmacksrichtungen > > Da ist für jeden was dabei. …und nur (im Sinne von ausschließlich) /dev/disk/by-id/ enthält von der Hardware abgeleitete Namen, welche wie oben schon gelistet zB. auch SERIAL beinhalten.
Lu schrieb: > Clonen verzeiht keine Irrtümer. Wenn Quelle und Ziel irrtümlich > vertauscht wurden, hat man im schlimmsten Fall blitzschnell 2 leere > Datenträger. Da Clonezilla ja auch den Typ/Hersteller anzeigt und sich die bei mir grob unterschieden ist Clonen für mich ein akzeptabler Weg.
Andreas B. schrieb: > Meines Wissens braucht es dazu spezielle HW. Oder geht das mit diesen > getrennten Steckern für Power & Daten? SATA ist prinzipiell hotplugfähig, genau dafür wurden die Steckverbinder mit vorauseilenden Massekontakten erfunden. Aber nicht jeder SATA-Hostcontroller kommt damit zurecht, und erst recht nicht jedes Betriebssystem. Am wenigsten Ärger hat man, wenn man eine der zu klonenden Platten/SSDs an einem USB-SATA-Adapter betreibt. Der ist prinzipiell immer hotplugfähig, und der sollte selbst unter Clonezilla leicht vom SATA-Controller des PCs zu unterscheiden sein. Sofern man keinen Uralt-PC verwendet, der nur USB2.0 kennt, ist so etwas auch ausreichend schnell. Bei SATA-SSDs ist die USB-Lösung vielleicht 10..20% langsamer, aber das auch nur, solange der Cache der SSD ausreicht.
Harald K. schrieb: > Aber nicht jeder SATA-Hostcontroller kommt damit zurecht, und erst recht > nicht jedes Betriebssystem. Welches denn nicht? Selbst Windows (getestet mit 10 und 11) kommt heutzutage damit zurecht, Linux und FreeBSD ebenso. MacOS, OpenBSD und TempleOS habe ich noch nicht probiert, bei den beiden BSDs würde ich es allerdings annehmen. Letzteres kommt vermutlich wirklich nicht damit klar – aber ich kenne keinen, der das ernsthaft nutzt. Und wie gesagt: Ich hatte noch keinen Rechner, bei dem es nicht funktioniert hat, und ich hab ’ne Zeitlang wirklich viele Rechner am Wickel gehabt (als in den Firmen die Hardware auf ’nen Win11-fähigen Stand gebracht wurde – da haben wir die Datenträger im laufenden Betrieb an die Boards gehängt und abgezogen, weil’s halt am schnellsten ging). Einer meiner PCs kam damit mal nicht zurecht (glaube, das hatte ich hier im Forum irgendwo auch mal geschrieben), aber da war’s besagte Einstellung im Firmware-Setup.
:
Bearbeitet durch User
Rolf schrieb: > In der Checkliste fehlt der Punkt "Prüfe vor dem Starten des Kopierens > zweimal, ob wirklich die richtige physische Platte als Zielplatte > genutzt wird." Nach der aktuell üblen Erfahrung habe ich meine Checkliste angepasst. Ich hielt bei einem Backup die Richtung von A nach B in Stein gemeißelt. Bei meinem zweiten und hauptsächlich genutzten System ist dies und war das auch immer so. Clonezilla gibt hier bei der Auswahl der Platten folgende Info aus: Wählen Sie die lokale Original-Platte. Die erste Platte im System ist "hda" oder "sda", die zweite Platte ist "hdb" oder "sdb"... Ich verstehe als erste Platte die Platte, die fest im Gerät verbaut ist. Desweiteren liefert Clonezilla hier bei der Auswahl von Quell-und Zielplatte folgende Informationen zur Platte: Speicherplatz - Hersteller - Modellnummer (MDL) - Seriennummer (S/N) Alle vier Angaben stehen auf dem Label der Platte und werden einem auch in CrystalDiskInfo angezeigt. Man kann also eine Platte eindeutig zuordnen und sollte sda bzw. sdb besser vergessen.
Herbert Z. schrieb: > Lu schrieb: >> Deswegen bevorzuge ich Images sofern möglich. > Die dann nicht gehen wenn du sie brauchst? Das ist auch meine Befürchtung. Und bei einem testweisen zurück laden des eben erstellten Images hat man sich schnell mal sein System versaut. Bei einem Backup auf eine zweite Platte kann ich zum Testen mal eben umstecken, ohne mein aktuelles System zu riskieren.
Daniel A. schrieb: > Andreas B. schrieb: >> Deshalb gibt es UUIDs. >> Die Reihenfolge sda, sdb ist lediglich diejenige, mit der die FP vom >> System gefunden wurden. > > Das ist die richtige Antwort. Bei allem, was durchnummeriert ist / keine > UUID oder ähnliches hat, geht man am besten davon aus, dass die > Reihenfolge zufällig ist. Die Reihenfolge ist aber nicht zufällig. Der TE wird, wie in seinen Threads üblich, mindestens einen Fakt nicht genannt haben, der zu einer anderern Bennungsreihenfolge geführt hat.
Man kann ein Image erzeugen auf einem großen Datenträger und später auf eine neue Platte zurückspielen. Das kostet zwar Zeit, hat aber den Vorteil, dass man später noch ein Image als Backup im Schrank herumliegen hat, wenn die neue Platte eingebaut wurde und funktioniert.
Hans H. schrieb: > Desweiteren liefert Clonezilla hier bei der Auswahl von Quell-und > Zielplatte folgende Informationen zur Platte: > > Speicherplatz - Hersteller - Modellnummer (MDL) - Seriennummer (S/N) Gleich die erste Anleitung, die Google im Netz zu Clonezilla findet, schreibt: „Um die Festplatten später eindeutig zuzuordnen, können Sie sich im Vorfeld die Seriennummern der Festplatten notieren. Diese finden Sie z.B. auf den Deckeln der Festplatten.“ Erfahrung kommt halt überall von erfahren. Oliver
Michael L. schrieb: > Die Reihenfolge ist aber nicht zufällig. Das ist wahr, nur sind die Faktoren für den User nicht in jedem Fall vorhersehbar, die die Reihenfolge kann sich durchaus von Boot zu Boot ändern. Zu Festplattenzeiten mit zwei Platten, die ähnlich schnell angelaufen sind, war’s fast schon als RNG zu gebrauchen, aber ich hab das Verhalten auch schon bei Flash-Datenträgern beobachtet. Ich würde daher zumindest diesbezüglich nichts unterstellen wollen.
:
Bearbeitet durch User
Norbert schrieb: > …und nur (im Sinne von ausschließlich) /dev/disk/by-id/ enthält von der > Hardware abgeleitete Namen, welche wie oben schon gelistet zB. auch > SERIAL beinhalten. /dev/disk/by-path kann auch zur eindeutigen Identifizierung heran gezogen werden. Nicht umsonst schrieb ich von verschieden Geschmacksrichtungen.
G. K. schrieb: > /dev/disk/by-path kann auch zur eindeutigen Identifizierung heran > gezogen werden. > > Nicht umsonst schrieb ich von verschieden Geschmacksrichtungen. So wie ich das sehe, identifizierst du damit aber den Anschluss, nicht jedoch das angeschlossene physikalische Gerät. Solange man nichts an- oder umsteckt, ist das in Ordnung. Allerdings hören sich ›Notebook‹ und ›zwei physische Harddisks‹ sowie etwas seltsam an.
:
Bearbeitet durch User
Norbert schrieb: > G. K. schrieb: >> /dev/disk/by-path kann auch zur eindeutigen Identifizierung heran >> gezogen werden. >> >> Nicht umsonst schrieb ich von verschieden Geschmacksrichtungen. > > So wie ich das sehe, identifizierst du damit aber den Anschluss, nicht > jedoch das angeschlossene physikalische Gerät. > Solange man nichts an- oder umsteckt, ist das in Ordnung. > > Allerdings hören sich ›Notebook‹ und ›zwei physische Harddisks‹ sowie > etwas seltsam an. Welche Eindeutigkeit fehlt dir hier?
1 | lrwxrwxrwx 1 root root 9 May 17 11:08 pci-0000:00:1f.2-ata-1 -> ../../sr0 |
2 | lrwxrwxrwx 1 root root 9 May 17 11:08 pci-0000:00:1f.2-ata-1.0 -> ../../sr0 |
3 | lrwxrwxrwx 1 root root 9 May 17 11:08 pci-0000:04:00.0 -> ../../vda |
4 | drwxr-xr-x 6 root root 120 May 17 11:08 pci-0000:04:00.0-part |
5 | lrwxrwxrwx 1 root root 10 May 17 11:08 pci-0000:04:00.0-part1 -> ../../vda1 |
6 | lrwxrwxrwx 1 root root 10 May 17 11:08 pci-0000:04:00.0-part2 -> ../../vda2 |
7 | lrwxrwxrwx 1 root root 10 May 17 11:08 pci-0000:04:00.0-part3 -> ../../vda3 |
8 | lrwxrwxrwx 1 root root 13 May 17 11:08 pci-0000:07:00.0-nvme-1 -> ../../nvme0n1 |
9 | drwxr-xr-x 6 root root 120 May 17 11:08 pci-0000:07:00.0-nvme-1-part |
10 | lrwxrwxrwx 1 root root 15 May 17 11:08 pci-0000:07:00.0-nvme-1-part1 -> ../../nvme0n1p1 |
11 | lrwxrwxrwx 1 root root 15 May 17 11:08 pci-0000:07:00.0-nvme-1-part2 -> ../../nvme0n1p2 |
12 | lrwxrwxrwx 1 root root 15 May 17 11:08 pci-0000:07:00.0-nvme-1-part3 -> ../../nvme0n1p3 |
13 | lrwxrwxrwx 1 root root 15 May 17 11:08 pci-0000:07:00.0-nvme-1-part4 -> ../../nvme0n1p4 |
14 | lrwxrwxrwx 1 root root 9 May 17 11:08 pci-0000:08:00.0-ata-2 -> ../../sda |
15 | lrwxrwxrwx 1 root root 9 May 17 11:08 pci-0000:08:00.0-ata-2.0 -> ../../sda |
16 | lrwxrwxrwx 1 root root 9 May 17 11:08 pci-0000:08:00.0-ata-3 -> ../../sdb |
17 | lrwxrwxrwx 1 root root 9 May 17 11:08 pci-0000:08:00.0-ata-3.0 -> ../../sdb |
18 | lrwxrwxrwx 1 root root 9 May 17 11:08 pci-0000:08:00.0-ata-4 -> ../../sdc |
19 | lrwxrwxrwx 1 root root 9 May 17 11:08 pci-0000:08:00.0-ata-4.0 -> ../../sdc |
20 | lrwxrwxrwx 1 root root 9 May 17 11:08 virtio-pci-0000:04:00.0 -> ../../vda |
21 | lrwxrwxrwx 1 root root 10 May 17 11:08 virtio-pci-0000:04:00.0-part1 -> ../../vda1 |
22 | lrwxrwxrwx 1 root root 10 May 17 11:08 virtio-pci-0000:04:00.0-part2 -> ../../vda2 |
23 | lrwxrwxrwx 1 root root 10 May 17 11:08 virtio-pci-0000:04:00.0-part3 -> ../../vda3 |
G. K. schrieb: > Welche Eindeutigkeit fehlt dir hier? Das ist einfach: Niemand weiß welche sdx zu welcher physischen Festplatte gehört. Und wenn ich zwei SATA Anschlüsse umstöpsele, dann noch viel weniger.
1 | ~$ l /dev/disk/by-path/ |
2 | lrwxrwxrwx 1 root root 9 29. Mai 06:49 pci-0000:00:1f.2-ata-4 -> ../../sdd |
3 | lrwxrwxrwx 1 root root 9 29. Mai 06:49 pci-0000:00:1f.2-ata-4.0 -> ../../sdd |
4 | lrwxrwxrwx 1 root root 10 29. Mai 06:49 pci-0000:00:1f.2-ata-4.0-part1 -> ../../sdd1 |
5 | lrwxrwxrwx 1 root root 10 29. Mai 07:01 pci-0000:00:1f.2-ata-4.0-part2 -> ../../sdd2 |
6 | lrwxrwxrwx 1 root root 10 29. Mai 06:49 pci-0000:00:1f.2-ata-4-part1 -> ../../sdd1 |
7 | lrwxrwxrwx 1 root root 10 29. Mai 07:01 pci-0000:00:1f.2-ata-4-part2 -> ../../sdd2 |
Wohingegen /dev/disk/by-id zu wirklich eindeutigen Ergebnissen führt.
1 | lrwxrwxrwx 1 root root 9 29. Mai 06:49 ata-SAMSUNG_HD154UI_S1Y5476BGF334 -> ../../sdd |
Jack V. schrieb: > Das ist wahr, nur sind die Faktoren für den User nicht in jedem Fall > vorhersehbar, die die Reihenfolge kann sich durchaus von Boot zu Boot > ändern. Zu Festplattenzeiten mit zwei Platten, die ähnlich schnell > angelaufen sind, war’s fast schon als RNG zu gebrauchen, aber ich hab > das Verhalten auch schon bei Flash-Datenträgern beobachtet. Sowas hab ich nur einmal mit einer Festplatte aus den 90ern an einem vergleichsweise neuen MB gehabt. Da war die Platte tatsächlich zu langsam für das BIOS.
Michael L. schrieb: > Da war die Platte tatsächlich zu > langsam für das BIOS. Die absolute Geschwindigkeit ist dabei egal; es geht dabei darum, welche Platte sich zuerst am Controller anmeldet. Bei einer sehr schnellen und einer sehr langsamen Platte wär’s wieder weitgehend vorhersagbar.
:
Bearbeitet durch User
Norbert schrieb: > Allerdings hören sich ›Notebook‹ und ›zwei physische Harddisks‹ sowie > etwas seltsam an. Sein Laptop scheint ja ein paar Jahre älter zu sein. Da gab es durchaus einige mit 2 Laufwerksplätzen. Und es gab Wechseleinschübe für Festplatten, die man gegen das eingebaute CD/DVD-Laufwerk tauschen konnte.
Jack V. schrieb: > Die absolute Geschwindigkeit ist dabei egal; es geht dabei darum, welche > Platte sich zuerst am Controller anmeldet. Bei einer sehr schnellen und > einer sehr langsamen Platte wär’s wieder weitgehend vorhersagbar. Das mag sein, aber ich glaub's Dir nicht :-) Weil meine persönliche Erfahrung dagegen spricht. Ich werde jetzt aber auch keine Doku von irgendwelchen Controllern wälzen. Was aber, so glaube ich mich zu erinnern, an einem älteren Laptop ging: Man konnte die beiden SATA-Ports switchen und damit war dann auch die Bezeichnung der Platte/SSD gewechselt.
Michael L. schrieb: > Das mag sein, aber ich glaub's Dir nicht :-) Weil meine persönliche > Erfahrung dagegen spricht. Ich kann mir richtig vorstellen, wie dir jemand erzählt, was ihm passiert ist und du ihm erklärst, dass du ihm nicht glaubst, weil es dir persönlich noch nicht passiert wäre m( Leute gibt das …
Lu schrieb: > Man kann ein Image erzeugen auf einem großen Datenträger und später auf > eine neue Platte zurückspielen. Das kostet zwar Zeit, hat aber den > Vorteil, dass man später noch ein Image als Backup im Schrank > herumliegen hat, wenn die neue Platte eingebaut wurde und funktioniert. Und wenn die Platte nicht funktionierte, hatte man eben KEIN Backup. Ich hatte zu Win98-Zeiten mal so ein Image-Programm benutzt, keine Ahnung, wie oft ich Win98 neu aufgesetzt habe, weil nach dem zurück spielen nichts funktionierte. Mehrere Wochenenden hatte ich gebraucht, bis ich die richtigen Einstellungen raus hatte. Dann ging es allerdings recht pfiffig: Für einen Test mal eben ein reines Win98-SystemImage zurück spielen dauerte gerade mal 28 Sekunden.
Michael L. schrieb: > es gab Wechseleinschübe für Festplatten, die man gegen das eingebaute > CD/DVD-Laufwerk tauschen konnte. So ist es, da hat einer mal eine sauber geputzte Glaskugel. Ist ein altes IBM-Thinkpad, in den seitlichen Schacht des DVD-Laufwerks konnte man vom Disketten- und ZIP-Laufwerk über Festplatten bis hin zu einem zweiten Akku alles mögliche einschieben. Jack V. schrieb: > es geht dabei darum, welche Platte sich zuerst am Controller anmeldet. Das wäre eine sehr seltsame Technik. In einem Windows-PC mit mehreren Platten hätten dann selbige nach jedem Booten jedes mal andere Laufwerksbuchstaben. Würde nicht wirklich Sinn machen.
Hans H. schrieb: > Das wäre eine sehr seltsame Technik. In einem Windows-PC mit mehreren > Platten hätten dann selbige nach jedem Booten jedes mal andere > Laufwerksbuchstaben. Würde nicht wirklich Sinn machen. Laufwerksbuchstaben != Blockdevice Die interne enummerierung bekommt man ja unter Windows normalerweise nicht zu sehen. > Ist ein altes IBM-Thinkpad, in den seitlichen Schacht des DVD-Laufwerks > konnte man vom Disketten- und ZIP-Laufwerk über Festplatten bis hin zu > einem zweiten Akku alles mögliche einschieben. Die Platten, auch verschiedene, die du da einsteckst dürften immer gleich unter "by-path" auftauchen, auch wenn der Norbert was anderes behauptet.
:
Bearbeitet durch User
Bei mir ist es so, dass Clonezilla sie Systemplatte die immer im Rechner ist als Quellplatte markiert. Die Platte welche ich als Zielplatte dazu hänge ist dann automatisch die Zielplatte. Kann auch sein, dass der Steckplatz der Systemplatte auf den Board ein Rolle dabei spielt. Ganz sicher geht man über die Seriennummer. Wenn das Prozedere immer das gleiche ist , macht Clonezilla das immer gleich.
So viel Aufwand habe ich nie getrieben. Oft erkennt man schon an der Plattengröße oder Label welche Platte es ist. Gründlichstes LESEN der Clonezilla-Anleitungen hilft natürlich unheimlich, da es verschiedene Clonezilla-Versionen gibt!
G. K. schrieb: > Die Platten, auch verschiedene, die du da einsteckst dürften immer > gleich unter "by-path" auftauchen, auch wenn der Norbert was anderes > behauptet. Aber das behauptet der Norbert gar nicht. Er sagte lediglich, wenn die Platten anders angesteckt werden, tauchen sie an anderen Pfaden auf. Er erwähnte auch, so meine ich mich zu erinnern, ›Solange man nichts an- oder umsteckt, ist das in Ordnung.‹
Lu schrieb: > So viel Aufwand habe ich nie getrieben. Oft erkennt man schon an > der > Plattengröße oder Label welche Platte es ist. Hans H. schrieb: > Aktuell war auf einem Dual-Boot Notebook mit Windows/Ubuntu ein Backup > auf eine baugleiche HDD zu machen. Beide Platten waren WD1600BEVT mit je > 160 GB. Finde das Problem. Oliver
Herbert Z. schrieb: > Ganz sicher geht man über die Seriennummer. Das Tupel aus Seriennummer und Typ sollte eindeutig sein, die Seriennummer alleine ist nicht zwingend eindeutig.
:
Bearbeitet durch User
Lu schrieb: > So viel Aufwand habe ich nie getrieben. Oft erkennt man schon an der > Plattengröße oder Label welche Platte es ist. Das Label wird beim clonen mit kopiert, daher sollte man das besser komplett ignorieren.
Hans H. schrieb: > Das wäre eine sehr seltsame Technik. In einem Windows-PC mit mehreren > Platten hätten dann selbige nach jedem Booten jedes mal andere > Laufwerksbuchstaben. Würde nicht wirklich Sinn machen. Es ist so; einerseits basiert Clonezilla nicht auf Windows und dessen Laufwerksbuchstaben, andererseits sind die Laufwerksbuchstaben unter Windows an das Dateisystem gebunden – sowas Ähnliches gibt es hier natürlich auch, aber es sind nicht die Devicefiles. Diese werden stumpf chronologisch vergeben (sofern man nicht in der udev-Config Dinge festnagelt). Aber probier’s halt aus: Nimm zwei USB-Sticks, stecke Stick A in einen Port, dann Stick B in einen anderen Port. Gucke, welcher Stick welches Devicefile bekommt. Nimm beide raus, warte kurz, und stecke dann Stick B vor Stick A ein, jeden in den vorherigen Port. Schaue erneut. USB und SATA verhalten sich hierbei gleich, der Mechanismus ist derselbe. Hans H. schrieb: > So ist es, da hat einer mal eine sauber geputzte Glaskugel. Bisschen dreist ist es ja schon auch irgendwie, solche relevanten Infos nicht in den Eingangsbeitrag zu schreiben, und dann sowas zu bringen …
G. K. schrieb: > die > Seriennummer alleine ist nicht zwingend eindeutig. Erkläre mal! Es gibt keine Platten die eine identische Seriennumer haben. Wenn du so etwas hast, dann ist das ein fehl Label, die kannst du als Pärchen als Kuriosum teuer auf einer Auktion anbieten. Im übrigen erkennt Clonezilla einige Kriterien ( Seriennummer, Größe, Hersteller zb.) Ganz einfach ist das auseinander halten über den Hersteller wie bei mir. Toshiba ist die Quelle, Samsung die Zielplatte. Da bekommt man keinen Knoten ins Hirn.
Herbert Z. schrieb: > G. K. schrieb: >> die >> Seriennummer alleine ist nicht zwingend eindeutig. > > Erkläre mal! Es gibt keine Platten die eine identische Seriennumer > haben. Irgendwelche Hersteller haben noch nie disfunktionalen Kernschrott auf den Markt gebracht? Und wie generieren eigentlich Storage-Netzwerke die Seriennummern für die (virtuellen) LUNs? Vor 40 Jahren waren MACs angeblich immer eindeutig, kannst dich noch daran erinnern?
:
Bearbeitet durch User
Hans H. schrieb: > Ich hatte zu Win98-Zeiten mal so ein Image-Programm benutzt, keine > Ahnung, wie oft ich Win98 neu aufgesetzt habe, weil nach dem zurück > spielen nichts funktionierte. Mehrere Wochenenden hatte ich gebraucht, > bis ich die richtigen Einstellungen raus hatte. Dann ging es allerdings > recht pfiffig: Für einen Test mal eben ein reines Win98-SystemImage > zurück spielen dauerte gerade mal 28 Sekunden. Bereits zu den seligen Zeiten von Windows98 gab es eine revolutionäre, heute hieße es "disruptive" Technologie, mit der man die gewünschten Einstellungen hätte aufzeichnen können. Diese erstaunliche Technologie nennt sich, und sie funktioniert heute immer noch: Stift und Papier. :-)
Ein T. schrieb: > Bereits zu den seligen Zeiten von Windows98 gab es eine revolutionäre, > heute hieße es "disruptive" Technologie, mit der man die gewünschten > Einstellungen hätte aufzeichnen können. Diese erstaunliche Technologie > nennt sich, und sie funktioniert heute immer noch: Stift und Papier. :-) Und schon 10 Jahre früher konnte man mit den PC-Ports von Unix wunderbar Medien (Floppys, Bänder und Platten) clonen. Und die Kommandos von damals funktionieren heute noch :-)
Hans H. schrieb: > Das letzte Backup wurde 2019 erstellt. Du solltest dir ein Bookmark auf diesen Thread setzen. Wenn dann 2033 das nächste Backup ansteht, kannst du nachlesen, worauf du achten musst. Oliver
:
Bearbeitet durch User
G. K. schrieb: > Und schon 10 Jahre früher konnte man mit den PC-Ports von Unix Ende der 80er? 386/ix? Das hatte und kannte ja auch jeder.
Roland F. schrieb: > G. K. schrieb: >> ...die Seriennummer alleine ist nicht zwingend eindeutig. > > Warum nicht? Warum sollte sie? Wird die durch ein zentrales Konsortium vergeben? Ich würde Seriennummern auch nur innerhalb des Herstellerkontexts als eindeutig betrachten ...
Jens G. schrieb: > Ich würde Seriennummern auch nur innerhalb des Herstellerkontexts als > eindeutig betrachten Es dürfte den meisten Leuten klar sein, daß man sich die Seriennummer der Festplatte nur ansieht, wenn die Festplatte nicht nur vom gleichen Hersteller ist, sondern auch die gleiche Typenbezeichnung aufweist. Insofern ist Deine Betrachtung "mathematisch": Zutreffend, aber sinnlos.
Richtig ist, dass man auch mit der Identifizierung von Festplatten auch eine Diplom oder Doktorarbeit ableiten kann....je nachdem wie man gestrickt ist. Bei mir heißt das Toshiba oder Samsung, kurz und knapp. Wenn sich das Prozedere am Rechner nicht jedes mal ändert, zeigt auch Clonezilla immer das selbe an.
Harald K. schrieb: > > Ende der 80er? 386/ix? > > Das hatte und kannte ja auch jeder. Das Subnetz lief damals zu großen Teilen auf solchen Kisten.
:
Bearbeitet durch User
Herbert Z. schrieb: > Bei mir heißt das Toshiba oder Samsung, kurz und knapp. Und was machst Du, wenn Du zwei Festplatten des gleichen Herstellers hast? Manche Zwerge sind so klein, die werfen noch nicht mal einen Schatten.
Harald K. schrieb: > Und was machst Du, wenn Du zwei Festplatten des gleichen Herstellers > hast? Ich mache keine Doktorarbeit daraus sondern schreibe mir die Seriennummer auf. Hatte ich auch schon, 2 absolut baugleiche Toshiba. Harald K. schrieb: > Manche Zwerge sind so klein, die werfen noch nicht mal einen Schatten. KI ist viel höflicher als so mancher "Nullinger" hier im Forum. Deswegen nutze ich KI immer öfter, es ist mir eine reine Freude. Musst nur präzise fragen können, dann macht es richtig Spaß! Tschüüüüüß!
:
Bearbeitet durch User
Herbert Z. schrieb: > Ich mache keine Doktorarbeit daraus sondern schreibe mir die > Seriennummer auf. Ach. Ach was. Ach Herbert. Und was ist jetzt bitte der Unterschied zu dem, was Du "Doktorarbeit" nennst? KI ist digitale Lobotomie. Sich das Hirn mit dem Löffel rauskratzen. Viel Spaß!
Harald K. schrieb: > KI ist digitale Lobotomie. Sich das Hirn mit dem Löffel rauskratzen. > Viel Spaß! Nein ! Es macht solche Typen wie dich unnötig, absolut existenzgefährdend für Leute wie dich. Kein Wunder auch, dass dir KI nicht zusagt.;-)
Herbert Z. schrieb: > Es macht solche Typen wie dich unnötig, absolut > existenzgefährdend für Leute wie dich. Jaja, glaub da nur dran.
Harald K. schrieb: > Es dürfte den meisten Leuten klar sein, daß man sich die Seriennummer > der Festplatte nur ansieht, wenn die Festplatte nicht nur vom gleichen > Hersteller ist, sondern auch die gleiche Typenbezeichnung aufweist. Was ja hier der Fall ist ...
Habe das Ganze nochmal laufen lassen und paar Aufnahmen vom Bildschirm gemacht. Die rot hinterlegte Platte ist eindeutig und wiederholt die Zielplatte. Weiß jemand, was -2 und -0 in Bildmitte bedeutet?
Hans H. schrieb: > Weiß jemand, was -2 und -0 in Bildmitte bedeutet? Lass den mal laufen:Beitrag "Re: Clonezilla vertauscht sda mit sdb" Ich vermute dass die -2 -0 zum Festplattentyp gehören. Vielleicht eine Evolutionsstufe.
Hans H. schrieb: > Habe das Ganze nochmal laufen lassen und paar Aufnahmen vom Bildschirm > gemacht Clonezilla stellt aus irgendeinem Grund die Information doppelt oder sogar mehrfach dar: 160GB_WDC_WD1600BEVT-2_WDC_WD1600BEVT-22ZCT_WD- Trennt man das jeweils beim Unterstrich, wird es deutlicher
1 | 160GB_ |
2 | WDC_ |
3 | WD1600BEVT-2_ |
4 | WDC_ |
5 | WD1600BEVT-22ZCT_ |
6 | WD- |
Nochmal ohne Einrückungen:
1 | 160GB |
2 | WDC |
3 | WD1600BEVT-2 |
4 | WDC |
5 | WD1600BEVT-22ZCT |
6 | WD- |
Die "0" oder "2", nach der Hans fragt, ist wohl einfach nur die erste Stelle der Seriennummer, die beim ersten Aufführen abgeschnitten ist. Die Macher von Clonezilla haben sich vermutlich was bei dieser Darstellungsform gedacht, nur sind die wenigsten von uns "speziell" genug, um diesen Gedankengang nachvollziehen zu können. Ich bin mir einigermaßen sicher, daß das "identify drive"-Kommando seine Informationen in anderer Form rausrückt.
Tausche mal die Platten an den Plätzen am Mainboard und schaue mal was Clonezilla dann für einen Eintrag schreibt.... Ich habe so einen Verdacht...Man muss ja nur die SATA Kabel umstecken.
Herbert Z. schrieb: > Tausche mal die Platten an den Plätzen am Mainboard und schaue mal > was > Clonezilla dann für einen Eintrag schreibt.... Ich habe so einen > Verdacht...Man muss ja nur die SATA Kabel umstecken. Ist das nicht ein bisschen viel Aufwand? Extra ein Notebook aufschrauben? Und ob darin SATA Kabel verlegt sind…
Norbert schrieb: > Ist das nicht ein bisschen viel Aufwand? > Extra ein Notebook aufschrauben? > Und ob darin SATA Kabel verlegt sind… Sorry Notebook, das hatte ich jetzt nicht auf meinen Schirm, wäre in der Tat etwas aufwändig und Kabel gibt es da keine. Bei meinem Rechner wäre das ein Klacks.
:
Bearbeitet durch User
Herbert Z. schrieb: > Tausche mal die Platten an den Plätzen am Mainboard und schaue mal was > Clonezilla dann für einen Eintrag schreibt... Habe ich mir auch schon überlegt. Der Tausch ist bei dem Notebook aber nicht ganz so einfach. Am Ende gäbe es zwei Antworten: 1. Bleibt zu Zuordnung weiterhin verkehrt, hat mein Notebook eine Macke. 2. Passt dann die Zuordnung, hat eine Platte eine Macke. Die Erkenntnis wird mich wahrscheinlich nicht viel weiter bringen. Norbert schrieb: > Lass den mal laufen... Das werde ich noch machen.
Hab es mal laufen lassen, Ergebnis in der unteren Bildhälfte. Hier stimmt die Zuordnung, sdb ist die Zielplatte. Die MDL-Nummer wird bei dem Kommando nicht ausgegeben. Was sagt uns das jetzt? Dass Clonezilla sda und sdb vertauscht?
:
Bearbeitet durch User
Hans H. schrieb: > Was sagt uns das jetzt? > Dass Clonezilla sda und sdb vertauscht? Das sieht für mich zunächst ganz so aus. Und es scheint ein echter Fehler zu sein. Außerdem steht das 2ZCT0 sowie 0A23T aller Wahrscheinlichkeit nach in VER (was ich bei der Auflistung der Variablen unterschlagen hatte). Was mir allerdings unangenehm auffällt, beide Clonezilla Images (Bilder) sind identisch, aber das lsblk muss zwangsläufig neuer sein (und nach einem Neustart). Also passt da irgend etwas nicht zusammen bei dem was du uns hier zeigst.
:
Bearbeitet durch User
Doublette1: Beide Images untereinander Doublette2: Gestapelt und eines mit grünem Marker versehen Doublette3: Unterschied
Habe jetzt keinen blassen Schimmer, was zu mir damit zeigen oder sagen willst, wenn du mein Bild 3x auseinander pflückst und wieder zusammensetzt. Auch kann ich in deinem zweiten Bild weder einen Stapel noch einen grünen Marker erkennen. Aber egal, das Ergebnis des Testlaufes ist eh hinfällig. Denn beim Booten gab es nur die internen Platte, die zweite Platte habe ich erst nach dem Booten eingeschoben. Denn ich konnte mich finster daran erinnern, dass es vor Jahren mal erhebliche Probleme gab, weil das Notebook - gestartet mit zwei Platten - von der zweiten Platte (der Backup-Platte) bootete und ich dies erst viel zu spät bemerkt hatte. Für den Testlauf hätte ich die Backup-Platte formatieren müssen. Aber man hat ja noch paar Platten in der Schublade liegen. Also eine 120er Platte eingeschoben und das Notebook mit zwei Platten gestartet. Jetzt ist es amtlich, in dem Fall wird die zweite Platte zu sda, siehe Bild untere Hälfte. Die WD1600BEVT-0 ist immer die fest eingebaute System-Platte. Also vertauscht nicht Clonzilla sda mit sdb, sondern das macht mein Notebook, wenn man das Gerät mit zwei Platten startet. Was beim Booten von Clonezilla via USB-Stick m.W. unvermeidbar ist.
Norbert schrieb: > Außerdem steht das 2ZCT0 sowie 0A23T aller Wahrscheinlichkeit nach in > VER (was ich bei der Auflistung der Variablen unterschlagen hatte). Habe mal VER eingebaut, das erzeugt hier nur eine Fehlermeldung.
Vielleicht sollte man halt doch mit einer einzigen Platte im System arbeiten und Backups, Clones etc auf einen externen (USB) Datenträger schieben. Dann entfällt diese Unübersichtlichkeit. Erst recht, wenn die Backups nicht auch noch auf eine baugleiche Platte kommen sollen
:
Bearbeitet durch User
Hans H. schrieb: > Also vertauscht nicht Clonzilla sda mit sdb, Das sagte er doch. Norbert schrieb: > das lsblk muss zwangsläufig neuer sein (und nach einem Neustart) Deine Screenshots zeigen unterschiedliche Zeitpunkte. Norbert schrieb: > Also passt da irgend etwas nicht zusammen bei dem was du uns hier > zeigst.
Michael L. schrieb: > Die Reihenfolge ist aber nicht zufällig. Für alle praktischen Zwecke muss man sie als solches behandeln. Ein Würfel zu werfen ist auch nicht zufällig, das ist ein komplett deterministischer Prozess. Ist nur meistens nicht Sinnvoll, das als solches zu betrachten.
Hans H. schrieb: > Habe mal VER eingebaut, das erzeugt hier nur eine Fehlermeldung. Wundert mich nicht. Weil ich es aus Versehen falsch herum angegeben habe.
1 | lsblk -oNAME,SIZE,MODEL,REV,SERIAL | egrep '^NAME|sd[a-z][^0-9]' |
So isses besser.
Ist irgendwie ein alter Hut. Früher beim Diskettenkopieren konnte man auch A und B Vertauschen, so dass dann B das neue A war, und A eben dann B. Das war meist keine Absicht - konnte aber vorkommen. Einfluss auf die Daten hatte das nicht, nur eben auf die Verwaltung. Und man wollte es ja wieder umstellen, so dass A wieder A ist und B wieder B. ;)
:
Bearbeitet durch User
Daniel A. schrieb: > Ein Würfel zu werfen ist auch nicht zufällig, das ist ein komplett > deterministischer Prozess. Seit ca. 100 Jahren gibt es die Quantenmechanik. Danach gibt es "im ganz Kleinen" keinen Determinismuss, sondern nur Wahrscheinlichkeiten. "Im Großen" fällt das nur nicht so auf. Wenn der Würfel (und natürlich die übrigen Bedingungen) fast ideal ist (also "dicht an der Quantenkippe" ist), kann er mal so und mal so fallen.
Rolf schrieb: > Seit ca. 100 Jahren gibt es die Quantenmechanik. und was war vorher? nur schwarz-weiss?
Hans H. schrieb: > Jetzt ist es amtlich, in dem Fall wird die zweite Platte zu sda, siehe > Bild untere Hälfte. Tu mal Butter bei die Fische. Dein Bild (https://www.mikrocontroller.net/attachment/preview/698325.jpg) zeigt zwei lsblk-Befehle und deren Ergebnisse. Liegt dazwischen WIRKLICH kein Bootvorgang? Falls doch, ist das Bild so irreführend wie deine früheren Bilder. Es wurde dann nichts vertauscht, sondern lediglich nach dem Booten anders zugeordnet. Womit man immer rechnen muss, wie inzwischen x-mal erklärt. > Also vertauscht nicht Clonzilla sda mit sdb, sondern das macht mein > Notebook Die Hardware des Notebooks weiß gar nichts von sda und sdb. Das sind Bezeichnungen, die Linux im Rahmen seines Startvorgangs in eigener Regie vergibt.
.● Des|ntegrator ●. schrieb: >> Seit ca. 100 Jahren gibt es die Quantenmechanik. > und was war vorher? > nur schwarz-weiss? Vorher gab es den Laplace'schen Dämon. Der konnte den Fall jedes Würfels vorhersagen. https://de.wikipedia.org/wiki/Laplacescher_Dämon
Rolf schrieb: > Seit ca. 100 Jahren gibt es die Quantenmechanik. Danach gibt es "im ganz > Kleinen" keinen Determinismuss, sondern nur Wahrscheinlichkeiten. In der Quantenmechanik gibt es Dinge, die wir nicht vorhersagen können, und von denen es unmöglich für uns ist, sie zu Messen oder sonst wie herauszufinden. Das muss aber nicht heissen, dass diese Vorgänge tatsächlich zufällig sind. Das ist halt allgemein das Problem mit dem Zufall, man kann sich nie wirklich sicher sein, dass etwas wirklich zufällig ist. (Und um das schonmal vorweg zu nehmen, nein, auch Bell kann uns nicht endgültig sagen, ob die Welt deterministisch ist, oder nicht).
Daniel A. schrieb: > In der Quantenmechanik gibt es Dinge, die wir nicht vorhersagen können, > (...) > Das muss aber nicht heissen, dass diese Vorgänge tatsächlich zufällig > sind. Nein, dass muss es nicht heißen. Aber nach herrschender Wissenschafts-Meinung heißt es genau das. Übrigens gibt es auch Vorgänge, für deren Nichtvorhersagbarkeit man die Quantenmechanik gar nicht bemühen muss. Ich sage nur: Chaostheorie. > Und um das schonmal vorweg zu nehmen, nein, auch Bell kann uns nicht > endgültig sagen, ob die Welt deterministisch ist, oder nicht. Nach Jaspers gibt es Endgültigkeit in der Erkenntnistheorie nicht. Aber laut Wikipedia sagen bisher alle Bell-Tests, dass Einsteins "Gott würfelt nicht!" unhaltbar ist. Solange da nicht jemand etwas Gegenteiliges vorzeigen kann ...
Man muss schon im Auge behalten, was die Bell-Tests tatsächlich zeigen. Man könnte es auch so verstehen, dass die Resultate global / Zeitlos im vornherein klar waren. Und würde das nicht sogar für den Determinismus sprechen? Solange da nicht jemand etwas Gegenteiliges vorzeigen kann ... Also alles kein Grund, das eine oder das andere anzunehmen.
Norbert schrieb: > Hans H. schrieb: >> Habe mal VER eingebaut, das erzeugt hier nur eine Fehlermeldung. > > Wundert mich nicht. Weil ich es aus Versehen falsch herum angegeben > habe.lsblk -oNAME,SIZE,MODEL,REV,SERIAL | egrep '^NAME|sd[a-z][^0-9]' > So isses besser. Jo, so sieht es bedeutend netter aus. Wobei REV die Firmwareversion der Platte anzeigt und nicht die MDL. Clonezilla und auch Windows zeigen die frisch formatierte Testplatte im DVD-Schacht als WD1200BEVS-08RST2 an. So steht es auch auf dem Label der Platte. Habe jetzt mal bei meinem 14" IBM-Thinkpad diese 120GB-Platte als zweite Platte in den DVD-Schacht eingeschoben, das Notebook eingeschaltet und Ubuntu gebootet. Bei dem Gerät stimmt die Zuordnung von sda und sdb, die zweite Platte im DVD-Schacht ist die Zielplatte (sdb), siehe Bild 1. Bei meinem 15" IBM-Thinkpad steckte ebenfalls die 120GB-Platte als zweite Platte im DVD-Schacht. Bei genau gleicher Startmethode ist die Zuordnung nun eine andere, sda/sdb sind vertauscht. Die fest eingebaute Platte mit 160GB wird zur Zielplatte (sdb), siehe Bild 2. Rolf schrieb: > Liegt dazwischen WIRKLICH kein Bootvorgang? Da lag ein Bootvorgang dazwischen, ist aber jetzt hinfällig. Das wirkliche Problem ist den beiden vorigen Absätzen beschrieben und in den beiden Bildern dokumentiert. Die Angabe bei Clonezilla bzgl. der Auswahl von Quell- und Zielplatte, "sda ist die erste Platte und sdb die zweite Platte" dürfte so dort nicht stehen, da sda und sdb offensichtlich beliebig sind.
:
Bearbeitet durch User
Hans H. schrieb: > Das wirkliche Problem sitzt vorm Bildschirm, Hans H. schrieb: > da sda und sdb offensichtlich beliebig sind.
Hans H. schrieb: > Die Angabe bei Clonezilla bzgl. der Auswahl von Quell- und Zielplatte, > "sda ist die erste Platte und sdb die zweite Platte" dürfte so dort > nicht stehen, da sda und sdb offensichtlich beliebig sind. Clonezilla gibt absolut korrekt an, welche Platte als Erste, als Zweite usw. detektiert wird. Es ist nur deine Wahrnehmung, dass eine von dir präferierte Platte unbedingt die "Erste" sein muss.
Hans H. schrieb: >> Liegt dazwischen WIRKLICH kein Bootvorgang? > Da lag ein Bootvorgang dazwischen Aha, also hast du uns irreführende Informationen gegeben und deren Bedeutung - obwohl es dir von mehreren hier x-mal erklärt wurde - immer noch nicht verstanden. Ein ganz kleiner Abstraktionsschritt für viele, ein großer für so manchen (Neil Armstrong der Zweite).
Norbert schrieb: > Es ist nur deine Wahrnehmung, dass eine von dir präferierte Platte > unbedingt die "Erste" sein muss. Dann mal anders: Ein User hat ein Notebook mit einer fest eingebauten Platte. Nach dem Booten von Ubuntu zeigt ihm das Kommando lsblk die fest eingebaute Platte als erste Platte im System an (sda). Dann schiebt der User im laufenden Betrieb eine zweite Platte in den DVD-Schacht, selbige wird ihm dann vom Kommando lsblk als zweite Platte im System angezeigt (sdb). Nun schaltet der User sein Notebook aus und wieder ein, das Kommando lsblk wird ihm nun die fest eingebaute Platte als zweite Platte (sdb) anzeigen und die neu hinzugekommene Platte als erste Platte (ada). Wie erklärst du dem User die dahinter steckende Logik?
Hans H. schrieb: > Wie erklärst du dem User die dahinter steckende Logik? Intrusion bzw. Schadsoftware.
Hans H. schrieb: > Wie erklärst du Der Rechner erkennt das Laufwerk im DVD-Schacht beim Bootvorgang zuerst wenn eines vorhanden ist und das wird dann sda. Manchmal ist das im BIOS konfigurierbar (Bootreihenfolge) ob die "externen" Laufwerke als erstes erkannt werden. Nachtrag: Stand hier auch schon Jack V. schrieb: > es geht dabei darum, welche > Platte sich zuerst am Controller anmeldet.
:
Bearbeitet durch User
Hängst Du etwas nachträglich ein landet es weiter hinten, nämlich da wo noch was frei ist. Es sei denn, man hat wie in Windows einen Laufwerksbuchstaben schon reserviert. Der Kernel vergibt die Buchstaben in der Reihenfolge in der er die Geräte findet, welche Festplatte auch immer zuerst ready meldet. SATA‑Controller werden in der Reihenfolge ihrer PCI‑Busnummern abgefragt; jeder SATA-Controller hat mehrere Ports, aus der sich eine Reihenfolge (für den Scan) ergibt. Eine HDD kann auch an manchen Tagen etwas länger zum Spindeln brauchen als die andere. Das ist vollkommen deterministisch, selbst wenn es willkürlich aussieht. Und wenn es am Ende die Kapazität eines bestimmten Kondensators ist.
Hans H. schrieb: > Wie erklärst du dem User die dahinter steckende Logik? So wie ich es zuvor (aber anscheinend erfolglos) erklärte. Norbert schrieb: > … gibt absolut korrekt an, welche Platte als Erste, als Zweite > usw. detektiert wird. Versuchen wir's anders. Zwei SATA Anschlüsse. Die interne Platte steckt an Anschluss Zwei. Sie wird beim booten erkannt ──▶ sda Eine Zweite wird nun im Betrieb an Anschluss Eins hinzu gefügt. Sie wird erkannt ──▶ sdb Nun wird gebootet. Anschluss Eins wird zuerst abgefragt ──▶ sda Anschluss Zwei wird abgefragt ──▶ sdb Voilà
Bitte das Wort "arbitrary" beachten: (https://dict.leo.org/englisch-deutsch/arbitrary)
1 | This article describes how to use persistent names for your block devices. This has been made possible by the introduction of udev and has some advantages over bus-based naming. If your machine has more than one drive sharing a naming scheme, the order in which their corresponding device nodes are added is arbitrary. This may result in block device names (e.g. /dev/sda and /dev/sdb, /dev/nvme0n1 and /dev/nvme1n1, /dev/mmcblk0 and /dev/mmcblk1) switching around on each boot, culminating in an unbootable system, kernel panic, or a block device disappearing. Persistent naming solves these issues. |
https://wiki.archlinux.org/title/Persistent_block_device_naming
G. K. schrieb: > switching around on each boot, culminating in an unbootable system, Deshalb wird /dev/sdxn ja auch seit gefühlten zwei Jahrzehnten nicht mehr in dieser Form in fstab genutzt. Debian zB. nutzt wohl UUID= als Standard, aber LABEL= macht fstab noch schöner les- und pflegbar. Das geht sogar mit swap-Partitionen. Alles natürlich IMNSHO.
Alexander schrieb: > UUID wird mitgeklont, hatten wir schon. Das bezog sich NICHT auf den Klon-Vorgang, sondern auf G.K.s korrekten Einlass bzgl. persistent naming
Norbert schrieb: > persistent naming by-id WWN wäre relevant gewesen. UUID wurde schon im Beitrag #2 genannt. Norbert schrieb: > nur (im Sinne von ausschließlich) /dev/disk/by-id/ enthält von der > Hardware abgeleitete Namen, welche wie oben schon gelistet zB. auch > SERIAL beinhalten.
:
Bearbeitet durch User
Wer darauf besteht ein System zu booten in welchem sich zwei Daten- identische Festplatten befinden, gleiche UUIDs, gleiche LABELs, macht bereits zu Anfang einen kolossalen Fehler. Nicht umsonst ist die erste Aktion nach dem Klonen eines Dateisystems, dessen UUID neu zu vergeben. Und wer halbwegs schlau ist macht das natürlich auch mit den LABELs (und allem was dazu gehört). Wir müssen uns hier jetzt nicht über Möglichkeiten unterhalten diese Blödheit nun irgendwie herum und gerade zu biegen.
Norbert schrieb: > Versuchen wir's anders. Norbert hats auf den Punkt gebracht. Und Schuld an der Misere ist nicht Clonezlla, sondern Lenovo, weil die bei diesem Modell hier die Idee hatten, die fest eingebaute "Platte" nicht am ersten SATA-Port zu betreiben, sondern am zweiten, und den ersten SATA-Port für den Wechselschacht vorzusehen.
Harald K. schrieb: > Und Schuld an der Misere ist nicht Clonezlla, sondern Lenovo, weil die > bei diesem Modell hier die Idee hatten, die fest eingebaute "Platte" > nicht am ersten SATA-Port zu betreiben, sondern am zweiten, und den > ersten SATA-Port für den Wechselschacht vorzusehen. Ich erzähl euch mal was, was sich in unserer Firma tatsächlich so ereignet hat. Wir haben hier in der Firma VMWare. Fest definierte Festplatten, feste Reihenfolge von der Hardware / Firmware Perspektive. Die Schlaumeier von unserer Linux Server Abteilung haben dann die durchnummerierten Devicenamen genommen, statt UUIDs. Das Resultat: Die Betriebsabteilung durfte nun die Server jeweils 2-3 mal neu starten, bis die Reihenfolge wieder zufällig passte. Nach einem Jahr oder so wurde das dann irgendwann behoben.
Daniel A. schrieb: > Die Schlaumeier von Habe schon den einen oder anderen Euphemismus gesehen, dieser gewinnt haushoch. ;-) > unserer Linux Server Abteilung haben dann die durchnummerierten > Devicenamen genommen, statt UUIDs.
An was klebt eigentlich Windows seine Laufwerksbuchstaben fest? Folgende Situation: Windows Kiste mit 2 Platten auf denen jeweils eine Partition ist. Jetzt wird D: geclont und sowohl der clone und das Orginal von D: bleiben angeschlossen und Windows wird neu gebootet. Welche Platte wird jetzt D:? Der Clone oder das Orginal?
G. K. schrieb: > An was klebt eigentlich Windows seine Laufwerksbuchstaben fest? UUIDs sind eigentlich eine ziemlich gute Idee, also wollte MS die nicht. Die nutzen - WIMRE - eine Volumen-basierte Seriennummer. Kann und sollte man nach dem Klonen ebenfalls ändern. Wie aber deren internes mapping aussieht, da muss ich passen. Zu lang ist's her.
Windows schreibt ungefragt System Volume Information auf jede Platte. Und im proprietären NTFS Dateisystem sollen sich angeblich unsichtbare Metadaten verstecken lassen, die über MFT und ACLs hinaus gehen
Rbx schrieb: > Daniel A. schrieb: >> nach einem Jahr oder so wurde das dann >> irgendwann behoben. > Wie denn genau? Seither wird die UUID verwendet. Ich weiss nicht, wie genau das ausgerollt wurde, ich vermute mal per salt oder so.
Harald K. schrieb: > weil die > bei diesem Modell hier die Idee hatten, die fest eingebaute "Platte" > nicht am ersten SATA-Port zu betreiben, sondern am zweiten, und den > ersten SATA-Port für den Wechselschacht vorzusehen. Der physische Port ist an dieser Stelle völlig egal (Ausnahme: man hat via udev etwas festgenagelt). Es zählt einzig, welches Laufwerk sich auf der Zeitachse zuerst beim Controller anmeldet. Um es bildlich darzustellen: Wenn der TE eine Festplatte und eine SSD hätte, wär’s egal, was er an welchem Port anschließt – die SSD würde beim Booten mit beiden Laufwerken installiert immer /dev/sda bekommen (gut, es sei denn, es ist eine NVMe-SSD, da bekommt’s dann /dev/nvme0 und die Platte wäre immer sda, aber das ist hier ja nicht der Fall) … und so oft, wie’s nun von verschiedenen Leuten in verschiedenen Worten hier im Thread dargestellt worden ist, sollte es eigentlich auch beim TE mal so langsam die Wahrnehmungsschwelle überschritten haben.
:
Bearbeitet durch User
Jack V. schrieb: > Der physische Port ist an dieser Stelle völlig egal (Ausnahme: man hat > via udev etwas festgenagelt). Es zählt einzig, welches Laufwerk sich auf > der Zeitachse zuerst beim Controller anmeldet. Ja, das sagt zumindest Red Hat. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/storage_administration_guide/persistent_naming > sollte es eigentlich auch beim TE mal so langsam die Wahrnehmungsschwelle > überschritten haben. Er ist halt darauf fixiert, dass irgendetwas an seiner Hard- oder Software etwas falsch macht. Nachdem die ursprüngliche Behauptung (siehe Betreff), es müsse CloneZilla sein, nicht zu halten war, muss es dann logischerweise das Notebook sein. Da kann man nichts machen: https://de.wikipedia.org/wiki/Falsche_Prämissse
Rolf schrieb: > Da kann man nichts machen: > https://de.wikipedia.org/wiki/Falsche_Prämissse LOL, wie dieser Link ;)
Mario M. schrieb: > Der Umlaut muss urlencoded werden. Tatsächlich geht’s mit Umlaut, die Browser codieren es on teh fly: https://de.wikipedia.org/wiki/Falsche_Prämisse – willkommen in der Gegenwart ;) Da war lediglich ein ›s‹ zuviel.
:
Bearbeitet durch User
Alexander schrieb: > Der Kernel vergibt die Buchstaben in der Reihenfolge in der er die > Geräte findet, welche Festplatte auch immer zuerst ready meldet. Das ist falsch.
Jack V. schrieb: > Es zählt einzig, welches Laufwerk sich auf > der Zeitachse zuerst beim Controller anmeldet. Das ist ziemlich unwahrscheinlich. Wenn zwei Laufwerke gleichschnell sind, ist nicht auszuschließen, daß mal das eine, mal das andere zuerst "da" meldet. Das Resultat wäre komplett unbrauchbar, weil nicht vorhersagbar. Nein, es wird sehr sicher der verwendete SATA-Port entscheiden. Die werden in aufsteigender Reihenfolge abgeklappert, und das erste vorgefundene Laufwerk ist halt das erste, d.h. sda. Natürlich, bei deutlich später stattfindenden Hotplug-Events wird nichts an der zum Startzeitpunkt des Systems vorgefundenen Reihenfolge geändert (sowas hätte ja auch zur Folge, daß der Devicename einer Platte mit gemounteten Dateisystemen verändert werden könnte, mit lustigen Auswirkungen). Aber auch bei Hotplug-Events: Wenn zwei Laufwerke gleichzeitig angestöpselt werden, entscheidet die SATA-Portnummer.
Harald K. schrieb: > Das ist ziemlich unwahrscheinlich. Wenn zwei Laufwerke gleichschnell > sind, ist nicht auszuschließen, daß mal das eine, mal das andere zuerst > "da" meldet. Es ist schlicht so, und ja: Das ist doch, worum es hier die ganze Zeit geht! Es kann sein, dass sich mal das eine, mal das andere Laufwerk zuerst meldet und entsprechend sda zugewiesen bekommt. Das ist dokumentiert, und falls einem das zuviele Buchstaben sind, habe ich weiter oben auch gezeigt, wie man es sich selbst live angucken kann, wenn man möchte. Das gleiche Spiel geht auch mit SATA-Platten (sofern du nicht eines der seltenen Boards hast, dessen Controller nicht hotplugfähig ist), falls du dich an dem USB störst. Für feste Zuordnungen gibt es nunmal Labels, UUIDs und andere Dinge, die man unter /dev/disk/ finden kann – einschließlich verwendeten Anschlusses, wenn man das nutzen möchte.
Harald K. schrieb: > Nein, es wird sehr sicher der verwendete SATA-Port entscheiden. Die > werden in aufsteigender Reihenfolge abgeklappert, und das erste > vorgefundene Laufwerk ist halt das erste, d.h. sda. Ich habe ein Board mit einem H55, der vergibt die Devices anders je nachdem ob AHCI aktiviert ist oder nicht. Ist dann noch mal ein dev an oder abgeklemmt ist die Reihenfolge wieder komplett anders. Hat man devs die 3Gbps können und welche die nur 1.5Gbps können ist es wieder anders, schaltet man die 3Gps devs per boot para auf 1.5 ist die Reihenfolge wieder anders. Ist ein bekannter Bug von diesem Scheisschipsatz.
Harald K. schrieb: > Nein, es wird sehr sicher der verwendete SATA-Port entscheiden. Die > werden in aufsteigender Reihenfolge abgeklappert, und das erste > vorgefundene Laufwerk ist halt das erste, d.h. sda. Zwar ist es üblicherweise einigermaßen statisch, und wenn beide Laufwerke beim Booten am Controller angemeldet sind, wird vermutlich aufsteigend übergeben, aber das Verhalten ist nicht definiert, und wie ich an anderer Stelle schon schrieb: Ich habe zwei Maschinen, bei denen die Reihenfolge ab und zu mal wechselt, und die ich daher auf mit den UUIDs in der Bootloader-Config festgenagelt habe, um ab und zu nicht bootbare Systeme zu vermeiden. Ich hab auch ’ne Maschine, bei der eine beim Booten an USB angeschlossene SSD ab und zu sda bekommt – nichts davon ist eine Fehlfunktion, das ist völlig normal und bei der Konfiguration des Systems entsprechend zu berücksichtigen. Am einfachsten, indem man eben UUIDs nimmt. Das zweite U steht für „unique“, wodurch man ziemlich sicher sein kann, damit das richtige Laufwerk anzusprechen. Nicht zuletzt dazu wurde der Kram schließlich erfunden.
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.








