Beim Booten "something wrong with extent"

[halo44]

Gestern liess sich mein Desktoprechner nicht mehr booten. Eine Reparatur schien zunächst nicht möglich, gelang schließlich aber doch. Das „Problem“ ist also nicht mehr existent, aber ich wüsste doch gern, was die Ursache gewesen sein könnte.

Den Ablauf möchte ich aus der Erinnerung dokumentieren, wobei ich hoffe nichts Wichtiges vergessen zu haben.

Vorgeschichte

Auf meinem Desktoprechner habe ich Debian-Stretch und Kanotix installiert. Systemsicherungen der Installationen mache ich jeweils aus dem jeweils anderen OS.

Ich habe aus Kanotix die Root- und die Homepartition meines Debian-OS mit rsync auf externe Festplatte gesichert, weil ich eine neuere Version meiner Softmaker-Office-Anwendung installieren wollte.

Diese Sicherung mache ich immer, wenn ich nicht sicher bin, ob ich nicht später wieder zum Status-quo zurückkehren will.

Zuerst scheiterte die Sicherung, indem sie bereits nach wenigen Sekunden den Erfolg meldete, aber für beide Partitionen eine Größe von 4K anzeigte. Dies ist gewöhnlich der Fall, wenn das Mounten der Ein- und/oder Ausgabepartition nicht gelang.

Ich habe daher die externe Festplatte getrennt und wieder neu angeschlossen, bevor ich die Sicherung neu startete. Diesmal gelang sie mit 7,9 bzw. 1,9 GB.

Ich habe dann wieder Debian gestartet und die neue Office-Version installiert, wodurch die Version aus 2012 ersetzt wurde. Getestet habe ich dann die Tabellenkalkulation und als für mich nicht geeignet verworfen.

Also habe ich aus Kanotix heraus die Systemsicherung von Debian zurückgeladen und den Rechner neu gestartet.

Rechner bootet nicht

Der Bootvorgang scheiterte und meldete „error: something wrong with extent“, zeigte dann grub rescue > , was für mich bedeutete, daß ich den Bootloader reparieren musste.

Ich startete daher den Rechner mit einem Debian Live-USB-Stick, mountete dann die /dev/sda1 (Rootpartition von Debian) nach /mnt, /dev, /sys und /proc mit bind bzw. proc auch nach /mnt.

Auf das anschließende chroot /mnt /bin/bash erhielt ich die Fehlermeldung „chroot: /bin/bash Exec format error“.

Anschließende Versuche mit Super-Brub2-CD und rescatux blieben erfolglos. Beide fanden keine OS, keine grub.cfg, aber alle Partitionen, jedoch mit „unbekanntem Dateisystem“.

Danach startete ich mit einer Debian-9.4-Netinstall-CD und wählte Advanced options >> Rescue Mode. Dort wurde mir nach einigen Zwischenschritten angeboten „Bootloader neu installieren“, was ich auch wählte.

Der Vorgang startete, brach aber bei der Anzeige 50% ab und bot erneut das Neuinstallieren des Bootloaders an. Hier brach ich ab.

Ich startete den Rechner neu, wobei der Bootloader überraschend startet und mir die Auswahl von Debian oder Kanotix an. Ich wählte Debian und die ersten Systemmeldungen liefen über den Bildschirm, wobei allerdings rote Warnungen über erfolgloses Mounten von Daten-Partitionen und gelbe Hinweise auf Abhängigkeitsprobleme erfolgten. Schließlich fror der Rechner ein.

Beim nächsten Startversuch wählte ich Kanotix, welches problemlos sauber hochfuhr. Daher nutzte ich dort das Zurückladen der Debian-Systemsicherung.

Beim folgenden Reboot aber scheiterte der Bootvorgang erneut und zeigte mir wieder „error: something wrong with extent“, zeigte dann grub rescue > grub rescue >.

Ich habe daher wieder die Debian-9.4-Netinstall-CD verwandt, wie vorher beschrieben und konnte wieder booten, wobei beim Start von Debian wieder die Fehler gemeldet wurden und der Rechner einfror.

Kanotix aber startete und so konnte ich die vorletzte Systemsicherung von Debian zurückladen. Anschließend liess sich auch Debian starten und die Welt war wieder in Ordnung.

Ganz offensichtlich war also die letzte Systemsicherung fehlerhaft (oder unvollständig?) und hat den kompletten Rechner samt Bootloader unbrauchbar gemacht.

Das „Problem“ ist also nicht mehr existent, aber ich wüsste doch gern, was die Ursache gewesen sein könnte.

Darum frage ich hier, ob jemand einen Hinweis geben kann, was mögliche Auslöser sein könnten. Hierzu liess sich nicht vermeiden einen solch langen Beitrag zu verfassen. Schliesslich wollte ich nichts unerwähnt lassen.

Andererseits ist alles aus der Erinnerung beschrieben und nicht sicher vollständig.

[whisper]

Ich startete daher den Rechner mit einem Debian Live-USB-Stick, mountete dann die /dev/sda1 (Rootpartition von Debian) nach /mnt, /dev, /sys und /proc mit bind bzw. proc auch nach /mnt.

Auf das anschließende chroot /mnt /bin/bash erhielt ich die Fehlermeldung „chroot: /bin/bash Exec format error“.

Ist das jetzt nur versehentlich falsch beschrieben, oder hast du wirklich alles auf /mnt gemountet?
Es müsste z.B. für proc /mnt/proc sein usw...
Ansonsten kann ich nicht helfen, bin aber interessiert, ob jemand eine Erklärung parat hat

[halo44]

... Ist das jetzt nur versehentlich falsch beschrieben, oder hast du wirklich alles auf /mnt gemountet?
Es müsste z.B. für proc /mnt/proc sein usw...
Ansonsten kann ich nicht helfen, bin aber interessiert, ob jemand eine Erklärung parat hat

Nein, ich habe nach /mnt/dev, /mnt/sys und /mnt/proc gemountet. Ich wollte nur den Satz nicht überfrachten, bin davon ausgegangen, daß jeder weiß, was ich meine.

Aber danke für Dein Interesse.

Gruss H.

[rendegast]

Log-Einträge der letzten Zeit, die auf Speicher- oder Platten-Fehler deuten?
zBsp. Programmabbrüche

smart? (Auch beim Sicherungsmedium)

Code: Alles auswählen

smartctl /dev/sdX -a

[halo44]

Log-Einträge der letzten Zeit, die auf Speicher- oder Platten-Fehler deuten?
zBsp. Programmabbrüche

smart? (Auch beim Sicherungsmedium)

Code: Alles auswählen

smartctl /dev/sdX -a

Log-Einträge kann ich nicht mehr überprüfen, da ich ja (siehe Eröffnungspost) eine ältere Sicherung zurückgeladen habe.

Smart der /dev/sda und /dev/sdb ohne Error. Aber beim Sicherungsmedium finden sich 3 Errors, wobei der Error 3 bei 218 Std. zeitlich passen würde. Gesamtlaufzeit derzeit 220 Std.

Code: Alles auswählen

Error 3 occurred at disk power-on lifetime: 218 hours (9 days + 2 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 50 00 ff 43 44 40   at LBA = 0x004443ff = 4473855

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  35 ff a0 60 3d 44 40 00      00:00:38.851  WRITE DMA EXT
  aa aa aa aa aa aa aa ff      00:00:38.388  [RESERVED]
  35 00 a0 60 3d 44 40 00      00:00:38.154  WRITE DMA EXT
  35 00 a0 c0 35 44 40 00      00:00:38.143  WRITE DMA EXT
  35 00 d8 e8 2e 44 40 00      00:00:38.073  WRITE DMA EXT

Sagt Dir das was?

Gruss H.

[rendegast]

"WRITE DMA ..."
könnte ein Speicherfehler sein oder ein Leitungsproblem?

'smartctl -a ....'
nach nopaste.debianforum.de?



"... at LBA = .... = ...."
mal einen Lesetest anstoßen?

Code: Alles auswählen

smartctl -s on -o on -S on /dev/sdX       (generell smart-Features aktivieren)
smartctl -t long /dev/sdX

(läuft innerhalb der Plattenfirmware, also nicht von der Leitung abhängig)

[halo44]

"WRITE DMA ..."
könnte ein Speicherfehler sein oder ein Leitungsproblem?

Die externe Festplatte ist über USB-3 angeschlossen. Kann auch der USB-Anschluß Leitungsprobleme verursachen?

'smartctl -a ....'
nach nopaste.debianforum.de?

Hier die Ausgabe 40440

"... at LBA = .... = ...."
mal einen Lesetest anstoßen?

Code: Alles auswählen

smartctl -s on -o on -S on /dev/sdX       (generell smart-Features aktivieren)
smartctl -t long /dev/sdX

(läuft innerhalb der Plattenfirmware, also nicht von der Leitung abhängig)

Test werde ich durchführen. Dauert natürlich.

Gruss H.

[halo44]

Erster sagt:

Code: Alles auswählen

smartctl -s on -o on -S on /dev/sdd

smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-8-amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF ENABLE/DISABLE COMMANDS SECTION ===
SMART Enabled.
SMART Attribute Autosave Enabled.
SMART Automatic Offline Testing Enabled every four hours.

Zweiter sagt:

Code: Alles auswählen

smartctl -t long /dev/sdd

smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-8-amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 118 minutes for test to complete.
Test will complete after Thu Sep 13 17:01:41 2018

Use smartctl -X to abort test.

Die blaue LED an der externen Festplatte bleibt nur kurz an und verlischt dann. Es findet wohl keine Aktivität statt. Nach zwei Stunden zeigt ein

Code: Alles auswählen

smartctl -a /dev/sdd

im wesentlichen die gleichen Informationen, wie heute morgen gepostet. Allerdings findet sich jetzt zusätzlich:

Code: Alles auswählen

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Aborted by host               90%       221         -
# 2  Extended offline    Aborted by host               90%       220         -

Das stimmt wohl was nicht?

Gruss H.

[rendegast]

# 1 Extended offline Aborted by host 90% 221 -

"Aborted by host" ist ein Abbruch des Tests durch zBsp. Ausschalten des Systems oder Abschalten der Platte,
somit bedeutet es nur "Test nicht abgeschlossen".

Lese- oder Schreibvorgänge verursachen dieses nicht, der Test wird da nur aus- und später fortgesetzt.

Ein evtl. Abschalten der Platte könnte vielleicht verhindert werden durch ein kurzes Auslesen

Code: Alles auswählen

dd if=/dev/sdX of=/dev/null count=1
oder
smartctl /dev/sdX -c -l selftest

alle paar Minuten.

[halo44]

# 1 Extended offline Aborted by host 90% 221 -

"Aborted by host" ist ein Abbruch des Tests durch zBsp. Ausschalten des Systems oder Abschalten der Platte,
somit bedeutet es nur "Test nicht abgeschlossen".

Lese- oder Schreibvorgänge verursachen dieses nicht, der Test wird da nur aus- und später fortgesetzt.

Ein evtl. Abschalten der Platte könnte vielleicht verhindert werden durch ein kurzes Auslesen

Code: Alles auswählen

dd if=/dev/sdX of=/dev/null count=1
oder
smartctl /dev/sdX -c -l selftest

alle paar Minuten.

Ich habe den Test nochmal gestartet. Die Platte schaltet sich sich nach exakt 3 Minuten aus. Da der extended Test 118 Minuten laufen soll, müßte ich diese Zeit vor dem Rechner sitzen und rechtzeitig vor Ablauf der 3 Minuten das kurze Auslesen starten.

Der kurze Test dauert zwei Minuten und wird offensichtlich komplett durchgeführt:

Code: Alles auswählen

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%       222         -
# 2  Extended offline    Aborted by host               90%       222         -
# 3  Extended offline    Aborted by host               90%       221         -
# 4  Extended offline    Aborted by host               90%       220         -

Ich werde mal den Langtest starten und versuchen das Auslesen alle 2 Minuten durch einen cronjob vornehmen zu lassen.

Gruss H.

[halo44]

Mit Hilfe des cronjobs konnte ich jetzt den long-Test durchführen. Er fand keine Fehler:

Code: Alles auswählen

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%       225         -
# 2  Short offline       Completed without error       00%       222         -
# 3  Extended offline    Aborted by host               90%       222         -
# 4  Extended offline    Aborted by host               90%       221         -
# 5  Extended offline    Aborted by host               90%       220         -

Gruss H.

[rendegast]

... müßte ich diese Zeit vor dem Rechner sitzen und rechtzeitig vor Ablauf der 3 Minuten das kurze Auslesen starten.
...
Ich werde mal den Langtest starten und versuchen das Auslesen alle 2 Minuten durch einen cronjob vornehmen zu lassen.

In einem terminal

Code: Alles auswählen

while true; do irgendwas; sleep 100; done

oder
watch -n100 -d=cum 'irgendwas; noch irgendwas; ...' 

Zum Thema
Dann ist die Platte selbst ja wohl oK.
(Ein kompletter, Daten-zerstörender Test wäre
'badblocks -svw /dev/sdX'
und dauert 8x den smart-long-Test (bei bester Verbindung, zBsp. Platte direkt am SATA-Kabel).
Halb so lang, im Fehlerfall doch potentiell Daten-zerstörend:
'badblocks -svn -c $((256*1024)) /dev/sdX'
(Die '-c'-Option beim letzteren noch höher, um den Lesekopf noch mehr zu schonen))

[ChoMar]

Man kann auch bei den meisten USB-Platten die Sleep-Parameter mit hdparm anpassen.
Müsste auch bei USB3 noch so sein.
Das der UDMA_CRC_Error_Count nicht 0 ist und das WRITE DMA EXT deutet auf Kommunikationsprobleme hin.
Ob bei USB oder dem internen Controller ist schwer zu sagen.

[halo44]

@rendegast
Ich habe inzwischen den long-Test auch mit dem zweiten USB-Anschluss durchgeführt. Auch dieser lief fehlerfrei.

Von einem kompletten Daten-zerstörenden Test möchte ich vorerst keinen Gebrauch machen. Bei Bedarf kann ich ja einen der badblocks-Test durchführen.

Vielen Dank für Deine hilfreichen Hinweise.

@ChoMar
Danke für den Hinweis auf den UDMA_CRC_Error_Count. Ich nehme an, daß der Zähler von 3 sich auf die später im Log aufgeführten 3 Errors bezieht.

Gruss H.