Boot fails - what happened? An analysis with TestDisk

[thorr]

Hi everyone,

Sorry for the curious thread title. I think I'm not the first with my kind of problem, but the threads I've found so far only give instructions. I'd rather like to understand what has gone wrong with my filesystem.

I've got an Acer Switch 10 transformer tablet with an eMMC 32 GB drive. I upgraded the pre-installed Windows 8.1 to Windows 10, but changed nothing otherwise about the disk configuration. Recently, the tablet began to sporadically refuse to boot which evolved into a permanent problem (see photo of my boot screen).


I managed to boot Ubuntu from a USB flash drive* and ran TestDisk. The current partition structure looks like in the screenshot. It appears suspicious to me that the "MS Reserved" partition (no. 2) appears twice. Is this already faulty? Besides from that, are the messages "No FAT, ... marker" and "number of heads/cylinder mismatches" significant?

*For people also having problems with the Acer Switch 10 - probably coming here from a Google search - I would like to refer to the solution I found to get Ubuntu running from USB on the tablet: https://gist.github.com/franga2000/2154d09f864894b8fe84

I then did a quick search. TestDisk showed a non-recoverable partition and the message "The harddisk seems too small", see screenshot. What do both messages exactly mean? From my read through several threads, I guess they don't necessarily mean that there's something wrong.


After continuing, I was shown four partitions, see screenshot. Again, two partitions seem to show up twice each (with slightly different Start and End; I guess those are the "MS Data" and "Windows Recovery Env" from the last screenshot) while the "MS Reserved" partition does not show up anymore - which I can't really interpret.


I'm able to access the EFI System Partition and the last MS Data partition via pressing "p" (see screenshot), but the other three just give me the error message "Can't open filesystem. Filesystem seems damaged", see screenshots.


I had a look at the boot sectors via the "Avanced" menu and could see the "Boot" option only for the MS Data partition (no. 3). TestDisk says both boot sectors are OK, see screenshot.


What exact problem could I be faced with? What does it mean that the boot sector of the MS Data partition (is it a volume boot record?) be OK while the filesystem is damaged? Should I proceed with PhotoRec? I'm also curious about what could have happened to my device rendering it corrupted.

Thanks in advance!

[recuperation]

Hi everyone,

Sorry for the curious thread title. I think I'm not the first with my kind of problem, but the threads I've found so far only give instructions. I'd rather like to understand what has gone wrong with my filesystem.

I've got an Acer Switch 10 transformer tablet with an eMMC 32 GB drive. I upgraded the pre-installed Windows 8.1 to Windows 10, but changed nothing otherwise about the disk configuration. Recently, the tablet began to sporadically refuse to boot
which evolved into a permanent problem (see photo of my boot screen).

Da scheint die eMMC-Karte oder Teile davon nicht lesbar zu sein.

I managed to boot Ubuntu from a USB flash drive* and ran TestDisk. The current partition structure looks like in the screenshot. It appears suspicious to me that the "MS Reserved" partition (no. 2) appears twice. Is this already faulty? Besides from that, are the messages "No FAT, ... marker" and "number of heads/cylinder mismatches" significant?

Es könnte sein, dass die Speicherkarte im GPT-Format formatiert wurde und der Vorschlag von Testdisk bzw. die Auswahl zu Gunsten MBR falsch war - also falsche Einstellungen.

*For people also having problems with the Acer Switch 10 - probably coming here from a Google search - I would like to refer to the solution I found to get Ubuntu running from USB on the tablet: https://gist.github.com/franga2000/2154d09f864894b8fe84

I then did a quick search. TestDisk showed a non-recoverable partition and the message "The harddisk seems too small", see screenshot. What do both messages exactly mean? From my read through several threads, I guess they don't necessarily mean that there's something wrong.


After continuing, I was shown four partitions, see screenshot. Again, two partitions seem to show up twice each (with slightly different Start and End; I guess those are the "MS Data" and "Windows Recovery Env" from the last screenshot) while the "MS Reserved" partition does not show up anymore - which I can't really interpret.


I'm able to access the EFI System Partition and the last MS Data partition via pressing "p" (see screenshot), but the other three just give me the error message "Can't open filesystem. Filesystem seems damaged", see screenshots.

Das ist schade. Damit ist nachgewiesen, dass Testdisk hier nicht weiterkommt. Jetzt bleibt nur noch Photorec oder Drittanbietersoftware.

I had a look at the boot sectors via the "Avanced" menu and could see the "Boot" option only for the MS Data partition (no. 3). TestDisk says both boot sectors are OK, see screenshot.


What exact problem could I be faced with? What does it mean that the boot sector of the MS Data partition (is it a volume boot record?) be OK while the filesystem is damaged? Should I proceed with PhotoRec? I'm also curious about what could have happened to my device rendering it corrupted.

Ich habe keine Ahnung, ob eMMC-Karten Gesundheitsparameter à la SMART ausweisen. Bitte versuchen mit smartmontools von einem LiveLinux versuchen diese auszulesen und hier hochladen. Der nächste Schritt bestünde im Duplizieren der Karte mit Hilfe von ddrescue. Sowohl die Oberfläche von ddrescue als auch die unbedingt zu verwendende Logdatei zeigen eventuelle Fehler auf der Karte an.

Hat die Karte keinen Fehler, Reparaturinstallation mit Hilfe des Installationsdatenträger versuchen.

P.S.: Endliche mal eine saubere Dokumentation einer Datenpanne. Leider konnte ich bisher nicht wirklich viel zur Rettung von Daten beitragen...

[thorr]

Vielen Dank schon einmal für deine Antwort!

Ich habe keine Ahnung, ob eMMC-Karten Gesundheitsparameter à la SMART ausweisen. Bitte versuchen mit smartmontools von einem LiveLinux versuchen diese auszulesen und hier hochladen.

smartctl kennt MMCs leider nicht, aber mmc-utils ist wohl das entsprechende Tool für MMCs. Damit kann ich mir das Card-Specific Data register ausgeben lassen, aus dem ich mal die beiden Zeilen über den Gesundheitszustand ("EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_*") hier reinkopiere:

Code: Select all

ubuntu@ubuntu:~$ sudo mmc extcsd read /dev/mmcblk1
=============================================
  Extended CSD rev 1.7 (MMC 5.0)
=============================================
[...]
eMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x01
eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x0b
[...]

Der "TYP_A" bezieht sich auf den MMC-Typ Single-Level-Cell (SLC), der "TYP_B" auf den Typ Multi-Level-Cell (MLC). Ich weiß nur so grob, was der Unterschied ist, aber da ich gelesen habe, dass MLC-MMCs die günstigere und vorherrschende Variante sind, gehe ich davon aus, dass in meinem Tablet diese verbaut ist. Demnach schätze ich jetzt einfach mal, dass nur der Wert bei "TYP_B" aussagekräftig ist, und der ist eindeutig: 0x0b=11 bedeutet, dass ich bei 100-110% der Lebensspanne meines MMCs angelangt bin.* Das klingt nicht gut.
*Es war nicht so einfach, die Ausgabe von mmc zu interpretieren, aber in dieser PDF von SanDisk habe ich die nötigen Informationen dazu gefunden: https://datasheet.lcsc.com/lcsc/2105241 ... 830396.pdf

Der nächste Schritt bestünde im Duplizieren der Karte mit Hilfe von ddrescue. Sowohl die Oberfläche von ddrescue als auch die unbedingt zu verwendende Logdatei zeigen eventuelle Fehler auf der Karte an.

Das finde ich jetzt interessant. Ich hatte vorsorglich schon zwei Backups mit ddrescue gemacht und dabei aber jeweils keine bad sectors, bad areas oder read errors angezeigt bekommen, schien alles glatt gelaufen zu sein. Das klingt im Gegensatz zur life time ja eigentlich super. Allerdings haben die beiden Backups (zumindest auf meiner Festplatte) eine unterschiedliche Größe - das erste 30,3 GB, das zweite 31,3 GB. Das find ich wiederum komisch. [Edit: Das ist gar nicht komisch, da ich beim ersten Mal aus Versehen nur eine Partition gesichert habe.**] Vom ersten Backup hab ich ein Bildschirmfoto gemacht und beide Male das Logfile gespeichert.

Backup 1:

Code: Select all

# Mapfile. Created by GNU ddrescue version 1.23
# Command line: ddrescue /dev/mmcblk1p3 /media/nas/backup.dmg /media/nas/mapfile
# Start time:   2022-03-10 23:11:34
# Current time: 2022-03-11 02:59:30
# Finished
# current_pos  current_status  current_pass
0x71D8F0000     +               1
#      pos        size  status
0x00000000  0x71D8FBE00  +

Backup 2:

Code: Select all

# Mapfile. Created by GNU ddrescue version 1.23
# Command line: ddrescue /dev/mmcblk1 /media/BackupBrokenAcer/backup2/backup.dmg /media/BackupBrokenAcer/backup2/mapfile
# Start time:   2022-03-11 16:09:47
# Current time: 2022-03-11 19:46:37
# Finished
# current_pos  current_status  current_pass
0x747FF0000     +               1
#      pos        size  status
0x00000000  0x748000000  +

Mh... Das klingt für mich jetzt erstmal widersprüchlich. Die Lebensspanne ist laut ext-csd überschritten und offenbar ist meine Karte ja fehlerhaft, sonst würde mein System booten... Aber warum zeigt ddrescue dann keine Fehler an?

Es könnte sein, dass die Speicherkarte im GPT-Format formatiert wurde und der Vorschlag von Testdisk bzw. die Auswahl zu Gunsten MBR falsch war - also falsche Einstellungen.

Ja, die Formatierung ist in EFI GPT. Das wurde auch so erkannt und ausgewählt bei der Analyse durch TestDisk.

P.S.: Endliche mal eine saubere Dokumentation einer Datenpanne. Leider konnte ich bisher nicht wirklich viel zur Rettung von Daten beitragen...

Ich find eure Arbeit echt super und bin dafür sehr dankbar! Da möchte ich es euch so einfach wie möglich machen, mir zu helfen. Und ich finde dieses Thema auch einfach spannend und versuche, selbst so weit wie möglich zu kommen.

PS: Wie hast du eigentlich herausgefunden, dass ich Deutsch spreche?

**Wenn ich die beim "Current partition status" angezeigte Sektoranzahl für die Partition 3 in GB umrechne (Sektoranzahl*512B*1000^-3, oder?), erhalte ich 30,6GB, das (erste) Backup ist aber nur 30,3 GB groß. Liegt das im "Toleranzbereich"?

[recuperation]

Mh... Das klingt für mich jetzt erstmal widersprüchlich. Die Lebensspanne ist laut ext-csd überschritten und offenbar ist meine Karte ja fehlerhaft, sonst würde mein System booten... Aber warum zeigt ddrescue dann keine Fehler an?

ddrescue hat im Kopierprozess auf den eventuell beschädigten Datenträger nur lesend zugegriffen. Gute Flash-Medien lassen am Ende ihrer Lebenszeit noch einen lesenden Zugang zu. Schlechte Medien verweigern ihren Dienst komplett.
Das auf dem Rechner vorhandene Betriebssystem möchte sicherlich auch auf den Datenträger schreiben. Ob das geht, wurde bisher nicht erprobt.

PS: Wie hast du eigentlich herausgefunden, dass ich Deutsch spreche?

Welcher Ausländer würde einen nur deutschsprachigen Bilder-Hoster benutzen?

**Wenn ich die beim "Current partition status" angezeigte Sektoranzahl für die Partition 3 in GB umrechne (Sektoranzahl*512B*1000^-3, oder?), erhalte ich 30,6GB, das (erste) Backup ist aber nur 30,3 GB groß. Liegt das im "Toleranzbereich"?

Ich sehe "current partitions status" nicht. Toleranzbereiche gibt es nicht. Die Länge der Partition laut ddrescue beträgt 71D8FBE00 (hex) Bytes, das macht genau 30.560.730.624 Bytes. Bitte die Angabe 30,3 GB überprüfen und besser Byte-genaue Werte verwenden, da ansonsten nie klar ist, wie genau (Basis 1000 oder 1024) das umgerechnet worden ist!

[thorr]

Ich sehe "current partitions status" nicht. Toleranzbereiche gibt es nicht. Die Länge der Partition laut ddrescue beträgt 71D8FBE00 (hex) Bytes, das macht genau 30.560.730.624 Bytes. Bitte die Angabe 30,3 GB überprüfen und besser Byte-genaue Werte verwenden, da ansonsten nie klar ist, wie genau (Basis 1000 oder 1024) das umgerechnet worden ist!

Ich meinte "current partition status" (erster Screenshot, erster Post), sorry. 71d8fbe00B=30.560.730.624B haut mit den 59688927 Sektoren hin. Ich weiß gerade nicht genau, woher ich die GB-Angaben hatte - ich glaube, es war aus dem Ubuntu-Filemanager (nautilus). Da scheint dann aber mit der Umrechnung etwas nicht ganz zu stimmen, denn 30.560.730.624B sind weder 30.3GB noch 30.3GiB. Ich werde das nochmal checken, wenn ich wieder zu Hause bin (Montag).

ddrescue hat im Kopierprozess auf den eventuell beschädigten Datenträger nur lesend zugegriffen. Gute Flash-Medien lassen am Ende ihrer Lebenszeit noch einen lesenden Zugang zu. Schlechte Medien verweigern ihren Dienst komplett.

Interessant, danke! Dann könnte ich ja mal versuchen, das mit ddrescue erstellte Image zu mounten und da ddrescue keine Fehler angezeigt hat, besteht eine Chance, dass die Daten dort vorhanden sind?

Das auf dem Rechner vorhandene Betriebssystem möchte sicherlich auch auf den Datenträger schreiben. Ob das geht, wurde bisher nicht erprobt.

Wie kann ich das erproben?

[recuperation]

Ich sehe "current partitions status" nicht. Toleranzbereiche gibt es nicht. Die Länge der Partition laut ddrescue beträgt 71D8FBE00 (hex) Bytes, das macht genau 30.560.730.624 Bytes. Bitte die Angabe 30,3 GB überprüfen und besser Byte-genaue Werte verwenden, da ansonsten nie klar ist, wie genau (Basis 1000 oder 1024) das umgerechnet worden ist!

Ich meinte "current partition status" (erster Screenshot, erster Post), sorry. 71d8fbe00B=30.560.730.624B haut mit den 59688927 Sektoren hin. Ich weiß gerade nicht genau, woher ich die GB-Angaben hatte - ich glaube, es war aus dem Ubuntu-Filemanager (nautilus). Da scheint dann aber mit der Umrechnung etwas nicht ganz zu stimmen, denn 30.560.730.624B sind weder 30.3GB noch 30.3GiB. Ich werde das nochmal checken, wenn ich wieder zu Hause bin (Montag).

ddrescue hat im Kopierprozess auf den eventuell beschädigten Datenträger nur lesend zugegriffen. Gute Flash-Medien lassen am Ende ihrer Lebenszeit noch einen lesenden Zugang zu. Schlechte Medien verweigern ihren Dienst komplett.

Interessant, danke! Dann könnte ich ja mal versuchen, das mit ddrescue erstellte Image zu mounten und da ddrescue keine Fehler angezeigt hat, besteht eine Chance, dass die Daten dort vorhanden sind?

Wenn die Quelle Daten enthielt ja. Der Kopiervorgang scheint ja fehlerfrei verlaufen zu sein.

Das auf dem Rechner vorhandene Betriebssystem möchte sicherlich auch auf den Datenträger schreiben. Ob das geht, wurde bisher nicht erprobt.

Wie kann ich das erproben?

Live Linux starten und versuchen auf den Datenträger eine Datei draufzuschreiben.

[thorr]

Wenn die Quelle Daten enthielt ja. Der Kopiervorgang scheint ja fehlerfrei verlaufen zu sein.

Leider habe ich genau dasselbe Bild, wenn ich mit TestDisk die Image-Datei öffne. Was könnte das im Hinblick darauf, dass ddrescue ja ohne Fehler durchgelaufen ist, bedeuten?

Live Linux starten und versuchen auf den Datenträger eine Datei draufzuschreiben.

Dazu müsste ich die Platte mounten, oder? Das schlägt bei mir mit der folgenden Meldung fehl:

Code: Select all

ubuntu@ubuntu:~$ sudo mount /dev/mmcblk1p3 /mnt/Acer
Record 0 has corrupt in-use size (524808 > 1024)
Failed to load $MFT: Input/output error
Failed to mount '/dev/mmcblk1p3': Input/output error
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.

Partionen p1 und p4 lassen sich mounten (so wie ich mir deren Inhalt auch in TestDisk anzeigen lassen kann), p2 lässt sich hingegen nicht mounten:

Code: Select all

ubuntu@ubuntu:/mnt$ sudo mount /dev/mmcblk1p2 /mnt/Acer
mount: /mnt/Acer: wrong fs type, bad option, bad superblock on /dev/mmcblk1p2, missing codepage or helper program, or other error.

Ich probiere jetzt mal PhotoRec aus. Ich hab mir auch schon einen Win-Rescue-Stick fertig gemacht - ich hab da aber immer etwas Angst, dass chkdisk einfach alles platt macht. Ich hab zwar zwei ddrescue-Backups, aber ich bin paranoid.