staging.inyokaproject.org

babanek schrieb:

[…] Laptop mit 20.04. […] eingebaute Festplatte ist nicht mehr lesbar […] externe Festplatte mit 16.04.6 […] Als Quelle habe ich die den Namen der Festplatte und als Ziel einen selbst gewählten Namen der Datei eingegeben.

Hast Du nicht! Weil:

[…]

# Rescue Logfile. Created by GNU ddrescue version 1.19
# Command line: ddrescue -n /dev/sda1 /home/babanek/Dokumente/Sicherungsda1 ddrescue.log

Du hast lediglich eine einzige Partition von der Platte gesichert, die zum Zeitpunk der Datensicherung den temporären Namen sda hatte. Ob dies die eingebaute Platte bezeichnete, ist ungewiss, aber möglich. Wenn es zutrifft, und wenn auf der ersten Partition auch das Verzeichnis /home/ des defekten Systems war und wenn keine separate Partition für /home/ verwendet wurde, dann ist das aber genau so gut wie Deine Absicht.

Allerdings sind dann alle Überlegungen und Maßnahmen in Richtung Partitionstabelle sinnlos.

babanek schrieb:

[…]

babanek@Linuxext1:~$ sudo fsck /dev/sda1
[…]
/dev/sda1 besitzt nicht unterstützte Eigenschaft(en): metadata_csum
e2fsck: Neuere Version von e2fsck benötigt!

Schleierhaft.

Durchaus verständlich. Beim Dateisystem ext4 gibt es inkompatible Änderungen zwischen der Version, die von Ubuntu 16.04 und der, die bei 20.04 verwendet wird. Mit einem Kernel und einem fsck von 16.04 kann ein Dateisystem von 20.04 nicht repariert werden, und fsck meldet das ja auch.

Um 20.04 zu retten, benötigst Du ein Rettungssystem auf dem Stand von 20.04 oder neuer.

Da liegt wohl das eigentliche Problem. Der Festplattenmanager (immerhin funktioniert der noch) zeigt tatsächlich nur eine einzige Partition für sda1 an, obwohl da mehrere drauf waren. Es sieht also ganz danach aus, als ob die Partitionstabelle selbst abgeschossen wurde. Das würde wohl auch erklären, warum sämtliche Versuche mit verschiedenen Programmen zu recht merkwürdigen Fehlermeldungen führen. Hätte ich nur eine (saubere) Partition gesichert, müsste sie sich einhängen lassen. Aber die Meldung "Partition sector doesn't have the endmark 0xAA55" weist wohl darauf hin, das da was fehlt.

babanek schrieb:

Es sieht also ganz danach aus, als ob die Partitionstabelle selbst abgeschossen wurde.

Nein. So sieht es aus, wenn gar keine Partitionstabelle da ist. Wenn Du nur eine Partition gesichert hast, ist das eben so und auch richtig.

[…] Hätte ich nur eine (saubere) Partition gesichert, müsste sie sich einhängen lassen.

Nein, das stimmt nicht! Wenn das in der Partition installierte Dateisystem einen defekten Superblock hat, kann es beispielsweise nicht eingebunden werden. Reparatur mit einem hinreichend aktuellen fsck, wie bereits erläutert.

Aber die Meldung "Partition sector doesn't have the endmark 0xAA55" weist wohl darauf hin, das da was fehlt.

Sie besagt nur, dass im ersten Sektor kein Bootsektor und keine Partitionstabelle ist. Das ist bei einer Partition bzw. dem Abbild einer Partition ein zulässiger Zustand.

So, jetzt ist das Problem gelöst. Auf die leere Festplatte habe ich 20.04. installiert und dann mit fsck die Festplatte repariert. Offenbar war das alte 16.04. wirklich nicht kompatibel mit fsck.

EIN DICKES DANKESCHÖN EUCH ALLEN!

Da ddrescue nicht alle Sektoren lesen konnte, waere ich nicht so euphorisch. Was zeigt denn smartctl -a /dev/$kaputtedisk an?