staging.inyokaproject.org

Hans9876543210 schrieb:

grep smartd /var/log/syslog 

Das ist eindeutig der bessere Befehl.

Geändert 👍

Hallo,

und weiter einen "useless use of cat" eliminiert ☺

Gruß, noisefloor

Hallo,

ich würde gerne den Abschnitt wie folgt anpassen:

Alt:

Alternativ nimmt dieser Befehl in einem Terminal eingegeben die obige Änderung vor:

sed -i "/^SRCEXPR/{s#=.*#='https://sourceforge.net/p/smartmontools/code/HEAD/tree/\$location/smartmontools/drivedb.h?format=raw'#}" $(which update-smart-drivedb)

Neu:

Alternativ nimmt dieser Befehl in einem Terminal eingegeben die obige Änderung vor:

sed -i "/^SRCEXPR/{s#=.*#='https://sourceforge.net/p/smartmontools/code/HEAD/tree/\$location/smartmontools/drivedb.h?format=raw'#}" $(which update-smart-drivedb)

Ab Ubuntu 16.04 ist der Aufruf von update-smart-drivedb nicht mehr möglich, da das entsprechende Programm aus dem Paket smartmontools aufgrund von Sicherheitsbedenken herausgenommen wurde. Eine aktualisierte Datenbank kann jedoch manuell vorgenommen werden. Über smartmontools ist die Datenbank herunterladbar und muss lediglich ins Verzeichnis /var/lib/smartmontools/drivedb/ abgelegt werden.

Hallo,

ich sehe gerade keinen Unterschied zwischen den Befehlen...

Gruß, noisefloor

Oh, der Befehl bzw. der 1. Absatz war nur als Orientierung gedacht. Der zweite Absatz - Ab Ubuntu 16.04 ... - wäre neu.

Edit:

Habs aktualisiert.

Hans9876543210 schrieb:

Hallo,

ich würde gerne den Abschnitt wie folgt anpassen:

Ab Ubuntu 16.04 ist der Aufruf von update-smart-drivedb nicht mehr möglich, da das entsprechende Programm aus dem Paket smartmontools aufgrund von Sicherheitsbedenken herausgenommen wurde. Eine aktualisierte Datenbank kann jedoch manuell vorgenommen werden. Über smartmontools ist die Datenbank herunterladbar und muss lediglich ins Verzeichnis /var/lib/smartmontools/drivedb/ abgelegt werden.

👍 @Hans9876543210 Hab das gerade vermisst und dann hier gefunden, warum es nicht geht - mit Ubuntu 17.04

//edit: hast Du vll noch nen funktionierenden wget / curl - Befehl dafür? Finde das raw-File nicht, sondern nur die Oberfläche des Repos

// 😳 bin wohl müde. Wer lesen kann ist klar im Vorteil 😲 Gute Nacht...

Hallo,

im Abschnitt Abfrage der Attribute steht als Erläuterung u.a. Folgendes:

Zu Beachten ist also, dass das Unterschreiten der Grenzwerte ein Gefahrenzeichen darstellt, nicht das Überschreiten. Im Beispiel ist alles in Ordnung, da die Parameterwerte alle über den jeweiligen Grenzwerten liegen. Kritisch sind Fehler bei den mit Pre-fail bezeichneten Attributen, da hier tatsächlich ein Versagen innerhalb kürzester Zeit droht! In diesem Fall empfiehlt sich der sofortige Austausch des Laufwerks. Interpretationshilfe zur Tabelle: Solange unter der Spalte WHEN_FAILED keine Fehler vermerkt sind, ist das Laufwerk noch in Ordnung.

Diese Erläuterung (genau genommen dem letzten Satz) ist aber irreführend, denn es fehlt IMHO der explizite Hinweis (evtl. auch als Box) auf Sektorfehler!

Um Sektorfehler geht es in drei bzw. vier Zeilen der Attribute-Tabelle, nämlich in denen mit den IDs 5, 196, 197 und evtl. auch 198. Außerdem ist der ATA Error Count wichtig. Siehe dazu bitte auch den folgenden Auszug aus diesem Post von Benno-007, auf den ich vorhin gestoßen bin:

(...)

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   062    Pre-fail  Always       -       65536
  2 Throughput_Performance  0x0005   100   100   040    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0007   206   206   033    Pre-fail  Always       -       1
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       1290
  5 Reallocated_Sector_Ct   0x0033   095   095   005    Pre-fail  Always       -       276
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   100   100   040    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0012   081   081   000    Old_age   Always       -       8434
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       1228
191 G-Sense_Error_Rate      0x000a   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       35258395
193 Load_Cycle_Count        0x0012   099   099   000    Old_age   Always       -       13672
194 Temperature_Celsius     0x0002   203   203   000    Old_age   Always       -       27 (Min/Max 11/51)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       313
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       390
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0
223 Load_Retry_Count        0x000a   100   100   000    Old_age   Always       -       0

...

SMART Error Log Version: 1
ATA Error Count: 1705 (device log contains only the most recent five errors)

Die Platte selber hat je ca. 300 Fehler in allen drei Sektorfehlerspalten. Die ist also weniger als scheinlebendig, mehr so quasitot. Beispielsweise kann der Kopf gecrasht sein, dadurch blättern Magnetschichten ab. Das wird dann wie ein Flächenbrand mit jeder Umdrehung immer schlimmer. Bis die Platte vielleicht sogar steckenbleibt oder ab und zu ausgeht (hab ich bei einer externen erlebt, welche laufend nur ca. 20 cm tief auf den Tisch fiel).

Das hat also nix mehr mit vereinzelten 2-3 Fehlern zu tun, die über Jahre nicht mehr werden. Selbst 30 oder 100 Fehler wären schon fatal, du hast jedoch 1000 und es werden mit Sicherheit immer mehr. Das ist das eigentliche Problem, nicht die bereits vorhandenen Fehler: Durch die krassen Ursachen werden es mehr Fehler, du kannst den Verfall nicht mehr stoppen. Kannst du ja gern testen, nach einem weiteren Test in paar Stunden oder gar Tagen, falls die Platte da noch einen Mucks von sich gibt.

Grüße, Benno

Der Hinweis auf die mögliche (bzw. wahrscheinliche?) Ausbreitung von Sektorfehlern wäre IMHO auch nicht schlecht.

Oder hat sich mein Anliegen evtl. nicht bereits durch die im Artikel befindlichen Links auf die beiden Links erledigt?

Siehe auch:

• etwas abgekürzte Erklärung der S.M.A.R.T.-Werte

• ausführliche Erklärung der S.M.A.R.T.-Werte

IMHO ist mir das aber zu generell; es sollten explizit die drei bzw. vier Sektorfehlerzeilen plus der ATA Error Count erwähnt werden:

Besonders wichtig zur Beurteilung des Festplattenzustandes sind auch die Raw-Werte der Attribute 5 Reallocated_Sector_Ct, 196 Reallocated_Event_Count, 197 Current_Pending_Sector und 198 Offline_Uncorrectable, da es in ihnen um Sektorferhler geht. Deren Anzahl kann sich nämlich, sofern erst einmal überhaupt vorhanden, in relativ kurzer Zeit wie ein "Flächenbrand" ausbreiten und dann zum "Tod" der Festplatte führen. Wichtig ist außerdem der ATA Error Count.

Den vorstehenden Text dann noch abschließen, etwa mit "Also die Festplatte sicherheitshalber früher als später austauschen, vorher aber noch eine Datensicherung (bzw. Datenrettung) durchführen!"?

Hallo,

ich verstehe (wieder mal) deine Frage nicht wirklich... Was willst du wo genau ändern?

Gruß, noisefloor

http://smartmontools.sourceforge.net/ leitet auf https://www.smartmontools.org/ weiter. Link aktualisieren? http://gsmartcontrol.berlios.de/home/index.php/en/Downloads tot. Kann das raus? http://www.linux-user.de/ausgabe/2004/10/056-smartmontools leitet auf eine Übersichtsseite weiter.

Also der Befehl scheint es unter Kubuntu 16.04 LTS und Ubuntu-Mate 18.04 LTS nicht zu geben:

sudo update-smart-drivedb 

Im smartmontools Paket ist der gemäß Ausgabe von

dpkg -L smartmontools | grep update

auch nicht enthalten.

Es gibt lediglich einen man page Eintrag:

usr/share/man/man8/update-smart-drivedb.8.gz

Das Skript ist in /usr/sbin aber nicht zu finden. Den Eintrag im Artikel sollte man daher vielleicht anpassen.

Eventuell hat das mal unter 14.04 oder älter funktioniert.

EDIT: Okay, vielleicht hätte ich den Abschnitt bis nach ganz unten lesen sollen. Da steht, das es den Befehl in 16.04 aus Sicherheitsbedenken nicht mehr gibt.

Eventuell sollte man den Artikel etwas umbauen, denn < 16.04 wird sowieso nicht mehr supported.

Hallo,

Eventuell sollte man den Artikel etwas umbauen, denn < 16.04 wird sowieso nicht mehr supported.

Doch, doch - 14.04 LTS hat noch Support. Da das EOL aber in Sicht ist, kannst du den Artikel jetzt schon gerne so aktualisieren, dass er "nur" für 16.04 und neuer gilt.

Wenn Bedarf an einer Baustelle ist → bitte hier nochmal kurz melden.

Gruß, noisefloor

Ich habe mir mal die changelog der neuen Version 7.0 von smartmontools durchgelesen, da steht folgendes drin:

27	- update-smart-drivedb: New option '-u github'.
28	- update-smart-drivedb: New signing key.

https://www.smartmontools.org/browser/tags/RELEASE_7_0/smartmontools/NEWS

Die scheinen jetzt eine Signaturprüfung eingebaut zu haben, weswegen ich mir vorstellen könnte, dass dieses Skript wieder in das Paket zurück kommt.

Insofern würde ich vorschlagen abzuwarten, was man bei Debian Sid (unstable) und Testing daraus macht, schließlich bezieht Ubuntu von Debian die ganzen Pakete.

Momentan ist Version 7 aber noch nicht in Debian SID enthalten. https://tracker.debian.org/pkg/smartmontools

Wer die Debian Mailingliste abonniert hat, der kann die Leute ja dort auf diese Änderung hinweisen, das es jetzt für dieses Update Skript eine kryptografische Signatur gibt. Das wäre eventuell auch deswegen schon sinnvoll, weil es in Version 6.6 schon GnuPG signierte drivedb Dateien gab, wie die changelog auf der gleichen oben verlinkten Seite aufzeigt (einfach die Seite nach dem Stichwort "update" durchsuchen).

EDIT: Wegen 14.04 LTS hast du natürlich recht.

Was nochmal die Signatur betrifft. Die 6.6 war zwar noch nicht in Debian stable, da das früher rauskam, aber Testing wird die 6.6 schon haben. Da aber Ubuntu 18.04 die 6.6 schon hat und das da noch nicht dabei ist, schätze ich mal, dass man das bei Debian übersehen hat.

Ich denke man sollte den Eingangssatz:

Magnetische Massenspeichergeräte...

abändern, in Bezug auf Magnetisch, da ja mittlerweile SSD das große Thema sind. SSD sind zwar nicht so anfällig, aber SMART wirds weiter geben.

Ich weiß nur gerade nicht wie man den Satz oder den Abschnitt umformuliert, vllt. habt ihr eine Idee?

Edit: Sehe aber, es gibt einen Abschnitt SSD, dann vergesst was ich gepostet habe.

@Cordess:

Im wiki von Thomas Krenn ist die Problemlösung für das Aktualisieren der Datenbank gut beschrieben:

https://www.thomas-krenn.com/de/wiki/Smartmontools_Drive_Database_aktualisieren

Ich selbst habe für mich die Datenbank gemäß dieser Anleitung unter Ubuntu 18.04.3 aktualisiert: Das funktioniert alles.

Der vermisste wget-Befehl ist in der Anleitung vorhanden.

Es wäre sehr sinnvoll, den entsprechenden Wiki-Passus in https://wiki.ubuntuusers.de/Festplattenstatus/ aufzunehmen...

Greetz Bernhard