• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst] Filesystem am Bobbes

A

Anonymous

Gast
Systemcrasher schrieb:
Funzt!

Kann alle Verzeichnisse ansehen (hab das mal testweise mit ein paar probiert), ebenso konnte ich die erst beste Datei laden (Textdokument).

na prima, dann ist ja gut, dann kopier die wichtigen Dateien raus was du noch brauchst und wovon du sonst kein Backup hast, und dann mal

Code:
dumpe2fs  /dev/loop0 | tail -8
absetzen und die letzten Zeilen anschauen, insbesondere die mit "Frei Blöcke". Die letzten 168 Blocks das Image Dateisystems haben wir mit NULL aufgefüllt. Nachschauen ob dort viele sind die nicht als "Freie Blöcke" markiert sind, betroffener Bereich 3977815 - 3977983 den wir mit Nullen aufgefüllt haben, wenn dort Datenblöcke von Dateien waren, dann sind diese Dateien jetzt leer oder beschädigt? welche Dateien das sind könnte man zwar auch noch rausbekommen, kann nicht so schrecklich viel sein, und irgendwo müssen wir hier auch mal Schluss machen, über ein Forum gehen solche mehr oder weniger komplizierte Dinge nicht immer sehr effektiv, insbesondere wenn es lange Listings werden, oder es viele komplizierte individuelle interaktive Einzelaktionen werden würden, wie zB in die Tiefen eines solchen Dateisystems einzutauchen. ;)

Wenn du die wichtigsten Sachen rauskopiert hast, dann mal umounten und ein
Code:
fsck -f -y /dev/loop0
drüber laufen lassen. Er wird wohl noch einige reparieren wollen.
Danach kannst du es wieder mounten und dir die Dateien dann mit tar oder rsync wieder in ein neu angelegtes Dateisystem kopieren.

und schau mal nach was bei dir mit der sdb Platte los ist, ist das eine angestöpselte USB ? dort waren Schreib/Lese Fehler in der dmesg zu sehen. ;)

robi
 
OP
Systemcrasher

Systemcrasher

Hacker
robi schrieb:
Systemcrasher schrieb:
und schau mal nach was bei dir mit der sdb Platte los ist, ist das eine angestöpselte USB ? dort waren Schreib/Lese Fehler in der dmesg zu sehen. ;)

robi


Im Moment ist er am Dateien umschaufeln (lt. MC dauert es schon 2 h und noch 7 h, liegt wohl an der USB-Platte).

Zu Deiner Frage: Das könnte daran liegen, daß die Linuxpartition (auch die /) ziemlich voll war, weshalb ich die Partitionen auch vergrößern wollte. Jedenfalls brach das zypper-Update nach dem Download während der Installation der Pakete ab, wegen zu wenig Platz (mehr als 4 GB download beim Update :( ).
Danach hatte ich Probleme, die USB vom betroffenen Rechner aus zu mounten. Ich konnte zwar manchmal mounten, dann aber höchstens 1 mal auf eine Datei zugreifen. Das dürfte die Schreib/Lesefehler erklären.

Von den knapp 16 GB der beschädigten Partition will MC gerade mal gut 12 GB umkopieren. Das dürfte auch in etwa mit dem tatsächlichen Datenbestand übereinstimmen (ich kopiere sicherheitsbedingt und der Einfachheit halber das gesamte /home aus dem Image). Der Rest (die zerschossenden "Dateien") war wohl schon z.T. das per GParted zu verlängernde "Schwanzende" der Partition.

Noch mal Glück gehabt. :eek:ps:
 
OP
Systemcrasher

Systemcrasher

Hacker
Son nun den Rest durchgeführt:

Code:
 dumpe2fs  /dev/loop0 | tail -8
dumpe2fs 1.42.6 (21-Sep-2012)
  Freie Inodes: 979201-987360
Gruppe 121: (Blöcke 3964928-3977983) [INODE_UNINIT, ITABLE_ZEROED]
 Prüfsumme 0x2ff6, ungenutzte Inodes 8160
  Block bitmap in 3670025 (bg #112 + 9), Inode Bitmap in 3670041 (bg #112 + 25)
  Inode-Tabelle in 3674638-3675147 (bg #112 + 4622)
  1103 freie Blöcke, 8160 freie Inodes, 0 Verzeichnisse, 8160 ungenutzte Inodes
  Freie Blöcke: 3971582-3971583, 3971647-3971671, 3971798-3971999, 3972268-3973119, 3977710-3977727, 3977980-3977983
  Freie Inodes: 987361-995520


Code:
  fsck -f -y /dev/loop0
fsck von util-linux 2.21.2
e2fsck 1.42.6 (21-Sep-2012)
Durchgang 1: Prüfe Inodes, Blocks, und Größen
Durchgang 2: Prüfe Verzeichnis Struktur
Durchgang 3: Prüfe Verzeichnis Verknüpfungen
Durchgang 4: Überprüfe die Referenzzähler
Durchgang 5: Überprüfe Gruppe Zusammenfassung
/dev/loop0: 103213/995520 Dateien (0.3% nicht zusammenhängend), 3716248/3977984 Blöcke

Ging also alles ziemlich glimpflich ab. :thumbs:

Ich vermute mal, mit

Code:
dd if=/IMAGE of/dev/sda7 bs=8K

kann ich das auf die Platte zurückschreiben?

Wobei ich mich allerdigns jetzt frage, ob ich das "bs=8K" wirklich brauche, immerhin habe ich das Image ohne diesen Zusatz angelegt...

Die nächste Frage ist natürlich, ob ich erst die betreffende Partition vergrößern soll (bzw. komplett in der richtigen Größe neu anlegen), oder erst danach. Oder ist es sinnvoller, die komplette gestern mit MC angelegte angelegte Sicherungskopie auf der neu formatierten und entsprechend vergrößerten sda7 zu kopieren?
 
A

Anonymous

Gast
Systemcrasher schrieb:
Ich vermute mal, mit

Code:
dd if=/IMAGE of/dev/sda7 bs=8K

kann ich das auf die Platte zurückschreiben?
genau das geht so nicht. Damit würdest du den defekten Zustand mit dem Offset wieder rüberkopieren.

lege einfach dort wo die defekte Partition jetzt ist ein neues Dateisystem an, wenn du noch Platz auf der Platte hast dann mach es vorher gleich etwas größer, und dann von dem von /dev/loop0 gemounteten Dateisystem alles dort in das neue und eventuell größere Dateisystem rüberkopieren. wenn das neue Dateisystem auf einer anderen Partition entsteht als das ehemalige, sollte dann noch die fstab geändert werden, das dein altes/neues Home dann auch wieder richtig gemountet wird und - fertig. [/quote]

robi
 
OP
Systemcrasher

Systemcrasher

Hacker
Ich habe mich dann doch entschieden, das System gleich komplett neu aufzusetzen. Ist jetzt die 13.1 drauf.

Da hab ich wieder für ne Weile Ruhe ;)

Drucker MFC 260c ist auch schon eingerichtet (ging diesmal - erstmals !!! - bequem über Yast). Die Dokus schieb ich die Tqage wieder auf die Platte von der Platte.

PS: Beide Partitionen (/ und /home) haben jetzt je 5 GB mehr Platz, XP dafür 10 GB weniger.
 
A

Anonymous

Gast
Sehr schön, ganz Arbeit umsonst :zensur:
gelöst ist für mich was anderes, das ist aufgegeben.

robi
 
Oben