Hallo,
habe eine Ubuntu-HD auf eine andere HD geklont. Nun kann man von der
geklonten HD nicht starten.
Wenn ich sie anschließe und den Rechner normal einschalte, lande ich in
einem Fenster mit folgender Anzeige:
1
GNU GRUB version 2.14
2
3
Minimal BASH-like line editing is supported. For the first word, TAB lists possible commands completitions. Anywhere else TAB lists possible device or file completitions. To enable less(1)-like paging, "set pager = 1".
4
5
grub>_
Kann jemand etwas damit anfangen und sagen, wie man nun am besten
vorgeht, wenn ich das so naiv fragen darf?
Richie schrieb:> Mit Linux Bootstick booten, Dateisysteme mounten (proc, sys, dev, run),> chroot, grub-install bzw. update-grub, fertig.
Wir arbeiten erst seit ein paar Monaten mit Linux-Mint. Kann man mit USB
booten und dann ein grub-install auf einer fremden Partition auf einer
Platte durchführen ?
Richie schrieb:> Mit Linux Bootstick booten, Dateisysteme mounten (proc, sys, dev,> run), chroot, grub-install bzw. update-grub, fertig.
Und Du glaubst, dass jemand der wie der TE fragt, mit chroot
zurechtkommt?
L. schrieb:> Kann man mit USB booten und dann ein grub-install auf einer fremden> Partition auf einer Platte durchführen ?
Das hab ich eben schnell mit einer Suchmaschine gefunden. Ich habe das
selber auch schon gemacht nach anderer Anleitung. ;)
Ob die verlinkten Anleitung fehlerfrei ist, kann ich deshalb nicht sagen
;)
Aber es hat sich niemand beklagt dort und meinem dafürhalten ist die OK.
https://forums.linuxmint.com/viewtopic.php?t=320504
Also im Prinzip das was Ritchie oben in Kurzform beschrieben hat.
Stephan S. schrieb:> Hast Du die ganze Platte, z.B. /dev/sda geklont oder nur die> Partitionen, z.B. /dev/sda1, /dev/sda2.>> Womit hats Du geklont?
Diese beiden Fragen sind meiner Ansicht nach zentral. Denn wenn wichtige
Teile fehlen oder auf der falschen Ebene kopiert wurde, kommt nach dem
Problem mit dem grub gleich das nächste.
Stephan S. schrieb:> Da fällt mir ein, dass der eine Rechner evtl UEFI im BIOS hatte und der> andere nicht.
Ob sich dann überhaupt ein GRUB melden würde? Ich glaube kaum.
900ss schrieb:> Stephan S. schrieb:>> Da fällt mir ein, dass der eine Rechner evtl UEFI im BIOS hatte und der>> andere nicht.>> Ob sich dann überhaupt ein GRUB melden würde? Ich glaube kaum.
Eine Hybridinstallation, die sowohl mit klassischem BIOS als auch mit
UEFI gebootet werden kann, ist nicht unüblich. Wenn es das ist dann war
die hier aber nicht vollständig aufgesetzt so dass nur der eine Teil
richtig funktioniert.
Dirk schrieb:> Hallo, habe eine Ubuntu-HD auf eine andere HD geklont. Nun kann man von der> geklonten HD nicht starten.
Wie wurde denn geklont? Klonen ist so was wie "cp /dev/sdX /dev/sdY" mit
sdX als Quelllaufwerk und sdY als Ziellaufwerk und sdY >= sdX.
Stephan S. schrieb:> Da fällt mir ein, dass der eine Rechner evtl UEFI im BIOS hatte> und der andere nicht.
Der TE schreibt nix von einem anderen Rechner
Hallo und schon mal Danke für die vielen Antworten!
Also, das Board hat UEFI Bios und Secure Boot ist aktiv.
Sowohl die alte, als auch die neue Platte sind mechanisch.
Der Klon wurde an einem Win-Rechner mit Minitool Shadowmaker erstellt
(habe ich schon öfter mit Ubuntuplatten so gemacht und bis jetzt hat es
immer problemlos funktioniert).
Im Shadowmaker-Fenster war über die beiden Platten zu lesen:
Source Disk: ... SCSI Disk Device
Destination Disk: ... ATA Bus
Beide Platten werden logischerweise über ein SCSI-Kabel angeschlossen
(natürlich immer nur eine gleichzeitig).
Dirk schrieb:> Ach ja, es wurde die ganze Platte komplett und in einem geklont.
Ja, und wie jetzt? Die vorgeblich geklonte Platte funktioniert am
gleichen Rechner nicht? Dann wurde sie halt nicht geklont. Ein Klon ist
funktionsgleich, ansonsten ist es kein Klon.
Du könntest jetzt ja mal beide Platten vergleichen, um Differenzen zu
sehen.
Nachtrag:
Und wo ich's gerade auf der Webseite des Tools, von dem es eine
kostenfreie (Test)version und Bezahlversionen gibt: Bei der kostenfreien
Version steht explizit, daß sie das Klonen der Systemfestplatte nicht
unterstützt. Solltest Du das Problem mit der Bezahlversion haben, richte
Dich für Support an den Hersteller. Schließlich bezahlst Du dafür.
Wenn Du die kostenfrei Version hast und es ging früher mal, dann schau
halt ob das noch die gleiche Softwareversion ist. Vielleicht hat sich ja
was an der Unterstützung über die Versionen geändert.
Vorweg: ich finde es großartig, daß hier so viele Leute versuchen, dem
TO zu helfen, wenngleich ihre eigene Linux-Erfahrung noch überschaubar
ist. Danke dafür, so geht Community, und deswegen macht es Spaß, selbst
ein Teil dieser Community sein zu dürfen!
Dirk schrieb:> habe eine Ubuntu-HD auf eine andere HD geklont.
Nicht wichtig, bin nur neugierig: warum?
> Wenn ich sie anschließe und den Rechner normal einschalte, lande ich in> einem Fenster mit folgender Anzeige:>>
1
> GNU GRUB version 2.14
2
>
3
> Minimal BASH-like line editing is supported. For the first word, TAB
4
> lists possible commands completitions. Anywhere else TAB lists possible
5
> device or file completitions. To enable less(1)-like paging, "set pager
6
> = 1".
7
>
8
> grub>_
9
>
>> Kann jemand etwas damit anfangen und sagen, wie man nun am besten> vorgeht, wenn ich das so naiv fragen darf?
Wichtig: meinen Kommentar bitte komplett lesen und erst dann etwas
machen! :-)
Okay, das ist gut, denn es ist die normale Grub-Shell, also nicht einmal
die Rescue-Shell. Normale Grub-Shell heißt: der Grub wurde ganz normal
geladen, aber er konnte das konfigurierte Root-Device nicht finden.
Mit dem Befehl "ls" kannst Du jetzt herausfinden, welche Disks Grub in
Deinem System findet, und auch in die Dateisysteme dieser Disks
hineinschauen. Eine (wie ich finde) sehr gute Beschreibung findest Du
hier [1], aber wenn Dir das zu schwierig ist, können wir es gerne
gemeinsam Schritt für Schritt machen.
Wichtig ist: Grub2 bezeichnet die Disks anders als Linux; während unter
Linux eine Disk zum Beispiel /dev/sda oder /dev/nvme0n1 heißt, numeriert
Grub2 die Disks einfach durch: (hd0) ist die erste HD, (hd1) die zweite,
und so weiter. Bei den Partitionen heißt es bei Linux dann /dev/sda1
oder /dev/nvme0n1p1, in Grub2 hingegen sehen Bezeichner wie (hd0,1) für
die erste Partition auf der ersten Disk oder (hd1,2) für die zweite
Partition auf der zweiten Disk aus. Achtung: die Nummern der Disks
beginnen mit 0, die der Partitionen mit 1.
Die Grub2-Shell unterstützt im Übrigen auch die Tab-Completion. Wenn Du
also einen eindeutigen Beginn für eine Anweisung oder einen Parameter
angibst und dann auf die <TAB>-Taste drückst, wird die Grub-Shell die
Eingabe automatisch
vervollständigen. Wenn Deine bisherige Angabe nicht eindeutig war, hilft
ein zweiter Druck auf die <TAB>-Taste, um Dir die Auswahlmöglichkeiten
anzuzeigen. Nur wenn ein zweimaliger Druck auf die <TAB>-Taste weder
vervollständigt noch eine Auswahl anzeigt, wurde keine Entsprechung zu
Deiner Eingabe gefunden. Ah so, das klappt auch wenn Du noch gar keine
Eingabe gemacht hast.
Wenn Du Dein System gebootet hast, mußt Du die Konfiguration bootfest
machen. Dazu findest Du zuerst mit einem der Befehle "lsblk" oder
"mount" heraus, wo Dein Root-Verzeichnis / ist, dann führst Du als root
den Befehl "update-grub" zur Erzeugung einer neuen Grub2-Konfiguration
und dann, ebenfalls als root, den Befehl "grub-install <Gerät>" -- und
wenn Dein Root-Verzeichnis auf der Partition /dev/sda1 liegt, ist
"Gerät" also die ganze Disk, also /dev/sda.
Zu viel, zu schnell, zu...? Dann laß' uns das gemeinsam
Schritt-für-Schritt machen. Fang' mit "ls" an, was gibt das aus?
[1]
https://www.linuxfoundation.org/blog/blog/classic-sysadmin-how-to-rescue-a-non-booting-grub-2-on-linux
Hallo, Danke für die Antworten!
@Ein T. (ein_typ):
Vielen Dank für die ausführliche Antwort und das freundliche Angebot! :)
> Mit dem Befehl "ls" kannst Du jetzt herausfinden, welche Disks Grub in> Deinem System findet, und auch in die Dateisysteme dieser Disks> hineinschauen.
Das schaue ich heute Abend als erstes und melde mich dann wieder.
Daniel A. schrieb:> Ich nehme mal an, die unbekannte Software welche zum "klonen" verwendet> wurde, hat die UUID der Partitionen geändert.
Meinst du mit unbekannter Software das von mir verwendete "Minitool
Shadowmaker Free 3.1"?
Michael L. schrieb:> Ja, und wie jetzt? Die vorgeblich geklonte Platte funktioniert am> gleichen Rechner nicht?
Meine Erfahrung, wenn man damit Win-HDs klont, muss man über den Klon
anschließend noch chkdsk laufen lassen, damit es funktioniert. Ubuntu
ging bis jetzt immer problemlos ohne irgendwelche Zusatzmaßnahmen zu
klonen.
Daniel A. schrieb:> Ich nehme mal an, die unbekannte Software welche zum "klonen" verwendet> wurde, hat die UUID der Partitionen geändert.
Wie findet man das raus?
Dirk schrieb:> Ubuntu ging bis jetzt immer problemlos ohne irgendwelche Zusatzmaßnahmen zu> klonen.
Hast du auf völlig leere Platten geklont? Wenn nicht, kann es z. B.
sein, dass die zum Booten benötigten Daten bisher zufällig von früher
auf der Platte waren. Dann wäre es kein echter Klon.
Der sich jetzt meldende Grub war dann vielleicht auch schon vorher da,
passt nur jetzt nicht mehr ohne Nacharbeit.
Ein T. schrieb:> Mit dem Befehl "ls" kannst Du jetzt herausfinden, welche Disks Grub in> Deinem System findet, und auch in die Dateisysteme dieser Disks> hineinschauen.
Das habe ich gemacht und das Ergebnis sieht so aus:
1
grub> ls
2
(memdisk) (proc) (hd0) (hd0,gpt2) (hd0,gpt1)
3
grub> _
Die Befehle "mount" und "lsblk" bringen jeweils den Error "can't find
command"
So viel erst mal dazu.
Rolf schrieb:> Hast du auf völlig leere Platten geklont?
Nein und das habe ich bisher immer so gemacht. Aber Danke für den
Hinweis, da kann schon was dran sein. Wobei bei Ubuntu eins zu eins
übertragen werden müsste, nur unter Win ist es dem Programm real
möglich, nur genutzte Daten/Sektoren zu klonen (das kann man auch für
Ubuntu-Klone anklicken, bringt aber nichts).
Nemopuk schrieb:> https://wiki.ubuntuusers.de/GRUB_2/Reparatur/
Man könnte eine Grub-Repairdisk booten, und schauen, ob die hilft. Denn
wenn der Grub-Bootordner schon vorher dicht war, dann kann das schon
sein, dass der jetzt wenn auch nur ein klein wenig - überladen ist.
Dirk schrieb:> Ein T. schrieb:>> Mit dem Befehl "ls" kannst Du jetzt herausfinden, welche Disks Grub in>> Deinem System findet, und auch in die Dateisysteme dieser Disks>> hineinschauen.>> Das habe ich gemacht und das Ergebnis sieht so aus:>>
1
> grub> ls
2
> (memdisk) (proc) (hd0) (hd0,gpt2) (hd0,gpt1)
3
> grub> _
4
>
Okay, prima, sieht doch super aus. Dann benutzen wir wieder den Befehl
"ls", aber mit Parametern:
1
grub> ls (hd0,1)/
und
1
grub> ls (hd0,2)/
(Die beiden Befehle unterscheiden sich nur in der Partitionsnummer, den
/ am Ende solltest Du IIRC auch weglassen können.)
In einer der beiden Partitionen sollte das Verzeichnis "boot" liegen,
also entweder in (hd0,1) oder in (hd0,2). Das Verzeichnis "boot" zeigst
Du dann mit der betreffenden Partition an, also zum Beispiel
1
grub> ls (hd0,1)/boot
oder
1
grub> ls (hd0,2)/boot
In dem betreffenden Verzeichnis "boot" liegen dann ein Kernel und eine
Initrd; der Dateiname des Kernels beginnt mit "vmlinuz-" und der der
Initrd mit -- was eine Überraschung -- mit "initrd.img-". Vermutlich
liegen mehrere Kernels und mehrere Initrds in diesem Verzeichnis, wir
nehmen die mit der höchsten Version -- und, wichtig: die Versionsnummern
von Kernel und Initrd müssen gleich sein, also zum Beispiel
vmlinuz-6.8.0-100-generic und initrd.img-6.8.0-100-generic.
Wenn Du unsicher bist, kannst Du die Ausgabe der Befehle jetzt noch
einmal posten, ansonsten sehen die Befehle zum Booten zum Beispiel für
die Partition (hd0,2) -- das ist unter Linux /dev/sda2, bitte beachte
den Parameter "root" bei der Angabe des Kernels unten -- sowie meine
Beispiele für Kernel und Initrd wie folgt aus:
1
grub> set root=(hd0,2)
2
grub> linux /boot/vmlinuz-6.8.0-100-generic root=/dev/sda2
3
grub> initrd /boot/initrd.img-6.8.0-100-generic
4
grub> boot
> Die Befehle "mount" und "lsblk" bringen jeweils den Error "can't find> command"
Diese Befehle stehen Dir erst zur Verfügung, wenn das System gebootet
ist. Aber dazu müssen wir es natürlich erst einmal booten. :-)
Viel Glück und Erfolg! :-)
Rolf schrieb:> Hast du auf völlig leere Platten geklont? Wenn nicht, kann es z. B.> sein, dass die zum Booten benötigten Daten bisher zufällig von früher> auf der Platte waren. Dann wäre es kein echter Klon.
Das ist, ebenso wie jene von Daniel, eine naheliegende Vermutung, wenn
die kostenlose Version des Klon-Werkzeuges keine Systempartitionen, also
wohl nicht den MBR und / oder die GPT kopiert. Vielleicht wäre dem TO
besser mit GParted [1] gedient, der ist zwar nicht hübsch, funktioniert
aber wunderbar ohne irgendwelche Einschränkungen. Aber laßt uns ihm
erstmal helfen, sein System zu boooten, und danach kümmern wir uns um
den Rest.
[1] https://gparted.org/
Rbx schrieb:> Man könnte eine Grub-Repairdisk booten, und schauen, ob die hilft.
Das könnte man machen, aber das wäre nicht besonders klug. Denn der TO
kommt ja in die normale Grub-Shell, die mehr Funktionalität hat und zum
Booten des Systems weniger Einstellungen benötigt als die Grub Rescue
Shell.
Ich würde erst mal die Super Grub2 Disk probieren und nachsehen, ob
überhaupt ein System auf der Ziel-Platte ist, wenn ja, dann in dieses
mit SGD hineinbooten und von Ubuntu aus Grub reparieren.
Ansonsten holst Du Dir Clonezilla, bootest das und klonst device-device
und zwar die Platten, nicht die Partitionen. Dann hast Du einen exakten
und überprüften Klon.
Man kann ja an diesem Problem herumdoktoren soviel man will, aber sollte
der nächste Versuch nicht vielleicht ein RICHTIGES klonen sein?
Zumal die benötigte Art von korrekt arbeitenden Werkzeugen bereits
kostenlos im »Linux Paket« enthalten sind?
Stephan S. schrieb:> Ich würde erst mal die Super Grub2 Disk probieren und nachsehen, ob> überhaupt ein System auf der Ziel-Platte ist, wenn ja, dann in dieses> mit SGD hineinbooten und von Ubuntu aus Grub reparieren.
Meine Güte, da hat ja mal einer richtig aufgepaßt... NICHT!
Warum das eine dumme Idee ist, hatte ich hier [2] bereits erklärt --
direkt über Deinem Beitrag übrigens.
[1] Beitrag "Re: Ubuntu-HD geklont, bootet aber nicht richtig"
Norbert schrieb:> Man kann ja an diesem Problem herumdoktoren soviel man will, aber sollte> der nächste Versuch nicht vielleicht ein RICHTIGES klonen sein?
Genau dieses Klonen ist ja gerade das, was offensichtlich fehlgeschlagen
ist und zu der aktuellen Situation geführt hat, daß das System nicht
bootet. Dein Vorschlag ist jetzt also, genau diesen fehlgeschlagenen
Vorgang nochmals zu wiederholen. Äh, ja.
"Wahnsinn ist, immer wieder dasselbe zu tun und unterschiedliche
Ergebnisse zu erwarten." (Albert Einstein zugeschrieben, vermutlich
fälschlich)
> Zumal die benötigte Art von korrekt arbeitenden Werkzeugen bereits> kostenlos im »Linux Paket« enthalten sind?
Ja, aber damit fühlt sich der TO anscheinend nicht sicher genug,
weswegen er lieber diese ehrwürdige Windows-Software benutzt hat.
Leute! Der TO kommt in eine ganz normale Grub Shell. Die
Wahrscheinlichkeit, daß er nur ein paar einfache Befehle eingeben muß,
damit das System bootet, liegt mindestens bei 95%. Und da empfehlt Ihr
dem TO lieber kontraproduktive Maßnahmen wie das Booten in eine deutlich
beschränkte Rescue Shell anstelle der normalen Grub Shell, die er ja
schon hat -- beziehungsweise zeitaufwändige und potentiell destruktive
Maßnahmen wie ein erneutes Klonen, obwohl das doch genau das ist, das
überhaupt erst zu dieser Situation geführt hat?
Ehrlich, bisher hatte ich uxdx und Dich für vernünftig gehalten. Da muß
ich wohl nochmal intensiv drüber nachdenken. :-)
Ein T. schrieb:> Genau dieses Klonen ist ja gerade das, was offensichtlich fehlgeschlagen> ist und zu der aktuellen Situation geführt hat, daß das System nicht> bootet. Dein Vorschlag ist jetzt also, genau diesen fehlgeschlagenen> Vorgang nochmals zu wiederholen. Äh, ja.
Nein, lies noch einmal, aber richtig.
Dieses windige Windows Werkzeug hat anscheinend gepatzt und nur partiell
gearbeitet.
Mit den in jeder Distribution enthaltenen Werkzeugen geht es hingegen
OHNE jeden Patzer (was schon Millionenfach bewiesen wurde).
Wenn die Original-Festplatte noch normal funktioniert, würde ich
Clonezilla auf ne CD brennen oder davon nen bootfähigen USB-Stick
erstellen. Dann davon booten und eine Festplatten-Direktkopie machen.
Funktioniert eigentlich immer gut und da gibts auch Anleitungen im
Internet für.
Ein T. schrieb:> Stephan S. schrieb:>> Ich würde erst mal die Super Grub2 Disk probieren und nachsehen, ob>> überhaupt ein System auf der Ziel-Platte ist, wenn ja, dann in dieses>> mit SGD hineinbooten und von Ubuntu aus Grub reparieren.>> Meine Güte, da hat ja mal einer richtig aufgepaßt... NICHT!>> Warum das eine dumme Idee ist, hatte ich hier [2] bereits erklärt --> direkt über Deinem Beitrag übrigens.>> [1] Beitrag "Re: Ubuntu-HD geklont, bootet aber nicht richtig"
Es sprach der grosse Linux-Experte. Wenn der jemals mit der SGD
gearbeitet hätte, wüsste er mehr.
Dirk schrieb:> Meine Erfahrung, wenn man damit Win-HDs klont, muss man über den Klon> anschließend noch chkdsk laufen lassen, damit es funktioniert.
Ehrlich gesagt, mir stehen bei diesem Satz die Haare zu Berge. Wenn du
Pech hast, ist das Laufwerk beschädigt.
Norbert schrieb:> Dieses windige Windows Werkzeug hat anscheinend gepatzt und nur partiell> gearbeitet.
Möglich. Das wissen wir aber nicht wirklich sicher.
> Mit den in jeder Distribution enthaltenen Werkzeugen geht es hingegen> OHNE jeden Patzer (was schon Millionenfach bewiesen wurde).
Möglich. Was wir aber nicht wissen, ist, ob das in unserem Fall zum
gewünschten Erfolg führt.
Denn: Wir wissen ja nicht, ob die Disk, die der OP klonen möchte,
wirklich für sich alleine das darauf enthaltene Ubuntu booten kann.
Davon hat er nichts gesagt, und beim Klonen war noch mindestens eine
andere Disk im Rechner, nämlich die, auf der das Windows-Tool lief.
Kann also sein, dass man schon von der Original-Disk nur booten kann,
wenn zu dem Zeitpunkt im selben Rechner auf einer anderen Disk
entsprechende Daten sind. Zum Beispiel hat der OP vielleicht einen Grub
oder anderen Bootmanager auf C:, der beim Klonen von D: natürlich nicht
mitkommt – auch mit dem besten Klone-Tool der Welt nicht.
In diesem Licht betrachtet hat T. nicht so ganz unrecht.
Norbert schrieb:> Dieses windige Windows Werkzeug hat anscheinend gepatzt und nur partiell> gearbeitet.
Möglich. Das wissen wir aber nicht wirklich sicher.
> Mit den in jeder Distribution enthaltenen Werkzeugen geht es hingegen> OHNE jeden Patzer (was schon Millionenfach bewiesen wurde).
Möglich. Was wir aber nicht wissen, ist, ob das in unserem Fall zum
gewünschten Erfolg führt.
Denn: Wir wissen ja nicht, ob die Disk, die der OP klonen möchte,
wirklich für sich alleine das darauf enthaltene Ubuntu booten kann.
Davon hat er nichts gesagt, und beim Klonen war noch mindestens eine
andere Disk im Rechner, nämlich die, auf der das Windows-Tool lief.
Kann also sein, dass man schon von der Original-Disk nur booten kann,
wenn zu dem Zeitpunkt im selben Rechner auf einer anderen Disk
entsprechende Daten sind. Zum Beispiel hat der OP vielleicht einen Grub
oder anderen Bootmanager auf C:, der beim Klonen von D: natürlich nicht
mitkommt – auch mit dem besten Klone-Tool der Welt nicht.
In diesem Licht betrachtet hat @T. nicht so ganz unrecht.
Rolf schrieb:> Möglich. Was wir aber nicht wissen, ist, ob das in unserem Fall zum> gewünschten Erfolg führt.
Nicht möglich, SICHER!
Es ging zunächst einmal um den Prozess des Klonens selbst.
Und … das … funktioniert mit den Linux Werkzeugen ›beyond any doubt‹
Und wenn man das zuvor geklonte Quell-Laufwerk durch das Ziel-Laufwerk
ersetzt, dann sollte dieses – da es Bit für Bit identisch ist – genau so
funktionieren.
Rolf schrieb:> Zum Beispiel hat der OP vielleicht einen Grub> oder anderen Bootmanager auf C:, der beim Klonen von D: natürlich nicht> mitkommt – auch mit dem besten Klone-Tool der Welt nicht.
Und warum sollte sich der dann anders verhalten?
Ach ja, noch eines. Dass sich das Ganze dann eventuell auf einem anderen
Rechner abspielen soll, dass gibt die ursprüngliche Beschreibung nicht
im Geringsten her.
Ein T. schrieb:> Das ist, ebenso wie jene von Daniel, eine naheliegende Vermutung, wenn> die kostenlose Version des Klon-Werkzeuges keine Systempartitionen, also> wohl nicht den MBR und / oder die GPT kopiert.
Ich denke mal, diese Einschränkung gilt nur für eine System-Partition,
von der man gerade gebootet hat. Also z.B., wenn er die gerade laufende
Windows-C-Part. kopieren wöllte ...
Ein T. schrieb:> "Wahnsinn ist, immer wieder dasselbe zu tun und unterschiedliche> Ergebnisse zu erwarten." (Albert Einstein zugeschrieben, vermutlich> fälschlich)
Komisch. Bei mir sind die Ergebnisse immer unterschiedlich.
Wenn ich eine Kohle in den Eimer werfe, dann ist eine Kohle drin.
Dann werfe ich wieder eine Kohle rein - nun sind zwei Kohlen drin - ein
anderes Ergebnis ... ;-)
Rbx schrieb:> Dirk schrieb:>> Meine Erfahrung, wenn man damit Win-HDs klont, muss man über den Klon>> anschließend noch chkdsk laufen lassen, damit es funktioniert.>> Ehrlich gesagt, mir stehen bei diesem Satz die Haare zu Berge. Wenn du> Pech hast, ist das Laufwerk beschädigt.
Nur das Filesystem, nicht das Laufwerk ...
Norbert schrieb:>> Möglich. Was wir aber nicht wissen, ist, ob das in unserem Fall zum>> gewünschten Erfolg führt.>> Nicht möglich, SICHER!> Es ging zunächst einmal um den Prozess des Klonens selbst.> Und … das … funktioniert mit den Linux Werkzeugen ›beyond any doubt‹
Was verstehst du an "in unserem Fall" nicht?
> Und wenn man das zuvor geklonte Quell-Laufwerk durch das Ziel-Laufwerk> ersetzt, dann sollte dieses – da es Bit für Bit identisch ist – genau so> funktionieren.
Circulus vitiosus. Außerdem hat der OP nicht von solchem Ersetzen
gesprochen, sondern nur vom Anschließen. Beim zusätzlichen Anschließen
kann das Booten je nach Einstellungen im BIOS anders ablaufen.
>> Zum Beispiel hat der OP vielleicht einen Grub>> oder anderen Bootmanager auf C:, der beim Klonen von D: natürlich nicht>> mitkommt – auch mit dem besten Klone-Tool der Welt nicht.>> Und warum sollte sich der dann anders verhalten?
Der verhält sich gar nicht, weil er nicht auf der geklonten Platte ist.
:-P
> Dass sich das Ganze dann eventuell auf einem anderen> Rechner abspielen soll, dass gibt die ursprüngliche Beschreibung nicht> im Geringsten her.
Das Gegenteil gibt sie auch nicht her. Jedenfalls: Wenn ich so einen
Laufwerk-Klone herstelle, dann tue ich das nur, um ein System auf einen
anderen/weiteren Rechner zu übertragen.
Rolf schrieb:> Das Gegenteil gibt sie auch nicht her. Jedenfalls: Wenn ich so einen> Laufwerk-Klone herstelle, dann tue ich das nur, um ein System auf einen> anderen/weiteren Rechner zu übertragen.
Also ich mache so etwas um zB. von einem kleineren auf ein größeres
Laufwerk zu wechseln. Oder von Rost auf Silizium. Oder zurück. Und noch
aus vielen anderen Gründen.
Dirk schrieb:> Hallo,> habe eine Ubuntu-HD auf eine andere HD geklont. Nun kann man von der> geklonten HD nicht starten.>...............>> Kann jemand etwas damit anfangen und sagen, wie man nun am besten> vorgeht, wenn ich das so naiv fragen darf?
Wir arbeiten noch nicht lange mit Linux, hatten aber in letzter Zeit
viel mit Partionen einrichten, klonen usw. zu tun.
Hier eine Beschreibung, wie wir vorgehen würden.
Ziel-Platte komplett löschen mit Gparted und z.B. mit Fat32 formatieren,
um evtl. Datenreste zu überschreiben.
Darauf achten dass, Ziel-Platte etwas größer ist als Quell-Platte.
Dann mit erprobter Software klonen. Wir machen das üblicherweise täglich
als Datensicherung für zwei Sata-Platten ohne Computer auf Knopfdruck
mit einer preisgünstigen Docking-Station. Geht sehr schnell.
Wir wünschen viel Erfolg !
L. schrieb:> Wir arbeiten noch nicht lange mit Linux,
Im Folgenden gut erkennbar …
L. schrieb:> Ziel-Platte komplett löschen mit Gparted
Wenn es überhaupt irgendetwas gibt wozu gparted NICHT geeignet und auch
nicht konzipiert ist, dann dies.
L. schrieb:> mit Fat32 formatieren,> um evtl. Datenreste zu überschreiben.
Ach du meine Güte, für so etwas gibt es geeignete Werkzeuge…
L. schrieb:> Darauf achten dass, Ziel-Platte etwas größer ist als Quell-Platte.
Knapp daneben ist auch vorbei. Wenn man zehn Million LBAs kopieren
möchte, dann braucht man Platz für zehn Million LBAs. Nicht ›etwas
mehr‹…
Ein T. schrieb:>> Das habe ich gemacht und das Ergebnis sieht so aus:>>>>> grub> ls>> (memdisk) (proc) (hd0) (hd0,gpt2) (hd0,gpt1)>> grub> _>>>> Okay, prima, sieht doch super aus. Dann benutzen wir wieder den Befehl> "ls", aber mit Parametern:> grub> ls (hd0,1)/>> und> grub> ls (hd0,2)/>> (Die beiden Befehle unterscheiden sich nur in der Partitionsnummer, den> / am Ende solltest Du IIRC auch weglassen können.)>> In einer der beiden Partitionen sollte das Verzeichnis "boot" liegen,> also entweder in (hd0,1) oder in (hd0,2). Das Verzeichnis "boot" zeigst> Du dann mit der betreffenden Partition an, also zum Beispiel> grub> ls (hd0,1)/boot>> oder> grub> ls (hd0,2)/boot>> In dem betreffenden Verzeichnis "boot" liegen dann ein Kernel und eine> Initrd
Hallo Ein T., wieder vielen Dank für die Hilfe!
Habe es gemacht und wenn ich 1. eingebe, kommt 2.:
1. grub> ls (hd0,1)/
2. efi/
grub> _
Wenn ich dann 1. eingebe, kommt 2.:
1. grub> ls (hd0,2)/
2. grub> _
Von boot oder vmlinuz leider nichts zu sehen.
Habe dann noch sicherheitshalber das eingegeben:
grub> ls (hd0,1)/boot
und
grub> ls (hd0,2)/boot
Dann kommt beides Mal:
error: file '/boot' not found.
Dirk schrieb:> Hallo Ein T., wieder vielen Dank für die Hilfe!
Sehr gerne, allerdings...
> error: file '/boot' not found.
... das sieht, wie ja auch Daniel vermutet, bedauerlicherweise so aus,
als hättest Du nicht das System, sondern womöglich nur die EFI System
Partition geklont. Jetzt wäre sicher ein guter Zeitpunkt, um tatsächlich
einmal die Super Grub2 Disk [1] zu versuchen, um das zu verifizieren.
Wenn Daniels und meine Vermutung zutrifft, dann bedeutet leider, daß Du
den Klonvorgang noch einmal wiederholen mußt. Dieses Mal würde ich Dir
allerdings empfehlen, ein anderes Werkzeug zu benutzen.
Der Klassiker unter Linux ist das Programm dd(1), allerdings mußt Du da
sehr genau aufpassen, daß Du die richtigen Festplatten (nicht
Partitionen, also /dev/sda statt /dev/sda1) als Quelle und Ziel
auswählst. Zudem würde ich im Falle von dd(1) empfehlen, die Größe der
kopierten Blocks mit dem Parameter "bs=10M" zu vergrößern, sonst kann
die Veranstaltung seeehr lange dauern. Achtung: dd(1) zeigt
normalerweise keinen Fortschritt an, was Anwender oft irritiert, der
Parameter "status=progress" ändert das und der Parameter "conv=noerror"
verhindert, daß das Programm bei Lesefehlern abbricht.
Sicherlich wird es auch geeignete Windows-Werkzeuge, aber von Windows
habe ich überhaupt keine Ahnung, sicherlich können da andere Teilnehmer
des Threads wie Daniel, Norbert oder Stefan Dir etwas passendes
empfehlen. Ich persönlich habe viel Positives über CloneZilla [2]
gehört, kenne es aber selbst nicht. [3] ist zwar für Windows, sollte
aber analog für Linux-Disks funktionieren.
Ansonsten könntest Du auch eine Neuinstallation erwägen, denn das ist
kein Hexenwerk. Die Paketkonfiguration kann mit dpkg (Parameter
--get-selections und --set-selections), und die Konfigurationsdateien
und Daten mit rsync(1) leicht von der alten auf die neue Disk gebracht
werden.
Viel Glück und Erfolg! :-)
[1] https://www.supergrubdisk.org/super-grub2-disk/
[2] https://clonezilla.org/downloads.php
[3]
https://www.thomas-krenn.com/de/wiki/Klonen_einer_Windows-Installation_mit_Clonezilla
Norbert schrieb:> L. schrieb:>> Wir arbeiten noch nicht lange mit Linux,>> Im Folgenden gut erkennbar …
Für Typen wie Sie suchen wir noch nach einem Knopf zum Blockieren auf
diesem Forum.
Ein T. schrieb:> Sicherlich wird es auch geeignete Windows-Werkzeuge, aber von Windows> habe ich überhaupt keine Ahnung, sicherlich können da andere Teilnehmer> des Threads wie Daniel, Norbert oder Stefan Dir etwas passendes> empfehlen.
Glücklicherweise bin ich seit mehreren Jahrzehnten in der vorteilhaften
Situation nichts, aber auch gar nichts, über Windows sagen zu können.
Aber bei Linux erzeugt zum Beispiel
1
lsblk -f -o+MODEL
eine gute Übersicht der Laufwerke und deren Hersteller sowie
Device-Namen.
Da kann man dann bei ›dd‹ die entsprechenden ›if=‹ und ›of=‹ Parameter
setzen, ohne Gefahr zu laufen das leere auf das volle Laufwerk zu
klonen. ;-)
Ich nehme zum klonen normalerweise ddrescue. Das bricht nicht gleich ab,
wenn es bei einer alten Disk mal einen Lesefehler gibt, und man sieht
auch, was nicht kopiert werden konnte, und kann die teile nochmal
versuchen zu kopieren.
Letztens hab ich mal meine Laptop SSD auf eine größere kopiert. Ich
dachte, das ist ja ne M.2 SSD die noch nie Probleme gemacht hat, also
hab ich mal das "pv" Programm zum Kopieren genommen. Natürlich gab es
dann gegen Ende einen Lesefehler... (Aber ich wusste, wie viel es schon
kopiert hatte, also hab ich dann halt selbst ein mapfile erstellt, und
konnte den Rest kopieren lassen).
L. schrieb:> Norbert schrieb:>> L. schrieb:>>> Wir arbeiten noch nicht lange mit Linux,>>>> Im Folgenden gut erkennbar …>> Für Typen wie Sie suchen wir noch nach einem Knopf zum Blockieren auf> diesem Forum.
Bitte entschuldige, aber... auch wenn ich mit ihm nicht immer einer
Meinung bin, so gehört Norbert zweifellos zu den kompetentesten und
hilfsbereitesten Linux-Fachleuten in diesem Forum, und in der Sache hat
er leider Recht.
Davon abgesehen möchte ich Dir wärmstens ans Herz legen, Dir für dieses
Forum und auch in der OpenSource-Community ein dickeres Fell zuzulegen.
Wir neigen zu ausgesprochen sachlicher, sehr direkter Kommunikation. Das
sieht dann zwar bisweilen unhöflich aus, ist aber einfach nur effizient.
M. D. schrieb:> Clonezilla ist quasi dd mit GUI drumrum.
Vielleicht, vielleicht auch nicht. Wikipedia meint
1
For unsupported file systems, Clonezilla falls back to
2
indiscriminate block-level copying.
Warum sollte ich mir das antun, wenn ich sowieso schon gegen
rätselhafte Fehler kämpfen muss? Wenn alles funktioniert, bietet
Clonezilla einen Haufen nette Funktionen, dagegen sage ich nichts.
Hallo, ich habe die Platte nun mit dd geklont und vorher alle
Partitionen auf der Zielplatte gelöscht.
Habe den Befehlssatz hier verwendet:
sudo dd if=/dev/sdb of=/dev/sda bs=64K status=progress conv=noerror,sync
Das Ergebnis ist ähnlich wie beim Klonen mit Minitool Shadowmaker.
Deshalb vermute ich, das das Problem irgendwo beim Quell-LW liegt.
Am liebsten möchte ich nun Ubuntu einfach auf der neuen HD (bisher =
Ziellaufwerk) neu installieren.
Normalerweise mache ich das, indem ich die Ubuntu-Install-ISO auf einen
Ventoy-Stick packe, von diesem boote und das Ubuntu sich dann
installieren lasse.
Leider kann man jetzt nicht (mehr) vom Ventoy-Stock booten, da das vom
Secure Boot verhindert wird. Secure Boot will ich dafür aber nicht
abschalten, weil, wenn ich das für die Installation mache, könnte es
sein, dass das W11 anschließend nicht mehr bootbar ist (das Problem
hatte ich schon mal und musste dann W11 neu installieren).
Die Ubuntu-Platte und die W11-Platte sehen sich übrigens nie, weil die
Energieversorgung für beide Platten über einen Wechselschalter 1xUM
(selbstverständlich nur im ausgeschalteten Zustand) betrieben wird, um
das jeweilige OS zu wählen. Es kann immer nur eine HD Strom bekommen.
Hat jemand eine weiterführende Idee dazu?
Dirk schrieb:> … und vorher alle> Partitionen auf der Zielplatte gelöscht.
Schadet nicht, bringt aber auch nichts, denn…
> Habe den Befehlssatz hier verwendet:> sudo dd if=/dev/sdb of=/dev/sda bs=64K status=progress conv=noerror,sync
…das überschreibt wirklich die komplette Platte inkl. Bootsektor,
Partition Table, Grub stage1 und 1.5. Eine absolut identische Kopie.
(Selbst die UUIDs müssten identisch sein)
Damit ist also nicht zu erklären, warum diese Platte im Austausch gegen
die alte nicht funktionieren soll. Unter der Voraussetzung, dass
wirklich ein Austausch (und nicht eine zusätzliche Platte) stattgefunden
hat. Ansonsten wären die UUIDs doppelt vergeben, was allgemein als
unangenehm empfunden wird.
Die (für mich) einzige Erklärung wäre, dass im BIOS irgendwo die (nicht
klonbare) PlattenID/Seriennummer geprüft wird und bei Änderung der
Bootvorgang verhindert wird. Das ist sehr weit hergeholt, aber in
Ermangelung einer besseren Idee…
Dirk schrieb:> Im Shadowmaker-Fenster war über die beiden Platten zu lesen:>> Source Disk: ... SCSI Disk Device> Destination Disk: ... ATA Bus>> Beide Platten werden logischerweise über ein SCSI-Kabel angeschlossen> (natürlich immer nur eine gleichzeitig).
Vornweg: Mit SCSI habe ich keine praktischen Erfahrungen.
Was mich stutzig macht:
1) Wie kann man eine Platte mit "ATA Bus" mittels SCSI-Kabel
anschließen?
2) Braucht es für (S)ATA nicht andere Treiber, als für SCSI?
Holger T. schrieb:> 2) Braucht es für (S)ATA nicht andere Treiber, als für SCSI?
Das stimmt. Hatte zwar seit Ewigkeiten kein SCSI mehr in den Händen,
aber damals waren es /dev/sgX Devices, WIMRE.
Ein T. schrieb:> L. schrieb:>> Norbert schrieb:>>> L. schrieb:>>>> Wir arbeiten noch nicht lange mit Linux,>>>>>> Im Folgenden gut erkennbar …>>>> Für Typen wie Sie suchen wir noch nach einem Knopf zum Blockieren auf>> diesem Forum.>
..........in der OpenSource-Community ein dickeres Fell zuzulegen.
Wir bilden uns unsere Meinung aufgrund von nachlesbaren Fakten und nicht
nach Art des Hauses und von irgendwelchen Kumpel-Netzwerken.
> Wir neigen zu ausgesprochen sachlicher, sehr direkter Kommunikation. Das> sieht dann zwar bisweilen unhöflich aus, ist aber einfach nur effizient.
Realitätsfremder geht's nicht mehr. Das Gegenteil ist der Fall.
Unsachlicher, abstoßender, emotional-aggressiver und Lösungs-fremder
gegen alles, was hier neu ist, geht es nicht mal in irgendeinem
äh..Laden auf der Reeperbahn zu.
Wir haben einfach nur eine simple sachliche Beschreibung unseres
Vorgehens geschildert, ohne jede Bewertung und Empfehlung.
Was darauf folgte, war eine vollkommen unsachliche sinnlose
Beschimpfung, die nach Art eines Oberlehrers, der offenbar die Wahrheit
gepachtet hat, jedes einzelne unserer Worte mit Hohn und Spott bedacht
hat. In unserem Verein erhielte diese Person sofortiges Hausverbot.
Wer sich in so einer Umgebung (offenbar schon jahrelang) wohl fühlt, der
hat auch nichts anderes verdient.
Dirk schrieb:> Habe den Befehlssatz hier verwendet:> sudo dd if=/dev/sdb of=/dev/sda bs=64K status=progress conv=noerror,sync>> Das Ergebnis ist ähnlich wie beim Klonen mit Minitool Shadowmaker.> Deshalb vermute ich, das das Problem irgendwo beim Quell-LW liegt.
Wenn das Quell-LW Bootet, kann das eigentlich nicht sein. (Wenn es
nicht mehr bootet, wurden eventuell Quelle und Ziel bei dd
vertauscht?)
Was auch sein könnte - diese Festplatte, ist die echt? Es gibt ja diese
Fälschungen, die 8TB angeschrieben haben und angezeigt wird, aber nur
1GB oder so drinn ist.
Norbert schrieb:> Holger T. schrieb:>> 2) Braucht es für (S)ATA nicht andere Treiber, als für SCSI?>> Das stimmt. Hatte zwar seit Ewigkeiten kein SCSI mehr in den Händen,> aber damals waren es /dev/sgX Devices, WIMRE.
Das hängt doch heute alles zusammen. SATA commands kännen über ATA
gesendet werden und umgekehrt usw.
https://unix.stackexchange.com/questions/144561/in-what-sense-does-sata-talk-scsi-how-much-is-shared-between-scsi-and-ata
Unter linux gibt es für die Festplatten, CD Laufwerke, etc. die ich
angeschlossen habe, auch je ein /dev/sg* Device. Das braucht man aber
nur, wenn man da direkt low level SCSI zu den Geräten senden will.
Der Kernel stellt eigentlich immer auch ein richtiges Blockdevice bereit
(/dev/fd* (floppy), /dev/sd* (SATA HDDs), /dev/cdrom & /dev/sr*
(CD/DVD/BluRay,etc.), /dev/mmcblk* (Per mmc angebundener Speicher (z.B.
SD Karten)), /dev/nvmeXnY (per NVME angebundener Speicher, oft M.2
SSDs)), etc. In der Regel nimmt man die, und kann den /dev/sg kram
ignorieren.
Holger T. schrieb:> 1) Wie kann man eine Platte mit "ATA Bus" mittels SCSI-Kabel> anschließen?> 2) Braucht es für (S)ATA nicht andere Treiber, als für SCSI?
Auf der Platte selber steht SATA 6.0
Warum weiter oben das Wort ATA auftaucht, verstehe ich auch nicht. Im
Bios wird das angeblich automatisch verwaltet.
Habe leider auch keine andere Platte zur Hand, sonst würde ich die mal
beim Klonen als Zielplatte verwenden.
Interessant wäre noch, wie man unter den gegebenen Umständen Ubuntu neu
installieren könnte.
Ein DVD-LW habe ich noch irgendwo, aber ob das klappt, wenn man schon
nicht vom Ventoy-Stick booten kann?
Oder eben Secure Boot ausschalten, mit dem wahrscheinlichen Ergebnis,
dass dann das meisterhaft programmierte W11 nicht mehr läuft.
Dirk schrieb:> Leider kann man jetzt nicht (mehr) vom Ventoy-Stock booten, da das vom> Secure Boot verhindert wird. Secure Boot will ich dafür aber nicht> abschalten, weil, wenn ich das für die Installation mache, könnte es> sein, dass das W11 anschließend nicht mehr bootbar ist (das Problem> hatte ich schon mal und musste dann W11 neu installieren).
Der Ubuntu Installer hat meines wissens einen Signierten Bootloader, den
müsste man eigentlich hauch mit Secure Boot starten können. Eventuell
muss das dann halt ohne Ventory machen. Ist aber nicht deren schuld, da
sieht man die Abhängigkleit, die Secure Boot zu MS geschaffen hat. (Ja,
die signieren den Bootloader von Ubuntu.).
Daniel A. schrieb:> Wenn das Quell-LW Bootet, kann das eigentlich nicht sein. (Wenn es> nicht mehr bootet, wurden eventuell Quelle und Ziel bei dd> vertauscht?)
Das ist definitiv nicht der Fall! Die Quellplatte funktioniert nach wie
vor.
> Was auch sein könnte - diese Festplatte, ist die echt? Es gibt ja diese> Fälschungen, die 8TB angeschrieben haben und angezeigt wird, aber nur> 1GB oder so drinn ist.
Davon gehe ich stakt aus, das ist eine etwas ältere, bisher nur für
Archivzwecke verwendete Platte (2.5" mechanische HDD). Die Quellplatte
ist auch mechanisch, aber 3.5".
Daniel A. schrieb:> Eventuell> muss das dann halt ohne Ventory machen.
Z.B. von DVD?
Kann man eventuell auch einen Installer auf der HD ablegen und den dann
starten?
Dirk schrieb:> Davon gehe ich stakt aus, das ist eine etwas ältere, bisher nur für> Archivzwecke verwendete Platte (2.5" mechanische HDD). Die Quellplatte> ist auch mechanisch, aber 3.5".
Dabn zeige doch mal bitte, was lsblk ausgibt, wenn nur die
Quellplatte dran ist und wenn beide Platten darn sind
L. schrieb:> Wir haben einfach nur eine simple sachliche Beschreibung unseres> Vorgehens geschildert, ohne jede Bewertung und Empfehlung.
Und die beinhaltete drei Dinge, welche allesamt falsch sind.
Die ersten beiden mal so richtig falsch, das dritte nur etwas falsch.
Und da diese Sachen hier nun einmal stehen bleiben und andere
Beginner/Einsteiger dies und etwaige Folgen nicht abschätzen/einschätzen
können, gab es den Kommentar.
Vor allem deshalb, da bei der Arbeit mit Datenträgern und vermutlich
wichtigen Daten keine Fehler passieren dürfen.
Der Kommentar mag dir vielleicht harsch vorgekommen sein, aber frag dich
mal ob er es tatsächlich war. Oder du nur einen Bremsklotz auf's Gleis
bekommen hast, dies nicht mochtest und dich angegriffen fühltest.
Dirk schrieb:> Daniel A. schrieb:>> Eventuell>> muss das dann halt ohne Ventory machen.>> Z.B. von DVD?>> Kann man eventuell auch einen Installer auf der HD ablegen und den dann> starten?
Probier mal als erstes, nur die ubuntu-iso-Datei auf einen USB-Stick
zu schreiben. Also kein Dateisystem und keine extra Installer oder
sonstwas. Z.B. mit "dd if=/pfad/zur/iso-datei of=/dev/sdx". Wenn die
iso-Datei nicht gerade uralt ist, sollte man direkt von dem Stick booten
können, das funktioniert mit Debian seit Jahren.
Dieter D. schrieb:> Beim Lenovo wurden noch diese Partitionen benötigt:
Dieter, die Platte wurde GEKLONT!
Das ergibt eine Bit-identische Kopie.
Was auf der einen ist, ist auch auf der anderen.
Norbert schrieb:> Dieter, die Platte wurde GEKLONT!
Trotzdem gab es den Fall, wo sich später im Thread doch fehlerhaftes
herausstellte.
Daher sollten von beiden Platten die Ausgaben von
fdisk -l
geprüft werden. Dessen Frage hat den gleichen Hintergrund:
Stephan S. schrieb:> zeige doch mal bitte, was lsblk ausgibt,
Dieter D. schrieb:> Trotzdem gab es den Fall, wo sich später im Thread doch fehlerhaftes> herausstellte.
Selbst wenn man sich bei Vollmond um Mitternacht auf den Friedhof stellt
und dreimal eine tote Katze über dem Kopf schwenkt, ›dd‹ liest bei LBA0
beginnend solange von der einen und schreibt auf die andere Platte, bis
ein Fehler passiert.
Da ›status=progress‹ den Fortschritt zeigt und der Kopiervorgang bis zum
Plattenende durchlief, ist es praktisch ausgeschlossen das schon gleich
zu Beginn bei LBA0 (Partitiontable) falsch gelesen/geschrieben wurde.
Nur eine Fehlbedienung könnte so etwas bewirken.
Da wir aber die Befehlszeile bekommen haben und diese korrekt war kann
eine Fehlbedienung ebenfalls ausgeschlossen werden.
Ein:
Norbert schrieb:> Ein:dd if=/dev/sdX count=1 bs=1M|md5sum> wird bei beiden Platten den gleichen Hash zeigen.
Nur, wenn sie exakt gleich gross sind, was recht unwahrscheinlich ist.
Da muss ich dir widersprechen: bei meinen 4 Lenovo-Laptops (2 private
und 2 geschäftliche) mit Ubuntu hat keiner eine Miicrosoft reserved oder
eine Lenovo Boot Partition gehabt. Das Geraffel braucht Linux nicht.
Das ist ein Lenovo X270, ein alter T430 sieht genauso aus, allerdings
nicht mit nvme, sondern sda
1
xc@lap03:~$ sudo fdisk-l
2
Disk /dev/nvme0n1: 119,24 GiB, 128035676160 bytes, 250069680 sectors
Disk identifier: 6D896350-7B05-4CEB-940B-5EB0769BBC45
9
10
Device Start End Sectors Size Type
11
/dev/nvme0n1p1 2048 2203647 2201600 1G EFI System
12
/dev/nvme0n1p2 2203648 27369471 25165824 12G Linux filesystem
13
/dev/nvme0n1p3 27369472 247396351 220026880 104,9G Linux filesystem
14
xc@lap03:~$ sudo lsblk
15
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
16
nvme0n1 259:0 0 119,2G 0 disk
17
├─nvme0n1p1 259:1 0 1G 0 part /boot/efi
18
├─nvme0n1p2 259:2 0 12G 0 part /
19
└─nvme0n1p3 259:3 0 104,9G 0 part /home
20
xc@lap03:~$
Dieter D. schrieb:> Dirk schrieb:>> Also, das Board hat UEFI Bios und Secure Boot ist aktiv.
Bei Linux empfiehlt es sich, Secure Boot abzuschalten, macht nur Ärger,
das will nur Redmont.
Daniel A. schrieb:> Norbert schrieb:>> Ein:dd if=/dev/sdX count=1 bs=1M|md5sum>> wird bei beiden Platten den gleichen Hash zeigen.>> Nur, wenn sie exakt gleich gross sind, was recht unwahrscheinlich ist.
Jetzt hast du es gesagt! Zwar ganz anders gemeint (wegen bs=1M), aber
was passiert, wenn das Ziel kleiner ist? Die Kopie der Partition Table
fehlt und die letzte Partition ist unvollständig. Aber für dd ist das
kein Fehler.
Daniel A. schrieb:> Sieht so aus, als ob dein linux nicht existiert. Die Partition scheint> leer zu sein.
Sein Clonewerkzeug hat vermutlich ein Problem mit ext4 und mit ext3 ging
es frueher.
L. schrieb:> [Unterstellungen, Übertreibungen, Mimosenhaftes]
Tut mir leid, ich wollte Eurer Majestät nur einen gut gemeinten Rat
geben. Verzeihen Sie bitte, das wird nicht wieder vorkommen.
Daniel A. schrieb:> Wenn das Quell-LW Bootet, kann das eigentlich nicht sein. (Wenn es> nicht mehr bootet, wurden eventuell Quelle und Ziel bei dd> vertauscht?)
Ja, langsam wird es müsteriös. Bin gespannt, ob und wie sich das
auflöst.
Norbert schrieb:> Selbst wenn man sich bei Vollmond um Mitternacht auf den Friedhof stellt> und dreimal eine tote Katze über dem Kopf schwenkt, ›dd‹ liest bei LBA0
Tut mir leid Dir jetzt ganz den Boden wegzuziehen, der TO verwendete
kein "dd" auf der Kommandozeile:
Dirk schrieb:> Der Klon wurde an einem Win-Rechner mit Minitool Shadowmaker erstellt
Dieter D. schrieb:> Norbert schrieb:>> Selbst wenn man sich bei Vollmond um Mitternacht auf den Friedhof stellt>> und dreimal eine tote Katze über dem Kopf schwenkt, ›dd‹ liest bei LBA0>> Tut mir leid Dir jetzt ganz den Boden wegzuziehen, der TO verwendete> kein "dd" auf der Kommandozeile:>> Dirk schrieb:>> Der Klon wurde an einem Win-Rechner mit Minitool Shadowmaker erstellt
Tut mir leid Dir jetzt ganz den Boden wegzuziehen, der TO verwendete
"dd" auf der Kommandozeile:
Dirk schrieb:> Habe den Befehlssatz hier verwendet:> sudo dd if=/dev/sdb of=/dev/sda bs=64K status=progress conv=noerror,sync
Wenn Du den Thread nicht liest, dann schreib' auch nichts.
Als Du noch hin und wieder ein bisschen Quatsch geschrieben hast, ach
G~tt. Aber daß Du mittlerweile andere hier mit Fehlinformationen
böswillig in die Irre führst, das finde ich wirklich mies von Dir.
Daniel A. schrieb:> Nur, wenn sie exakt gleich gross sind, was recht unwahrscheinlich ist.
Das sehe ich anders, Daniel.
Nach einem richtigen™ Klonvorgang müssen bei beiden Platten die
jeweils ersten MiB identisch sein. Es wird ja keine neue
Partitionstabelle mit evtl. unterschiedlichen Parametern angelegt,
sondern schlicht und einfach alles kopiert. Bit für Bit, Byte für Byte.
Bauform B. schrieb:> Jetzt hast du es gesagt! Zwar ganz anders gemeint (wegen bs=1M), aber> was passiert, wenn das Ziel kleiner ist? Die Kopie der Partition Table> fehlt und die letzte Partition ist unvollständig. Aber für dd ist das> kein Fehler.
Die fehlt nicht, das kann sie gar nicht, die ist ganz am Anfang. Wenn
die PT in LBA0 schon fehlen würde, dann wäre die Zielplatte gar nicht
existent.
Es scheinen sich ja mittlerweile eine Menge falscher Informationen
angesammelt zu haben.
Hier also mal nur ein Gedanke:
Was passiert wenn die Zielplatte größer ist?
Normalerweise nicht das geringste Problem, beim klonen wird ja nur der
Teil überschrieben welcher der Größe der Quellplatte entspricht. Das
steht – so hoffe ich doch – außer Zweifel.
Wenn aber die Dinger keine sogenannte gute alte ›MSDOS‹ Partitiontabelle
sondern eine GPT enthalten. Davon gibt es noch eine Kopie ganz am Ende
(welch natürlich auch geklont wird).
Nun haben wir ganz am Ende auf dem größeren? Ziellaufwerk vielleicht
noch als Überbleibsel eine alte GPT (weil die nicht überschrieben wurde)
und mit gewissem Abstand davor (aber ebenfalls Richtung Ende) die
neuere/gültige zweite GPT.
Wie verhielte sich ein solches System?
Es gibt mit dd aber noch eine Fehlerquelle, wenn die Festplatte kopiert
wird, die gerade benutzt wird. Swapfile statt Swappartition waere dabei
so ein Querschlaeger.
Norbert schrieb:> Nun haben wir ganz am Ende auf dem größeren?
Die Angabe zu den groessen fehlt auch vom TO.
Es gibt bei SSD auch noch den unhaeufigen Fallstrick, dass das Levelling
zur Lebensdauerverlaengerung in einem Fall mit Treiberunterstuetzung und
anderen Fall ohne laeuft.
Dieter D. schrieb:> Swapfile statt Swappartition waere dabei> so ein Querschlaeger.
Stimmt, das wäre tatsächlich wenig hilfreich.
Ein ›swapoff -a‹ wäre da vorher angebracht.
Aber auch ein drop in die Konsole,
killen aller unnötigen Prozesse,
sowie ein remount,ro aller Beteiligten.
Kopie erstellen, danach reboot.
Norbert schrieb:> Nach einem richtigen™ Klonvorgang müssen bei beiden Platten die> jeweils ersten MiB identisch sein.
Ja, ich habe das count=1 übersehen...
Ein T. schrieb:> Sicherlich wird es auch geeignete Windows-Werkzeuge, aber von Windows> habe ich überhaupt keine Ahnung, sicherlich können da andere Teilnehmer> des Threads wie Daniel, Norbert oder Stefan Dir etwas passendes> empfehlen.
Muss man hier so kleine Brötchen backen? Prinzipiell herrscht hier ein
Denkfehler vor: hier geht es nicht primär um Linux, und auch nicht
primär um Windows.
Es geht darum, beide Dualbootmäßig zu nutzen, und das braucht ein
Extra-Kapitel. Diesbezüglich gab es in der c't schon einige Artikel, wo
auch klar wurde, das Windows nicht sonderlich Grub-freundlich ist.
Vielleicht ist das "Klonen" in diesem Zusammenhang auch keine so gute
Idee. Ach ja, und Windows-Erfahrung?: War da nicht immer: entweder gar
nichts machen oder alles komplett neu die Devise?
Das dauert zwar eine Zeit, sein System von Grund auf neu aufzubauen -
aber wir haben es ja gelernt - und wissen, dass die Neuinstallation,
Listen und Original-Medien helfen, das OS wieder auf die Beine zu
stellen.
Bei Linux gibt es etwas andere Sorgen - aber lassen wir die einfach mal
weg.
Außerdem stört dieses Gockelhahnkamm-Aufstellen ebenfalls, hier bei der
Sache zu bleiben.
Rbx schrieb:> Es geht darum, beide Dualbootmäßig zu nutzen, und das braucht ein> Extra-Kapitel.
Bei zwei separaten Festplatten, welche wechselseitig durch einen
(physikalischen) Schalter aktiviert werden?
Das wird ein sehr kurzes Extra-Kapitel.
Rbx schrieb:> wo> auch klar wurde, das Windows nicht sonderlich Grub-freundlich ist.> Vielleicht ist das "Klonen" in diesem Zusammenhang auch keine so gute> Idee.
Ich zitiere mal die Überschrift:
Ubuntu-HD geklont, bootet aber nicht richtig
Dirk schrieb:> Ich versuche das Klonen einfach noch mal auf einem älteren Rechner ohne> SB mit Clonzilla und teile dann das Ergebnis mit.
Ich bin sehr gepannt, ob Clonezilla kann, was mit dd(1) nicht geklappt
hat. Viel Erfolg! :-)
Ein T. schrieb:> Ich bin sehr gepannt, ob Clonezilla kann, was mit dd(1) nicht geklappt> hat.
Clonezilla zeigt zumindest an, ob was faul ist und später zu Problemen
führen kann. Sowas wie "Ziellaufwerk ist zu klein" wird da direkt
unterbunden.
M. D. schrieb:> Ein T. schrieb:>> Ich bin sehr gepannt, ob Clonezilla kann, was mit dd(1) nicht geklappt>> hat.>> Clonezilla zeigt zumindest an, ob was faul ist und später zu Problemen> führen kann. Sowas wie "Ziellaufwerk ist zu klein" wird da direkt> unterbunden.
So etwas sollte man besser wissen noch bevor man überhaupt anfängt.
Vorab: es hat geklappt, juhuu :)
Also, habe die zu klonende Ubuntu-Platte und die Zielplatte an einen
etwas älteren Rechner gehangen, dessen Bios noch kein Secure Boot hat.
Habe Clonzilla.iso auf einen Ventoystick gepackt und das ganze dann vom
Stick gebootet.
Clonezilla habe ich einfach in den empfohlenen Einstellungen für
Anfänger genutzt, also immer auf ja geklickt.
Nach einem ziemlich zügigen Klonvorgang habe ich nach dem Runterfahren
die Zielplatte an den eigentlichen Rechner (den mit Secure Boot)
angeschlossen und zwar da, wo vorher das Quelllaufwerk angeschlossen
war.
Nach dem Einschalten hat alles einwandfrei funktioniert und gebootet.
Jetzt hoffe ich, dass auch W11 normal bootet, wenn die Bootplatte
umgeschaltet ist.
Wo jetzt der Fehler lag, keine Ahnung.
Beide Platten sind exakt gleich groß, die Quellplatte (mechanisch) 3,5",
die Zielplatte (mechanisch) und 2,5".
Gibt es noch irgendwas, was man nach dem Klonen bei Ubuntu machen
sollte? Irgendwelche Dateisysteme überprüfen oder so?
Erstens: Gratulation
Zweitens: Das alles ergibt absolut keinerlei Sinn. Egal wie lange und
intensiv man darüber nachdenkt.
Außer wenn im Rechner BIOS das Überschreiben des LBA0 verboten ist und
das dann tatsächlich auch irgendwie physikalisch unterbunden wird.
Stephan S. schrieb:> Das habe ich Dir schon vor 2 1/2 Tagen vorgeschlagen
Aber – falls es wie gerade beschrieben gemacht wurde – funktionierte das
nur an einem anderen PC.
Mich persönlich würde nun sehr interessieren, welcher originale PC
(Hersteller/Typ/BIOS-Version) solch ein bisher nie beobachtetes
Verhalten zeigt.
Norbert schrieb:> So etwas sollte man besser wissen noch bevor man überhaupt anfängt.
Das ist auch ein Punkt.
Das Vorgehen von Dirk ist allerdings nicht besonders systematisch und
analytisch. Vielleicht hat die Platte auch geheime Partitionen?
Der erste Punkt wäre schon mal, was für Platten das sind. Es sind schon
mal die Typen ATA, SATA und SCSI genannt worden.
Dirk schrieb:> Source Disk: ... SCSI Disk Device> Destination Disk: ... ATA Bus
Da stellt sich auch die Frage, wie groß die beiden Festplatten sind.
Von dem Befehl "fdisk -l" beider Platten wäre diese Zeile schon mal
sinnvoll ein paar Ursachen auszuschließen:
Disk /dev/xxxx: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Zum Beispiel bei einer alte kleine Festplatte funktionierte das auch
nicht ohne manuelles Nachhelfen.
Zum Schluss hatte ich auf den Rechner ein Linux ohne GUI auf die neue
große Festplatte im Expertenmodus installiert. Dabei hatte ich die
Festplatte manuell partitioniert. Eine weitere Partition von 2GB wurde
zusätzlich angelegt um ein Linux im Textmodus (ohne GUI) zu
installieren. Die anderen Partitionen wurden manuell kopiert. Das
Grub-Menü wurde erweitert um die anderen Betriebssysteme auf den anderen
Partitionen zu starten.
Dirk schrieb:> Vorab: es hat geklappt, juhuu :)
Gratulation. Dann geht es jetzt mit Linux weiter.
Dirk schrieb:> etwas älteren Rechner gehangen, dessen Bios noch kein Secure Boot hat.
Damit lag es an dem secure boot, was mehrere im Thread schon im Verdacht
hatten.
Dieter D. schrieb:> Damit lag es an dem secure boot, was mehrere im Thread schon im Verdacht> hatten.
Das halte ich für einen Trugschluss.
Welcher Wirkmechanismus (und vor allem wozu dienlich) soll denn
verhindern, dass ein vollständig gebootetes Betriebssystem keinen Zugang
zu seinen eigenen Festplatten haben soll und deshalb das Klonen
fehlschlägt?
Norbert schrieb:> Dieter D. schrieb:>> Damit lag es an dem secure boot, was mehrere im Thread schon im Verdacht>> hatten.>> Das halte ich für einen Trugschluss.
Ich auch... das ist alles sehr, sehr merkwürdig.
> Welcher Wirkmechanismus (und vor allem wozu dienlich) soll denn> verhindern, dass ein vollständig gebootetes Betriebssystem keinen Zugang> zu seinen eigenen Festplatten haben soll und deshalb das Klonen> fehlschlägt?
...zumal die ESP ja anscheinend kopiert worden ist, wenn ich die Angaben
in diesem Beitrag [1] richtig interpretiere.
[1] Beitrag "Re: Ubuntu-HD geklont, bootet aber nicht richtig"
Clone/Hard Disk Replacement: When using similar hard disks, the firmware
might hold keys for the old disk. Resetting BIOS to factory defaults can
sometimes clear these old references, allowing the new disk to initiate
the required key exchange, as suggested in Microsoft Q&A.
Dieter D. schrieb:> Clone/Hard Disk Replacement: When using similar hard disks, the firmware> might hold keys for the old disk. Resetting BIOS to factory defaults can> sometimes clear these old references, allowing the new disk to initiate> the required key exchange, as suggested in Microsoft Q&A.
Erklärt überhaupt nicht warum das Klonen auf einem anderen PC
funktionieren soll, auf diesem jedoch nicht.
Denn wenn es tatsächlich von irgendwelchen ›keys‹ abhängig wäre, dann
gäbe die neue Platte auch weiterhin keinen Mucks von sich.
Stephan S. schrieb:> Da muss ich dir widersprechen: bei meinen 4 Lenovo-Laptops (2 private> und 2 geschäftliche) mit Ubuntu hat keiner eine Miicrosoft reserved oder> eine Lenovo Boot Partition gehabt. Das Geraffel braucht Linux nicht.
Dafür aber oft eine Scheiß-Extra-Partitionen für die first stage von
grub2. Das ist auch kein bissel besser.
Ich verstehe nicht wirklich, was die Typen da gebastelt haben. Warum war
es nicht möglich, diesen Solms mit in die EFI-Partition zu packen? Da
tobt sich grub2 ja durchaus auch aus und legt einen Haufen Scheiß ab.
Ich hatte bisher keine Lust, mir das genauer anzuschauen, aber es kommt
mir auf jeden Fall ähnlich hilflos vor wie das MS-Gebastel.
Thread beobachten
Seitenaufteilung abschalten