☰

Aktualisieren

tag-icon • tag-icon 18.04 grub2 fsck
Aktualisieren

Ich hatte Festplattenprobleme unter Ubuntu 18.04, wobei das System meine Root-Partition (/dev/sda4) aufgrund von Fehlern zufällig als schreibgeschützt neu mountet.

dmesg|grep 'I/O error'zeigt offensichtliche Probleme mit sda4. Ich habe im Moment nicht die genaue Ausgabe, da die Box erfolgreich neugestartet wurde und im Moment keine Probleme hat.

Mein Plan war, eine Dateisystemprüfung des Dateisystems durchzuführen. Ich folgtediese Antwortsowiedieses Tutorialsorgfältig. Im letzten Tutorial habe ich den Abschnitt mit dem Titel verwendet: "So erzwingen Sie, dass fsck nach einem Systemneustart unter Linux bei Verwendung von systemd das Dateisystem überprüft"

Nach dem Neustart wird das Dateisystem jedoch NICHT überprüft, wie die Ausgabe dieses Befehls zeigt:

tune2fs -l /dev/sda4 | grep checked             
Last checked:             Sat Nov 21 15:36:56 2020

Ich habe diese Variationen der GRUB CMDLINE ausprobiert, jedoch ohne Erfolg:

GRUB_CMDLINE_LINUX_DEFAULT="maybe-ubiquity fsck.mode=force"

Und

GRUB_CMDLINE_LINUX_DEFAULT="maybe-ubiquity fsck.mode=force fsck.repair=yes"

Und ja, ich bin gelaufen update-grub. Was übersehe ich?

Ausgabe von smartctl -a /dev/sda:

Device Model:     Samsung SSD 860 EVO 250GB
Serial Number:    S59WNG0MA22770K
LU WWN Device Id: 5 002538 e70265a2a
Firmware Version: RVT03B6Q
User Capacity:    250,059,350,016 bytes [250 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   Unknown(0x09fc), ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Wed May  3 11:35:14 2023 MST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever 
                                        been run.
Total time to complete Offline 
data collection:                (    0) seconds.
Offline data collection
capabilities:                    (0x53) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        No Offline surface scan supported.
                                        Self-test supported.
                                        No Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine 
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        (  85) minutes.
SCT capabilities:              (0x003d) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   038   038   010    Pre-fail  Always       -       311
  9 Power_On_Hours          0x0032   095   095   000    Old_age   Always       -       21420
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       14
177 Wear_Leveling_Count     0x0013   001   001   000    Pre-fail  Always       -       2041
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   038   038   010    Pre-fail  Always       -       311
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0032   067   065   000    Old_age   Always       -       33
195 Hardware_ECC_Recovered  0x001a   200   200   000    Old_age   Always       -       0
199 UDMA_CRC_Error_Count    0x003e   100   100   000    Old_age   Always       -       0
235 Unknown_Attribute       0x0012   099   099   000    Old_age   Always       -       10
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       166281511800

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
  256        0    65535  Read_scanning was never started
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

AKTUALISIEREN:

Der Server ist heute Morgen erneut abgestürzt (er ist noch aktiv, aber /schreibgeschützt gemountet) und Folgendes sehe ich in dmesg:

dmesg |grep sda

[70547.166349] sd 0:0:0:0: [sda] tag#13 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[70547.166354] sd 0:0:0:0: [sda] tag#13 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00
[70948.441912] sd 0:0:0:0: [sda] tag#15 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[70948.441918] sd 0:0:0:0: [sda] tag#15 CDB: Read(10) 28 00 1a cb 1c 00 00 00 08 00
[70948.441922] print_req_error: I/O error, dev sda, sector 449518592
[70948.442312] sd 0:0:0:0: [sda] tag#16 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[70948.442315] sd 0:0:0:0: [sda] tag#16 CDB: Read(10) 28 00 1a cb 1c 00 00 00 08 00
[70948.442316] print_req_error: I/O error, dev sda, sector 449518592
[70948.442955] sd 0:0:0:0: [sda] tag#17 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[70948.442960] sd 0:0:0:0: [sda] tag#17 CDB: Read(10) 28 00 0e 0b 03 08 00 00 20 00
[70948.442962] print_req_error: I/O error, dev sda, sector 235602696
[70948.443389] sd 0:0:0:0: [sda] tag#18 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[70948.443393] sd 0:0:0:0: [sda] tag#18 CDB: Read(10) 28 00 0e 0b 03 08 00 00 08 00
[70948.443396] print_req_error: I/O error, dev sda, sector 235602696
[72347.211525] sd 0:0:0:0: [sda] tag#19 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[72347.211531] sd 0:0:0:0: [sda] tag#19 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00
[74147.255746] sd 0:0:0:0: [sda] tag#21 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[74147.255752] sd 0:0:0:0: [sda] tag#21 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00
[75947.299631] sd 0:0:0:0: [sda] tag#23 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[75947.299637] sd 0:0:0:0: [sda] tag#23 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00
[77747.345291] sd 0:0:0:0: [sda] tag#25 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[77747.345297] sd 0:0:0:0: [sda] tag#25 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00
[79547.389376] sd 0:0:0:0: [sda] tag#27 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[79547.389382] sd 0:0:0:0: [sda] tag#27 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00
[81347.432593] sd 0:0:0:0: [sda] tag#29 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[81347.432598] sd 0:0:0:0: [sda] tag#29 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00

Mir ist klar, dass das Laufwerk ausgetauscht werden muss, aber mein Ziel besteht lediglich darin, fsckdie Root-Partition auszuführen.

Antwort1

Ich weiß nicht, wie ich das fsck mit der von Ihnen versuchten Lösung erzwingen kann, aber ich kann eine alternative Lösung vorschlagen:

Beschränken Sie tune2fsden Wert auf sehr niedrige Remounts und sehr niedrige Zeitstempel.

# To see current settings
sudo tune2fs -l /dev/sda4
# To alter it
sudo tune2fs -c 1 -i 1d /dev/sda4

Dadurch wird die Prüfung bei jeder erneuten Bereitstellung oder jeden Tag seit der letzten Prüfung erzwungen, je nachdem, was früher eintritt.

Überprüfen Sie SMART

Wie andere bereits gesagt haben, ist dies nur ein Pflaster für Hardwareprobleme. Manchmal ist die Festplatte kaputt, manchmal liegt ein anderes Hardwareproblem vor (führen Sie einen Memtest durch), manchmal ist es nur ein loses SATA-Kabel (ziehen Sie es an beiden Enden ab und stecken Sie es erneut ein. Wenn das das Problem nicht behebt, versuchen Sie es mit einem anderen Kabel).

Vorsicht, im schlimmsten Fall funktioniert das Netzteil nicht richtig und beschädigt die restliche Hardware (in einem solchen Fall behebt der Austausch der Festplatte das Problem nur vorübergehend, da die neue Festplatte mit der Zeit durch das Netzteil beschädigt wird). Überprüfen Sie, ob die Spannungen im akzeptablen Bereich liegen.

Die Ausgabe von smart posten:

sudo smartctl -a /dev/sda

Kann bei der Diagnose helfen, was möglicherweise los ist.

Aktualisieren

Ich weiß auch nicht, warum Sie das fsck nicht über tune2fs ausführen können.

Aber ich habe mir Ihr SMART angesehen. Demnach altert Ihre Festplatte, scheint aber intakt zu sein.

Das Problem liegt möglicherweise woanders, beispielsweise beim SATA-Kabel.

Wenn Sie das fsck nicht zum Laufen bringen, kann ich Ihnen nur empfehlen, von einem Live-USB zu booten und den Befehl manuell auszuführen.

Aktualisierung 2

OK, Sie haben die dmseg-Nachrichten gepostet.Wir haben widersprüchliche Informationen von SMART & OS, also werde ich es ausführlich schreiben.

Schlechte Blöcke

SMART sagt, dass Ihre Laufwerke fehlerhafte Blöcke haben. Das ist bei SSDs normal, wenn sie alt werden, und das Laufwerk wird die Daten in Ersatzblöcke umverteilen. Wenn keine Ersatzblöcke mehr vorhanden sind, muss das Laufwerk ausgetauscht werden.

SMART sagt, die Anzahl der fehlerhaften Blöcke liege im „normalen“ Bereich: Die wichtigsten hier zu sehenden Attribute sind Reallocated_Sector_Ctund Runtime_Bad_Block.

Es heißt, es habe 311 fehlerhafte Blöcke erkannt und 311 davon in den Ersatzblock umverteilt. Das ist gut. Wenn es 311 fehlerhafte Blöcke, aber nur 310 Umverteiltungen gegeben hätte, wären die Daten in einem der Blöcke verloren gegangen.

Wichtig ist der „normalisierte“ Wert (038). Damit gibt der Hersteller an, was er als normal ansieht.

Ein Wert, bei dem 100 perfekt und 0 wirklich schlecht bedeutet. Im Moment liegt er bei 38, was bedeutet „das wird schlimm“; aber der Hersteller sagt, es ist ok, solange der Wert über 010 (dem SCHWELLENPUNKT) liegt.

Hier haben wir unsere ersten widersprüchlichen Informationen: Used_Rsvd_Blk_Cnt_TotEs heißt, das Reservat sei überhaupt nicht angetastet worden, obwohl ich schlechte Blöcke habe. Das passt nicht zusammen.

Es würde mich aber nicht überraschen, wenn die Firmware diesen Wert trotz Meldung einfach nicht verfolgt, daher ignorieren wir dies vorerst.

Verschleißnivellierung

Dies ist das problematischste zu lesende Attribut. Wear_Leveling_Countsagt, es ist 001. Normalerweise bedeutet ein Wert von 1, dass Ihr Laufwerk defekt ist und so schnell wie möglich ersetzt werden muss.

Das bedeutet, dass keine freien Blöcke mehr vorhanden sind. Es gab jedoch Firmware-Fehler, bei denen dieses Attribut falsch gemeldet wurde, und ein Wert von 1 bedeutet, dass das Laufwerk zu 99 % funktionsfähig ist.

Verwendung einerTBW-RechnerIch habe die Anzahl der geschriebenen LBAs + 512 Sektorengröße eingegeben und festgestellt, dass Ihr Laufwerk 77,43 TiB geschrieben hat. Laut Google sollte Ihr Modell 150 TBW haben, alsosollennoch lebensfähig sein.

Ich fürchte, die beste Lösung ist, eine Windows-Box hochzufahren und auszuführenCrystalDiskInfodas diese Firmware-Fehler (mithilfe einer internen Datenbank) berücksichtigt und Ihnen eine sehr genaue Zustandsbewertung liefert.

Angesichts dessen, was Ihr Smart sagt, SMART overall-health self-assessment test result: PASSEDneige ich dazu anzunehmen, dass es 99 % und nicht 1 % sagen möchte.

Aber wenn ich falsch liege, können wir hier aufhören. Die Festplatte muss ausgetauscht werden.

Kabelprobleme / Motherboardprobleme

Die Fehler in Linux‘ dmesg bedeuten im Wesentlichen, dass beim Versuch, einen Sektor zu lesen, fehlerhafte Daten aufgetreten sind.

Der Kernel sagt sogar, dass er versucht hat, Sektor 235602696 zweimal zu lesen und unterschiedliche Daten erhalten hat:

  • 28 00 0e 0b 03 08 00 002000
  • 28 00 0e 0b 03 08 00 000800.

Wenn die Festplatte keine Fehler anzeigt, das Betriebssystem aber Fehler meldet, wurden die Daten während der Übertragung beschädigt. Normalerweise deutet dies auf Folgendes hin:

  • SATA-Kabel ist locker eingesteckt
  • Das SATA-Kabel ist beschädigt
  • Das Stromkabel ist locker eingesteckt
  • Das Stromkabel ist beschädigt
  • Motherboard-Busfehler
  • Netzteilfehler
  • RAM-Fehler

Aber hier haben wirunsere zweite Quelle widersprüchlicher Informationen: UDMA_CRC_Error_Countist 0.

Dies bedeutet, dass die Festplatte nie einen einzigen Fehler erkannt hat, der durch ein fehlerhaftes/loses Kabel oder einen fehlerhaften Motherboard-Bus verursacht wurde.

Das ist einfach sehr unwahrscheinlich. SMART sagt, dass die Festplatte in Ordnung ist und die vom Betriebssystem auf der Festplatte eingehenden Befehle nie durch eine fehlerhafte Verkabelung beschädigt werden. Trotzdem hat das Betriebssystem denselben Sektor zweimal gelesen und ein anderes Byte erhalten.

Das Einzige, was mir dazu einfällt, ist ein defekter RAM.Oder ein äußerst unwahrscheinliches Kabelproblem, bei dem die auf die Festplatte eingehenden Daten nicht beschädigt werden, die ausgehenden Daten jedoch beschädigt werden.

Vorgehensweise

Mein Bauchgefühl sagt mir, dass die Festplatte defekt ist. Aber:

  1. Sichern Sie alle Daten auf einer anderen Festplatte. Bei einem LiveUSB-Lauf (und einem ausreichend großen externen USB-Laufwerk):
sudo apt install zstd

# To backup
sudo zstd -16v < /dev/sda > /media/external_disk/backup_file.zst

# To restore (don't do that on step 1, see step 5)
sudo zstdcat -v /media/external_disk/backup_file.zst > /dev/sda
  1. Sichern Sie die Daten erneut, diesmal jedoch nur mit einer normalen Kopie der Dateien (wenn die Festplatte kaputt geht, ist eine Wiederherstellung mit einer einfachen Sicherung viel einfacher als der Versuch, ein komprimiertes zstd-Image einer Festplatte zu mounten und die Dateien von diesem zu lesen).
  2. Starten Sie neu und führen Sie einen Memtest aus, um RAM-Fehler zu beseitigen
  3. Herunterfahren, Gehäuse öffnen und SATA- und Stromkabel (zum Laufwerk) abziehen und wieder einstecken. Überprüfen Sie, ob sie nicht beschädigt sind. Eventuell ersetzen.
  4. Booten Sie das LiveUSB-Laufwerk erneut und führen Sie eine sichere Löschung der Festplatte durch. Wenn mit Ihrem Laufwerk etwas nicht stimmt, wird es dadurch möglicherweise wieder in einen funktionsfähigen Zustand zurückgesetzt (oder es wird der letzte ausgeführte Befehl ausgeführt, wenn die Festplatte nicht mehr zu retten ist). Dies sollte mehrere Minuten dauern:
sudo blkdiscard -s /dev/sda
  1. Wenn bisher alles gut gelaufen ist, stellen Sie Ihr Backup mit dem sudo zstdcatBefehl in Schritt 1 wieder her.

Wenn mit der Festplatte weiterhin Probleme auftreten und der Memtest erfolgreich war, würde ich persönlich die Festplatte einfach als fehlerhaft einstufen.

Wir können nicht ignorieren, dass ein Wert von 0,38 Reallocated_Sector_Ctbedeutet, dass die Dinge schlimmer werden, auch wenn der Hersteller sagt, dass es noch nicht „so“ schlimm ist.

Ah! Wichtig: Wenn Sie die Festplatte irgendwann länger als 3 Monate ausgeschaltet gelassen haben, ist dieses Szenario durchaus möglich. Entgegen der landläufigen Meinung können NAND-Zellen ihren Speicher verlieren, wenn sie zu lange ohne Strom bleiben („zu lange“ kann zwischen 7 Tagen und 7 Jahren liegen; am häufigsten sind es jedoch 3 Monate). Besonders, wenn sie alt sind.

Wenn Ihnen dies passiert ist, führen Sie einfach die oben genannten Schritte aus: Sichern Sie die Daten, löschen Sie die Festplatte sicher und stellen Sie die Sicherung wieder her.

Viel Glück.

verwandte Informationen