Hallo @l8night
hier scheint etwas nicht zu stimmen
Aber ja, wie oben erwähnt
Ich vermute nämlich, daß / , /media und /media/rettung im RAM liegen und deshalb ein Platzproblem existiert.
Nach der Ausgabe von df zeigt sich allerdings : das Platzproblem ist nicht im RAM.
Hallo Lysa,
und sorry es sind deutlich mehr als 30 min weil :
1. ich anderes erledigen mußte
2. l8night und Werner P. Schulz (gottseidank) einiges von mir geschriebenes teils schon beantwortet haben
und ich damit nur Zeit vertat
---------------------------------------------------------------------------------------------------------
Du sagst :
Ich schreibe das deswegen so ausführlich, weil ich zur Zeit nicht schlau daraus werde, welche Partition welche und wo eingehängt ist:
Du hast auf :
/media/sdb1 einen Datenträger mit 236183884 kB-Blöcken, also 242 GB (Umrechnung mit 1024)
/media/sdb1 ist wohl die ehemalige 2. Partition Deiner alten Festplatte.
/media/sdc1 einen Datenträger mit 164665344 kiB-Blöcken, also 168 GB
/media/sdc2 einen Datenträger mit 323427024 kiB-Blöcken, also 331 GB
/mnt den gleichen Datenträger mit 323427024 kiB-Blöcken, also 331 GB
wobei /media/sdc2 und /mnt offensichtlich auf die selbe Partition zeigen
("etwa so wie man ein Haus über die Haustüre oder die Balkontüre betreten kann")
Irgend eine Aktion von Dir (ddrescue, Dateimanager oder anderes) hat wohl dazu geführt - dies ist wirklich kein Problem.
/dev/sdc ist offensichtlich die neue Festplatte mit 2 Partitionen /media/sdc1 und /media/sdc2
Also /dev/sdb... ist immer ein Datenträger und /dev/sdb1,/dev/sdb2 ... verschiedene "gemountete" Partitionen darauf
Genauso /dev/sdc
---------------------------------------------------------------------------------------------------------
Nun ein offensichtliches Problem :
auf /dev/sdc2 ist praktisch kein verfügbarer Platz (20 kiB) für kiB kannst Du auf wikipedia nachschauen.
Vielleicht ist dort (u.a.) die Ausgabe von dd_rescue. Da dort kein Platz mehr ist, kann es sein, daß dd_rescue wegen fehlenden Platzes fehlerhaft geendet hat. (Da kommt der von mir erwähnte Returncode s.u. ins Spiel)
Man hätte erwartet, daß dafür ca 242 GB nötig waren, aber jetzt sind 331 GB belegt.
Also nachschauen warum (was sind da für Dateien):
In Kommandozeile :
cd /media/sdc2; ls -lRa;
Ausgabe anschauen - wo wird der Platz verbraucht ?
Natürlich kann man das alles auch im Dateimanager machen, aber wenn Du dann (wie Werner P. Schulz schon erwähnt) Ausgabe hier posten willst ist das Kopieren der Ausgabe der Kommandozeile einfacher.
Mache nichts auf der alten Festplatte A, bevor Du nicht dd_rescue und die weiteren Schritte erfolgreich beendet hast. Mit erfolgreich meine ich z.B. - Du hast alle Filmdateien die Dir wichtig sind woanderst hin kopiert und konntest sie dort von Anfang bis Ende in einem Videoprogramm anschauen.
Zusammenfassend willst Du mit dd_rescue ca 242 GB irgendwohin retten (nach image.dat ca 242 GB groß) und dann mit "cp ..." den Inhalt von image.dat (die hoffentlich geretteten Filmdateien) woanderst hin kopieren, hast aber dazu nicht genug Platz, außer wenn Du mit cp nach /dev/sdb schreibst. Mache das bitte nicht unüberlegt ! Melde Dich besser vorher hier im Forum.
---------------------------------------------------------------------------------------------------------
Du sagst :
Was Du anschließend noch geschrieben hast, verstehe ich leider nicht - ich scheitere am Begriff "Returncode"
sorry.
Wenn Du (z.B.) in der Kommandozeile einen Befehl eintippst (wie df, mount, mkdir ....) so führt "das System" also hier ein Teil von Linux der sich "bash" nennt und "die Dienstleistung Kommandozeile regiert, verwaltet" den Befehl aus und gibt eine Antwort. Diese Antwort ist oft nur die Zeile knoppix@Microknoppix:
Diese Antwort bekommst Du natürlich erst, nachdem der Befehl fertig abgearbeitet wurde. Manchmal erscheinen vorher auch Fehlermeldungen - wie Du schon erfahren hast. Zusätzlich speichert der ausgeführte Befehl am Ende "irgendwo" eine Zahl also einen "Code" und gibt dann "die Regie" an das System zurück" (Return). Dieser Returncode, ist in einem Speicherplatz "irgendwo" gespeichert bis der nächste Befehl dort seinen Returncode speichert.
Üblicherweise sagt ein Returncode 0 : kein Fehler
Jeder Returncode ungleich 0 beschreibt normalerweise eine bestimmte Fehlersituation. Diesen Speicherplatz nennt man eine Variable. Variablen in "bash" sind Namen, Wörter welche mit einem $ beginnen. Direkt nach einem Befehl kann ich auf diese Variable zugreifen, indem ich sie ausschreibe. Ausschreiben unter "bash" geht z.B. mit dem Befehl "echo".
Nun nochmals kürzer in anderen Worten :
Wenn man in "bash" wissen will ob ein Befehl erfolgreich beendet wurde, so schreibt man ALS NÄCHSTEN BEFEHL die Variable $? mittels "echo" aus. Wenn sie 0 ist, ist alles ok. Wenn nicht - muß man suchen (z.B. in der Beschreibung) des Befehls) was der "Returncode" bedeutet.
Übrigens gibt es Returncodes auch woanderst (Windows ...)
Es gibt "natürlich auch" eine Beschreibung zu bash (nämlich "man bash" in der Kommandozeile) aber davor rate ich (für Beginner) dringend ab. Es gibt auch (auf Nachfrage) andere Literatur.
Beispiel :
mount -t xfs -o loop,ro /media/sdb1/image.dat /media/sdc6/backup/rettung; echo -e "$?";
Die Antwort (des Systems, also von bash) ist eine ganze Zahl (und natürlich die Zeile knoppix@Microknoppix:) .
Es gibt viele Situationen in denen es besser ist, mit echo nicht nur die Zahl auszuschreiben, sondern auch eine "Beschreibung" hinzuzufügen, welche mir sagt, was diese Zahl denn soll.
Beispiel :
mount -t xfs -o loop,ro /media/sdb1/image.dat /media/sdc6/backup/rettung;
echo -e "Returncode von mount /media/sdc6/backup/rettung : $?";
Du siehst, alles in den Hochkommatas ohne $ ist einfach von mir (oder Dir) frei gewählter Text.
---------------------------------------------------------------------------------------------------------
MfG
progi
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »progi« (12.06.2015, 15:42)