Beiträge von hammu

das sagt:

localhost:/home/hgtschudi # df -h /run/media/hgtschudi/9efbc298-4f1e-4aea-b3a4-363caec1ef00/home/
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda2       110G     85G   24G   79% /run/media/hgtschudi/9efbc298-4f1e-4aea-b3a4-363caec1ef00

das.

Zitat von luigi

Konntest du nun nach Neustart normal auf die usb-Platte zugreifen und die Partition auslesen?

Falls nicht, dann als root

Code

dmesg

und die Ausgabe nach BTRFS: error durchsuchen ...

Auf die Platte kann ich zugreifen. Das Home-Verzeichnis ist aber immer noch leer. Da waren vor dem Schaden die Unterverzeichnisse von 4 Nutzern.

Ich habe dann "dmsg eingegeben und erhielt am Ende einer langen Liste folgende 2 BTRFS-Meldungen.

und noch 2 NOHZ-Fehlermeldungen dazu:

 52.666345] BTRFS info (device sda2): disk space caching is enabled
[   52.666354] BTRFS info (device sda2): has skinny extents
[   58.175107] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!!
[   58.175664] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!!

Zitat von luigi

Falls ich die Ausgabe von parted richtig verstehe, handelt es sich um ein btrfs-Filesystem, da muss man aber mit einem anderen tool ran.

Außerdem würde ich nicht auf die gesamte Platte /dev/sdc losgehen, sondern nur auf einzelne Partitionen, oder ?

Hallo Luigi. Das mit dem btrfs leuchtet mir ein. Ich habe gleich Deine zwei Vorschläge ausprobiert. Hier ist das Ergebnis Das Laufwerk hat sich heute verändert. Es ist /dev/sda geworden. Entsprechend:

localhost:/home/hgtschudi # btrfs rescue super-recover -v /dev/sda2
All Devices:
        Device: id = 1, name = /dev/sda2

Before Recovering:
        [All good supers]:
                device name = /dev/sda2
                superblock bytenr = 65536

                device name = /dev/sda2
                superblock bytenr = 67108864

        [All bad supers]:

All supers are valid, no need to recover

"All Supers are valid, no need to recover" das klingt sehr gut in meinen Ohren!

Daraufhin habe ich deinen zweiten Vorschlag ausprobiert und erhielt:

localhost:/home/hgtschudi # btrfs rescue zero-log /dev/sda2
Clearing log on /dev/sda2, previous log_root 0, level 0

was sagst Du dazu?

Zitat von Alero

Code

Der Superblock ist unlesbar bzw. beschreibt kein gültiges ext2/ext3/ext4-
Dateisystem. Wenn das Gerät gültig ist und ein ext2/ext3/ext4-
Dateisystem (kein swap oder ufs usw.) enthält, dann ist der Superblock
beschädigt, und Sie könnten versuchen, e2fsck mit einem anderen Superblock
zu starten:    e2fsck -b 8193 <Gerät> oder    e2fsck -b 32768 <Gerät>

oben in #7Wie kommst du überhaupt auf 8193? Ist gar nicht dabei!

Die Zahl "8193" tauchte als Ergebnis der Eingabe Deines Vorschlags auf:

"e2fsck -f -y -b <Superblock> /dev/sdc:"

siehe oben in #7, Zeile 5-10.

Dort fand ich die Empfehlung:

Der Superblock ist unlesbar bzw. beschreibt kein gültiges ext2/ext3/ext4-
Dateisystem. Wenn das Gerät gültig ist und ein ext2/ext3/ext4-
Dateisystem (kein swap oder ufs usw.) enthält, dann ist der Superblock
beschädigt, und Sie könnten versuchen, e2fsck mit einem anderen Superblock
zu starten:
    e2fsck -b 8193 <Gerät>
 oder
    e2fsck -b 32768 <Gerät>

Hatte ich das falsch verstanden?

Zitat von Alero

Ich meine nicht, das du bei der Masse an beschädigten Blöcken das Ding noch gerichtet bekommst. Ich würde neu partitionieren und gut.

Vielleicht bleibt mir nichts anderes zu tun übrig.

Ich warte aber noch damit. Mal sehen, vielleicht tut sich ja doch noch ne Tür auf.

Zitat von Alero

Superblöcke anzeigen lassen mit

Code

mke2fs -n /dev/sdc

hier ist das Ergebnis:

Code

localhost:/home/hgtschudi # mke2fs -n /dev/sdc
mke2fs 1.46.4 (18-Aug-2021)
In /dev/sdc wurde eine gpt-Partitionstabelle gefunden
Trotzdem fortfahren? (j,n) j
Ein Dateisystem mit 29305206 (4k) Blöcken und 7331840 Inodes wird erzeugt.
UUID des Dateisystems: 9c682ceb-c7fb-4aa0-828d-67561831a651
Superblock-Sicherungskopien gespeichert in den Blöcken: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424, 20480000, 23887872

Reparieren mit:

Code

e2fsck -f -y -b <Superblock> /dev/sdc

Für <Superblock> setzt du natürlich die oben ermittelten Blöcke ein. Ohne Garantie.

Alles anzeigen

hier ist das Ergebnis von: e2fsck -f -y -b <Superblock> /dev/sdc:

 localhost:/home/hgtschudi # e2fsck -f -y -b 8193 /dev/sdc
e2fsck 1.46.4 (18-Aug-2021)
e2fsck: Ungültige magische Zahl im Superblock beim Versuch, /dev/sdc zu öffnen

Der Superblock ist unlesbar bzw. beschreibt kein gültiges ext2/ext3/ext4-
Dateisystem. Wenn das Gerät gültig ist und ein ext2/ext3/ext4-
Dateisystem (kein swap oder ufs usw.) enthält, dann ist der Superblock
beschädigt, und Sie könnten versuchen, e2fsck mit einem anderen Superblock
zu starten:
    e2fsck -b 8193 <Gerät>
 oder
    e2fsck -b 32768 <Gerät>

In /dev/sdc wurde eine gpt-Partitionstabelle gefunden

Was hat es mit der letzten Zeile in der Meldung oben auf sich?

In /dev/sdc wurde eine gpt-Partitionstabelle gefunden

Mir sagt das leider nichts.

Zitat von Forentroll

Da ich aktuell keinen Linux-Rechner in der Nähe habe, kann ich leider nicht weiterhelfen.

Gibt es denn auf der defekten Platte wichtige Daten, deren Verlust schwer zu verschmerzen wären? Falls ja, vielleicht liest da ja einer von Gurus hier.

Ich will nicht so schnell aufgeben.

Ich habe die Platte jetzt noch einmal gemountet und "parted -l " auf Konsole eingegeben. Da bekomme ich folgende interessantere Ausgabe:

localhost:/home/hgtschudi # parted -l
Modell: HITACHI HTS541612J9SA00 (scsi)
Festplatte  /dev/sdc:  120GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags: pmbr_boot

Nummer  Anfang  Ende    Größe   Dateisystem     Name  Flags
 1      1049kB  9437kB  8389kB                        bios_grub
 2      9437kB  118GB   118GB   btrfs                 legacy_boot
 3      118GB   120GB   2148MB  linux-swap(v1)        swap


Modell: NVMe Device (nvme)
Festplatte  /dev/nvme0n1:  256GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang  Ende   Größe   Dateisystem     Name  Flags
 1      1049kB  525MB  524MB   fat16                 boot, esp
 2      525MB   254GB  253GB   btrfs
 3      254GB   256GB  2148MB  linux-swap(v1)        swap

Übrigens, der Link, den ich in #1 dieses Beitrags angegeben habe, funktioniert nicht, wie ich gerade gemerkt habe. Hier ist der korrekte: "https://www.opensuse-forum.de/thread/66690-daten-von-festplatte-auslesen/?pageNo=1"

Wie gesagt, es geht darum, den Superblock auf obiger, in /dev/sdc eingebundener externer HITACHI-Festplatte zu reparieren versuchen.

Für Hilfe bin ich dankbar.

Zitat von Forentroll

Code

e2fsck -f -y -b 8193 /dev/sda

oder

e2fsck -f -y -b 32768 /dev/sda

das habe ich eingegeben. hat aber, wie schon vorher, m.E. nichts neues gebracht:

Code

localhost:/home/hgtschudi # e2fsck -f -y -b 32768 /dev/sdc
e2fsck 1.46.4 (18-Aug-2021)
e2fsck: Ungültige magische Zahl im Superblock beim Versuch, /dev/sdc zu öffnen

Der Superblock ist unlesbar bzw. beschreibt kein gültiges ext2/ext3/ext4-
Dateisystem. Wenn das Gerät gültig ist und ein ext2/ext3/ext4-
Dateisystem (kein swap oder ufs usw.) enthält, dann ist der Superblock
beschädigt, und Sie könnten versuchen, e2fsck mit einem anderen Superblock
zu starten:
    e2fsck -b 8193 <Gerät>
 oder
    e2fsck -b 32768 <Gerät>

In /dev/sdc wurde eine gpt-Partitionstabelle gefunden

Alles anzeigen

herzlichen Dank für die gründliche Aufklärung!

Hartmut

Ich habe hier eine über den USB-port eingebundene externe Festplatte mit beschädigtem Superblock. Ich war ursprünglich einmal dran, deren Daten auszulesen, als die bad-superblockmeldung unvermittelt auftauchte. (Wie es dazu kam ist hier im Forum unter: . "Daten von Festplatte auslesen." nachzulesen.)

So sieht es auf der FP meines Lenovo-Laptops /dev/sda aus:

localhost:/home/hgtschudi # lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 111,8G  0 disk 
├─sda1        8:1    0     8M  0 part 
├─sda2        8:2    0 109,8G  0 part 
└─sda3        8:3    0     2G  0 part 
nvme0n1     259:0    0 238,5G  0 disk 
├─nvme0n1p1 259:1    0   500M  0 part /boot/efi
├─nvme0n1p2 259:2    0   236G  0 part /usr/local
│                                     /boot/grub2/x86_64-efi
│                                     /var
│                                     /boot/grub2/i386-pc
│                                     /tmp
│                                     /.snapshots
│                                     /home
│                                     /root
│                                     /srv
│                                     /opt
│                                     /
└─nvme0n1p3 259:3    0     2G  0 part [SWAP]

Ich habe dann entsprechend der Anleitung auf https://www.linuxmaker.com/tutorials/bad-superblock-on-und-nichts-geht-mehr.html, die Reparatur mit:

e2fsck -f /dev/sda

versucht und erhielt folgende Meldung:

localhost:/home/hgtschudi # e2fsck -f /dev/sda

e2fsck 1.46.4 (18-Aug-2021)

ext2fs_open2: Ungültige magische Zahl im Superblock

e2fsck: Superblock ungültig, Datensicherungs-Blöcke werden versucht ...

e2fsck: Ungültige magische Zahl im Superblock beim Versuch, /dev/sda zu öffnen


Der Superblock ist unlesbar bzw. beschreibt kein gültiges ext2/ext3/ext4-

Dateisystem. Wenn das Gerät gültig ist und ein ext2/ext3/ext4-

Dateisystem (kein swap oder ufs usw.) enthält, dann ist der Superblock

beschädigt, und Sie könnten versuchen, e2fsck mit einem anderen Superblock

zu starten:

   e2fsck -b 8193 <Gerät>

oder

   e2fsck -b 32768 <Gerät>

In /dev/sda wurde eine gpt-Partitionstabelle gefunden

der nächste Schritt wäre entsprechend der Anleitung:

e2fsck -f -y -b <Superblock> /dev/nbd0p1

Hier weiß ich nicht weiter! Was muss ich in meinem Fall für "Superblock" eingeben?