|
Anzeige
|
Ubuntu-HD geklont, bootet aber nicht richtigHallo, 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:
Kann jemand etwas damit anfangen und sagen, wie man nun am besten vorgeht, wenn ich das so naiv fragen darf? Hast Du die ganze Platte, z.B. /dev/sda geklont oder nur die Partitionen, z.B. /dev/sda1, /dev/sda2. Womit hats Du geklont? Ist uns auch passiert ! Kommt auf Wissen/Ausrüstung bei Euch an, welche Lösung infrage kommt. Ist es eine Sata-SSD Platte oder eine mechanische ? :
Bearbeitet durch User
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 ?
Und Du glaubst, dass jemand der wie der TE fragt, mit chroot zurechtkommt?
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. :
Bearbeitet durch User
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. 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.
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.
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). 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. :
Bearbeitet durch User
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!
Nicht wichtig, bin nur neugierig: warum?
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? Ich nehme mal an, die unbekannte Software welche zum "klonen" verwendet wurde, hat die UUID der Partitionen geändert. Als Alternative über ein Image gehen? -braucht natürlich ein zusätzliches Laufwerk, aber dann hat man gleich was lauffähiges als Backup liegen. Hallo, Danke für die Antworten! @Ein T. (ein_typ): Vielen Dank für die ausführliche Antwort und das freundliche Angebot! :)
Das schaue ich heute Abend als erstes und melde mich dann wieder.
Meinst du mit unbekannter Software das von mir verwendete "Minitool Shadowmaker Free 3.1"?
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.
Wie findet man das raus?
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.
Das habe ich gemacht und das Ergebnis sieht so aus:
Die Befehle "mount" und "lsblk" bringen jeweils den Error "can't find command" So viel erst mal dazu.
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). 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.
Okay, prima, sieht doch super aus. Dann benutzen wir wieder den Befehl "ls", aber mit Parametern:
und
(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
oder
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:
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! :-)
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.
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?
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"
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)
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. :-)
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. :
Bearbeitet durch User
Es sprach der grosse Linux-Experte. Wenn der jemals mit der SGD gearbeitet hätte, wüsste er mehr.
Ehrlich gesagt, mir stehen bei diesem Satz die Haare zu Berge. Wenn du Pech hast, ist das Laufwerk beschädigt.
Möglich. Das wissen wir aber nicht wirklich sicher.
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.
Möglich. Das wissen wir aber nicht wirklich sicher.
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.
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.
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. :
Bearbeitet durch User
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 ...
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 ... ;-)
Nur das Filesystem, nicht das Laufwerk ...
Was verstehst du an "in unserem Fall" nicht?
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.
Der verhält sich gar nicht, weil er nicht auf der geklonten Platte ist. :-P
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.
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 !
Im Folgenden gut erkennbar …
Wenn es überhaupt irgendetwas gibt wozu gparted NICHT geeignet und auch nicht konzipiert ist, dann dies.
Ach du meine Güte, für so etwas gibt es geeignete Werkzeuge…
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‹…
Hallo Ein T., wieder vielen Dank für die Hilfe! Habe es gemacht und wenn ich 1. eingebe, kommt 2.:
Wenn ich dann 1. eingebe, kommt 2.:
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. Sieht so aus, als ob dein linux nicht existiert. Die Partition scheint leer zu sein.
Sehr gerne, allerdings...
... 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
Für Typen wie Sie suchen wir noch nach einem Knopf zum Blockieren auf diesem Forum.
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
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. ;-)
Wenn es auch noch einen gäbe um inhaltlich völlig falsche Posts zu blocken… :
Bearbeitet durch User
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).
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. Clonezilla ist quasi dd mit GUI drumrum. Ich kanns nur empfehlen.
Vielleicht, vielleicht auch nicht. Wikipedia meint
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?
Schadet nicht, bringt aber auch nichts, denn…
…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… :
Bearbeitet durch User
Vornweg: Mit SCSI habe ich keine praktischen Erfahrungen. Was mich stutzig macht:
Das stimmt. Hatte zwar seit Ewigkeiten kein SCSI mehr in den Händen, aber damals waren es /dev/sgX Devices, WIMRE.
..........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.
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.
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.
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.
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.
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.).
Das ist definitiv nicht der Fall! Die Quellplatte funktioniert nach wie vor.
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".
Z.B. von DVD? Kann man eventuell auch einen Installer auf der HD ablegen und den dann starten?
Dabn zeige doch mal bitte, was lsblk ausgibt, wenn nur die Quellplatte dran ist und wenn beide Platten darn sind
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.
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. Beim Lenovo wurden noch diese Partitionen benötigt:
Womit man sich noch auseinandersetzen müßte: https://wiki.ubuntuusers.de/efibootmgr/ Und in Ruhe die Ausgabe studieren: efibootmgr --verbose
Dieter, die Platte wurde GEKLONT! Das ergibt eine Bit-identische Kopie. Was auf der einen ist, ist auch auf der anderen.
Trotzdem gab es den Fall, wo sich später im Thread doch fehlerhaftes herausstellte. Daher sollten von beiden Platten die Ausgaben von geprüft werden. Dessen Frage hat den gleichen Hintergrund:
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:
wird bei beiden Platten den gleichen Hash zeigen. :
Bearbeitet durch User
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
Bei Linux empfiehlt es sich, Secure Boot abzuschalten, macht nur Ärger, das will nur Redmont.
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.
Sein Clonewerkzeug hat vermutlich ein Problem mit ext4 und mit ext3 ging es frueher.
Tut mir leid, ich wollte Eurer Majestät nur einen gut gemeinten Rat geben. Verzeihen Sie bitte, das wird nicht wieder vorkommen.
Ja, langsam wird es müsteriös. Bin gespannt, ob und wie sich das auflöst.
Tut mir leid Dir jetzt ganz den Boden wegzuziehen, der TO verwendete kein "dd" auf der Kommandozeile:
Tut mir leid Dir jetzt ganz den Boden wegzuziehen, der TO verwendete "dd" auf der Kommandozeile:
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.
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.
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?
Aber erst beim zweiten Versuch. 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.
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.
So, gerade mal versucht, wird zuverlässig erkannt, scheint kein Problem zu sein:
Man kann übrigens schön sehen, das Quell- und Zielpartition identisch sind (UUID und Größe) :
Bearbeitet durch User
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. :
Bearbeitet durch User
Ja, ich habe das count=1 übersehen...
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.
Bei zwei separaten Festplatten, welche wechselseitig durch einen (physikalischen) Schalter aktiviert werden? Das wird ein sehr kurzes Extra-Kapitel.
Ich zitiere mal die Überschrift: Ubuntu-HD geklont, bootet aber nicht richtig :
Bearbeitet durch User
Hast Du denn jetzt Erfolg gehabt? Falls nein, warum hast Du dann nicht mal Clonezilla versucht? 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! :-)
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.
Oder noch bequemer:
:
Bearbeitet durch User
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?
Das habe ich Dir schon vor 2 1/2 Tagen vorgeschlagen Beitrag "Re: Ubuntu-HD geklont, bootet aber nicht richtig" 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.
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. :
Bearbeitet durch User
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.
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.
Gratulation. Dann geht es jetzt mit Linux weiter.
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?
Ich auch... das ist alles sehr, sehr merkwürdig.
...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.
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.
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. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
