V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
In den Fehlermeldung wird eine mögliche Lösung vorgeschlagen: Try 'apt --fix-broken install' with no packages (or specify a solution). Hast Du das schon probiert? In Ubuntu musst Du dem Befehl ein sudo voranstellen: sudo apt --fix-broken install Übrigens solltest Du bei Zitaten von Fehlermeldungen im Terminal auch immer den eingegebenen Befehl mit kopieren, damit wir sehen können, was Du genau eingegeben hattest. Die defekte Platte sollte bis zum eigentlichen Rettungsversuch abgezogen sein, damit nicht doch zufällig irgendwelche Schreibzugriffe darauf erfolgen. ⚠️
|
paraplasma
Anmeldungsdatum: 7. August 2010
Beiträge: 341
Wohnort: Ruhrpott NRW
|
Falls der Vorschlag von V_for_Vortex nicht klappen sollte. Hast du noch dein Installationsmedium von 18.04? (USB-Stick oder DVD) Du könntest davon booten und dein Festplatten Image so erstellen.
|
miau
(Themenstarter)
Anmeldungsdatum: 7. Oktober 2006
Beiträge: 394
Wohnort: Nordrhein-Westfalen
|
Ja, dies waren die Eingaben: | sudo apt-get update
sudo apt --fix-broken install
sudo apt autoremove libdevmapper1.02.1:i386 libfuse2:i386 libllvm6.0:i386 libllvm7 libllvm7:i386 libllvm8 libllvm8:i386 libnvidia-common-390 libnvidia-common-430 libwayland-client0:i386 libwayland-server0:i386
sudo apt-get install coreutils
|
Hab die Platte soeben abgetrennt
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Laut Deiner Fehlermeldungen sind die Pakete libnvidia-ifr1-435, libnvidia-ifr1-435:i386 und nvidia-driver-435 das Problem. Probier mal folgendes: sudo dpkg --dry-run -r libnvidia-ifr1-435 libnvidia-ifr1-435:i386 nvidia-driver-435 Und gib uns die Ausgabe des Befehls. Die Option --dry-run sorgt dafür, dass der Befehl nur simuliert wird und nicht wirklich etwas tut, um den Quatsch nicht quätscher zu machen.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8625
Wohnort: Münster
|
miau schrieb: […] Hab die Platte soeben abgetrennt
Gut. Belasse das vorläufig so. Wichtig ist in Deiner Situation, die Nerven zu beruhigen und planvoll zu handeln! Dein Plan könnte so aussehen: Du benötigst neue Platten. Kaufe oder bestelle welche. Du benötigst ein Live-Medium auf USB oder DVD, mit dem Du den Rechner starten kannst. Sobald Du eine frische USB-Platte in Händen hast, bringe erst einmal das auf der internen Platte installierte System in Ordnung: Lege auf der neuen USB-Platte eine oder mehrere Partitionen an und formatiere eine davon mit dem Dateisystem ext4. Schaffe auf der internen Platte wieder Platz, indem Du Dateien auf die neue USB-Platte kopierst und dann auf der internen Platte löschst. Repariere das System auf der internen Platte. Solange Du hier Fehler hast, sind das gute Voraussetzungen, um beim Kopieren von den beiden alten, sterbenden Platten Dateien zu verlieren.
Wenn das interne System wieder fit ist, schließe eine der alten Platten und eine neue USB-Platte an. Kopiere die Datenbestände auf die neue Platte. Mache Dir vorher klar, das es nur diesen Weg gibt und dieser Weg aber zum Datenverlust führen kann. Wenn Du kein Glück haben solltest, hast Du hoffentlich Likör … Du kannst die Kopieraktion in einem beauftragen oder auch in mehreren Etappe durchführen (das würde ich machen) und zwischen den Etappen der alten Platte etwas Ruhe gönnen. Ob das hilft, weiß man nicht, aber schaden kann das eigentlich nicht. Wenn Du dagegen das interne System nicht mehr fit bekommst, arbeite mit dem Live-System weiter (inkl. vorstehendem Punkt!). Wiederhole das mit der zweiten Platte. Wenn es wegen der Datenmenge lange Zeit dauert, dann dauert es eben lange. Ertrage das oder gib auf. Überlege Dir ein vernünftiges Backup-Konzept, um die gegenwärtige Misere für die Zukunft auszuschließen. Dafür benötigst Du noch mehr Platten.
|
miau
(Themenstarter)
Anmeldungsdatum: 7. Oktober 2006
Beiträge: 394
Wohnort: Nordrhein-Westfalen
|
paraplasma schrieb: Falls der Vorschlag von V_for_Vortex nicht klappen sollte. Hast du noch dein Installationsmedium von 18.04? (USB-Stick oder DVD) Du könntest davon booten und dein Festplatten Image so erstellen.
Ich guck mal; also doch nicht klonen sondern Image? Das ist am schnellsten, steht dort.. Den Pfad dann wie beim Klonen, nur mit .img am Ende? Beim Beispiel Klonen ist der Pfad zum anderen Medium angegeben.. und das Img soll ja nicht im Heimverzeichnis abgelegt werden.
|
miau
(Themenstarter)
Anmeldungsdatum: 7. Oktober 2006
Beiträge: 394
Wohnort: Nordrhein-Westfalen
|
kB schrieb: Du benötigst ein Live-Medium auf USB oder DVD, mit dem Du den Rechner starten kannst.
Ich glaub alles aus dem Live-Modus ist einfacher. Ist dd/coreutils in höheren Ubuntu-Versionen eigentlich besser/stabiler/schneller?
Du kannst die Kopieraktion in einem beauftragen oder auch in mehreren Etappe durchführen (das würde ich machen) und zwischen den Etappen der alten Platte etwas Ruhe gönnen. Ob das hilft, weiß man nicht, aber schaden kann das eigentlich nicht.
Was meint Etappen als command?
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
miau schrieb: Ist dd/coreutils in höheren Ubuntu-Versionen eigentlich besser/stabiler/schneller?
dd ist wie die meisten Programme der coreutils sehr alt uns seit langem bewährt. Viel wird sich dort nicht mehr tun. Ich habe trotzdem spaßhalber mal nachgeschaut: Laut des Changelogs der coreutils wurde dd nur dreimal seit 2017 verändert, und das nur in für den Alltagsbetrieb unwichtigen Details. Wenn Du Englisch kannst, schau es Dir selbst unter https://fossies.org/linux/coreutils/ChangeLog an und durchsuche die Seite nach dd: (also mit dem Doppelpunkt).
|
miau
(Themenstarter)
Anmeldungsdatum: 7. Oktober 2006
Beiträge: 394
Wohnort: Nordrhein-Westfalen
|
Jetzt hab ich den Release Candidate schon gebrannt und gestartet — Ubuntu 20.04 Die (womöglich) defekte Festplatte hat automatisch nur Lesezugriff; der neuen Festplatte habe ich gerade Schreibzugriff erteilt. Allerdings klappt das mit dem Image anfertigen nicht. | ubuntu@ubuntu:~$ sudo dd if=/dev/sda1 of=/dev/sdc2/image_sda1.img
dd: konnte '/dev/sdc2/image_sda1.img' nicht öffnen: Ist kein Verzeichnis
|
Oder muss ich da den media-Pfad angeben? Im Wiki steht ja stets der device-Pfad
|
miau
(Themenstarter)
Anmeldungsdatum: 7. Oktober 2006
Beiträge: 394
Wohnort: Nordrhein-Westfalen
|
Hab jetzt mal nur sudo dd if=/dev/sda1 of=/dev/sdc2 eingegeben und die Konsole macht anscheinend grad irgendwas, in der Zeile darunter blinkt es Ist das der Klonvorgang? Wenn ich derweil auf die Festplatte klicke steht »Die Struktur muss bereinigt werden«
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
miau schrieb: Hab jetzt mal nur sudo dd if=/dev/sda1 of=/dev/sdc2 eingegeben und die Konsole macht anscheinend grad irgendwas, in der Zeile darunter blinkt es
Ohne weitere Optionen gibt dd nur eventuelle Fehler und am Ende eine Übertragungsstatistik aus. Wenn Du eine laufende Fortschrittsanzeige willst, musst Du die Option status=progress verwenden.
|
miau
(Themenstarter)
Anmeldungsdatum: 7. Oktober 2006
Beiträge: 394
Wohnort: Nordrhein-Westfalen
|
Aber der ‘Klonungsvorgang’ geht schon vonstatten, ja? Ich habe rausgefunden dass sudo kill -SIGUSR1 den aktuellen Fortschritt angibt Eben merke ich dass der Vorgang sogar beendet wurde, aber ich weiß nicht ob mit gutem Ergebnis. Ich hab nun zwei Datenträger, einer mit USB-Logo. Ist das der Klon? Es ist eine Menge.. aber nicht alles vorhanden. 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34 | ubuntu@ubuntu:~$ sudo dd if=/dev/sda1 of=/dev/sdc2
71362985+0 Datensätze ein
71362985+0 Datensätze aus
36537848320 Bytes (37 GB, 34 GiB) kopiert, 1587,6 s, 23,0 MB/s
72976228+0 Datensätze ein
72976228+0 Datensätze aus
37363828736 Bytes (37 GB, 35 GiB) kopiert, 1621,12 s, 23,0 MB/s
77437649+0 Datensätze ein
77437649+0 Datensätze aus
39648076288 Bytes (40 GB, 37 GiB) kopiert, 1716,73 s, 23,1 MB/s
91448257+0 Datensätze ein
91448257+0 Datensätze aus
46821507584 Bytes (47 GB, 44 GiB) kopiert, 2022,04 s, 23,2 MB/s
122850545+0 Datensätze ein
122850545+0 Datensätze aus
62899479040 Bytes (63 GB, 59 GiB) kopiert, 2699,6 s, 23,3 MB/s
171715849+0 Datensätze ein
171715849+0 Datensätze aus
87918514688 Bytes (88 GB, 82 GiB) kopiert, 3766,01 s, 23,3 MB/s
210385417+0 Datensätze ein
210385417+0 Datensätze aus
107717333504 Bytes (108 GB, 100 GiB) kopiert, 4608,23 s, 23,4 MB/s
265055713+0 Datensätze ein
265055713+0 Datensätze aus
135708525056 Bytes (136 GB, 126 GiB) kopiert, 5790,65 s, 23,4 MB/s
417771161+0 Datensätze ein
417771161+0 Datensätze aus
213898834432 Bytes (214 GB, 199 GiB) kopiert, 9112,95 s, 23,5 MB/s
dd: Fehler beim Lesen von '/dev/sda1': Eingabe-/Ausgabefehler
486823880+0 Datensätze ein
486823880+0 Datensätze aus
249253826560 Bytes (249 GB, 232 GiB) kopiert, 10619,2 s, 23,5 MB/s
|
|
miau
(Themenstarter)
Anmeldungsdatum: 7. Oktober 2006
Beiträge: 394
Wohnort: Nordrhein-Westfalen
|
Ein Datenträger schreibt 38.725 Objekte der Gesamtgröße 343,0 GB, der andere 39.120 Objekte der Gesamtgröße 343,4 GB. Und tatsächlich scheinen genau die 400 MB aus dem anderen Ordner zu fehlen, die ich vorhin von der anderen Platte rüberkopiert hatte. Aber warum wurde dieser zweite Ordner ausgelassen? Und schlimmer: warum auch die (tatsächlich?) verlorenen Inhalte. Und müssten nicht etliche Dateien zu sehen sein die ich irgendwann mal gelöscht hatte? Kann natürlich auch sein dass die Festplatte so gut formatiert wurde dass nichts mehr übrig ist — ist wie gesagt Jahre her dass ich darauf Schreibzugriff nahm. Oder hätte die img-Variante ein üppigeres Ergebnis erbracht? Warum hatte mein command nicht funktioniert? Und was wäre wenn ich das selbe (oder ein bisschen anders) erneut machen würde, würden die Dateien dann überschrieben? Oder übersprungen? Übrigens schreiben beide dass 351,5 GB benutzt und 115,6 GB frei sind. In GParted ist als sdc1 die Microsoft reserved partition, Dateisystem unbekannt, Größe 128.00 MiB, benutzt und unbenutzt Strich, Markierungen msftres; sdc2 Basic data partition, ext4, Einhängepunkt ...1 (Zahl angehängt), Größe 3.64 TiB, benutzt 334.81 GiB, unbenutzt 130.95 GiB, Markierungen msftdata
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
Um nochmal auf eine frühere Frage zurückzukommen: Ja, wenn du mit dd eine Image-Datei eines Laufwerks anlegen willst, musst du das Ziellaufwerk/-dateisystem, wo die Imagedatei abgelegt werden soll, einhängen und den Pfad dorthin eingeben. Dein dd-Befehl hat dementgegen versucht, die vollständigen Partitionsinhalte der ersten Partition von sda in die zweite Partition von sdc zu übertragen. Das "versucht" steht dort, weil dd so lange Daten von Quelle zu Ziel bewegt, bis entweder die Quelle keine Eingabe mehr liefert oder das Ziel keine Daten mehr unterbringen kann. Ich gehe davon aus, dass sdc2 größer ist als sda1, weil dd dem Anschein nach nicht mit der Meldung abgebrochen hat, dass sdc2 vollgelaufen ist. Ein Resultat dieses Transfers ist, dass das Dateisystem mitsamt seinen Metadaten auch noch unangetastet ist. Wenn es vorher eine 100GB-Partition ausgefüllt hat und nun eine 200GB-Partition ausfüllt, wird es sich nach wie vor verhalten, als wäre es nur 100GB groß. Hättest du die 100GB in eine 10GB-Partition geschoben, sähe das Dateisystem sich vermutlich auch noch als 100GB groß, wobei du ziemlich schnell merken würdest, dass etwas nicht stimmt. Letztendlich ist eine Partitionsdefinition ein Datensatz an der einen Stelle eines Gesamtsystems und ein Dateisystem auf einer Partition eine etwas komplexere Datenstruktur an einer ganz anderen Stelle. Du könntest (bitte erst ganz zum Schluss, wenn du die Daten mindestens einmal ordentlich gesichert hast) die Partitionsgröße korrigieren, wenn du das magst. Und danach das Dateisystem entsprechend vergrößern. Wichtig: Erst nach Abschluss der Datenrettung und einer ordentlichen Sicherung! Mit Blick auf den Zustand der Datenquelle gibt es keinen Unterschied zwischen Klon und Image. Sprich: Was im Klon fehlt, würde auch im Image fehlen, und umgekehrt. Das Image hat den Vorteil, dass du weißt, wo der Datenträger anfängt und wo er endet und welche genauen Informationen er enthält. Wenn du von einem Datenträger auf einen größeren Datenträger klonst, dann musst du effektiv bei allen Low Level-Operationen genau wissen, wie viele Blöcke denn nun zum Klon gehören, weil sonst ggf. früher auf dem größeren Datenträger gespeicherte Inhalte, die nicht beim Klonen überschrieben wurden, ausgewertet werden. Das könnte passieren, wenn du bestimmte Analyseprogramme auf die bereits zuvor angesprochene 200GB-Partition ansetzt, in der aber nur 100GB das zu bearbeitende Dateisystem darstellen. Wenn du genau denselben Befehl nochmal ausführst, würden einfach die jetzt auf sdc2 liegenden Inhalte wieder mit denen von sda1 überschrieben. Bei einer heilen Festplatte mit einem heilen Dateisystem ist meine Erwartung, dass beide Aufrufe dasselbe Ergebnis haben. Mit deiner kaputten Festplatte, die mit jeder Nutzung immer dichter am Totalausfall steht, könnte ich mir vorstellen, dass es nicht mehr nur einen E/A-Fehler gibt (siehe deinen Ausgabeblock von dd), sondern irgendwann mehrere. Jeder E/A-Fehler steht für verlorene Daten. Findet er innerhalb einer regulären Datei statt, ist der Inhalt kaputt - nicht schön, aber nicht auch nicht unbedingt kritisch. Allerdings können hier auch Dateisystemmetadaten betroffen sein und damit plötzlich der Zugang zu ganzen Teilen des Dateisystems verwehrt werden. Hier kommen dann die bereits genannten Werkzeuge wie testdisk zum Tragen, die den Datenträger unterhalb der Ebene des Dateisystems durchgraben und herauszufinden versuchen, welche Blöcke zu einer Datei gehören und welche zu einer anderen. Das dauert ewig, die Ordnerstrukturen gehen unter Umständen verloren und am Ende hast du vermutlich immernoch einen Datenverlust, der mangels Datensicherung einfach akzeptiert werden muss. ☹ Früher mal gelöschte Daten würdest du z.B. nach einer Bearbeitung mit den Recovery-Tools wiedersehen. Ein dd-Befehl gefolgt vom Mounten der Zielpartition zeigt das Dateisystem, wie es an der Quelle aussieht. Und an der Quelle siehst du ja ohne Anwendung entsprechender Tools auch keine bereits gelöschten Dateien.
|
miau
(Themenstarter)
Anmeldungsdatum: 7. Oktober 2006
Beiträge: 394
Wohnort: Nordrhein-Westfalen
|
Das ist schön geschrieben, aber ich verstehe es leider nicht ganz, und schon gar nicht was nun zu tun ist. Ich weiß nicht ob diese Festplatte kaputt ist. Vielleicht nur die andere, vielleicht (auch) die Docking-Station. Daher halte ich einen weiteren Vorgang (mit dd oder anderem) für vertretbar. Aber weshalb wurde nur ein Ordner geklont und der zweite ausgelassen, während ich im command keine Angaben zu spezifischen Inhalten machte? Und wie genau gehe ich jetzt vor um insbesondere die nirgends sichtbaren Dateien wiederherzustellen, also die Gigabytes im zweiten Ordner. dd hatte einfach einen leeren Ordner hingepackt. Und was muss ich tun um bei der anderen Festplatte – bei der man sich keine wiederholten Kopiervorgänge leisten kann – alles zu übertragen?
|