Sie sind nicht angemeldet.

[erledigt] Xubuntu verschlampt seine Partitionen | völlig verrückter Fehler

Lieber Besucher, herzlich willkommen bei: Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

  • 1
  • 2

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

1

17.12.2016, 16:28

Xubuntu verschlampt seine Partitionen | völlig verrückter Fehler

Seit 3 Tagen plagt mich ein Fehler der so verrückt ist, daß ich zur Erklärung ziemlich weit ausholen muß und gar nicht weiß, wo ich ihn einordnen soll.

Mein Produktivsystem (Xubuntu 16.04) läuft auf einem Rechner mit 2 Festplatten und besteht aus 3 Partitionen: /, /var und /home - alle ext4 - zusätzlich eine Sicherungspartition mit btrfs, welche von Timeshift benützt wird. Die ersten 2 Partitionen sind auf /dev/sda, die anderen beiden auf /dev/sdb. Das System lief monatelang stabil und wurde regelmäßig aktualisiert.

Im Lauf der Zeit kamen 2 weitere Lernsysteme dazu, die nur je eine einzige Partition auf /dev/sda haben, allerdings ebenfalls mittels Timeshift auf /dev/sdb3 gesichert werden: Manjaro und Mint 18. Auch das lief mindestens 2 Monate ohne Auffälligkeiten und beide Nebensysteme waren auf dem aktuellen Stand. Jüngst geschah es jedoch, daß ich durch einen Bedienungsfehler ein Ereignis herbeigeführt hatte, welches in seiner Wirkung einem Stromausfall gleichkam. Scheinbar war alles gut gegangen, denn nach dem Neustart lief das System weiter. Einige Zeit später bemerkte ich zu meiner Verblüffung, daß ein großer Dateikopiervorgang mit einer Fehlermeldung der Art "2 Dateien (Dateifragmente?) können nicht zusammengeführt werden" abrach und gleichzeitig beobachtete ich in einem zufällig offenen Fenster des Home-Verzeichnisses, wie dieses sich zügig leerte. Völlig ungefragt wurde dann das Sicherungsverzeichnis von Timeshift eingehängt, obwohl jenes nicht lief und nicht von mir gestartet worden war.

Umfangreichere Programme konnten nicht mehr gestartet werden, weil sie ihre Konfiguration in /home nicht mehr fanden - dieses schien ja leer zu sein. Die parallel installierten Systeme benützte ich als Rettungssyteme und sicherte was ging von /dev/sdb5 (darauf liegt /home), denn die Partition war durchaus nicht geleert, sondern nur "entführt" worden. Nach langen erfolglosen Mühen entschloß ich mich am nächsten Tag zu einer Neuinstallation von Xubuntu, der Fehler stellte sich im Lauf der Kopiervorgänge beim Rücksichern jedoch wieder ein. Am übernächsten Tag installierte ich erneut neu und machte auch alle Sicherungen auf /dev/sdb3 platt. Die Partition erschien mir verdächtig, weil sie bei jedem Auftreten des Fehlers automatisch eingehängt wird. Wieder ging alles gut; ich glaubte schon an den Erfolg und installierte viele GB an verlorenen Programmen nach. Zwischendurch machte ich Snapshots mit Timeshift und auch hierbei gab es keine Auffälligkeiten. Die kamen erst bei den anschließenden Kopierorgien.

Weil der Fehler so "unbeschreiblich" ist verwende ich folgendes umgangssprachliche Bild zur Charakterisierung:
Vergleicht man /home mit einer Badewanne und das Wasser darin mit den Nutz- und Konfigurationsdaten darin, so stellt sich der (unbekannte) Fehler so dar, als wenn jemand den Stöpsel ziehen würde. Die Wanne läuft leer und es ist kein Wasser mehr sichtbar (bzw. keine Daten mehr auffindbar).

Zum Einhängen der Sicherungspartition sehe ich leider keine umgangsprachliche Parallele, denn offenbar wird nichts wegkopiert, sondern alles bleibt wo es ist. Es wird nur der Blick auf die Wirklichkeit durch ein Trugbild ersetzt. Der Fehler ist reproduzierbar, jedoch nicht mit einer einzelnen bestimmten und definierten Aktion. Ich habe nur festgestellt, daß das Kopieren größerer Datenmengen ihn auslöst. Es geht so um die 10 GB los. Bei einer Einzeldatei dieser Größe tritt er fast sicher auf; bei vielen Dateien, die zusammen diese Größe übersteigen, bin ich mir nicht sicher. Vielleicht sollte ich noch präzisieren, daß die Kopieraktionen alle mit der graphischen Oberfläche (XfCE) gemacht worden waren, weil mir das Einhängen der externen Partitionen mit dem Midnight Commander zu umständlich war (das sollte ich wirklich noch überprüfen -- oder noch einfacher in der Shell ein Verzeichnis mit einigen GB Inhalt kopieren).
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 8 mal editiert, zuletzt von »ebbi97a« (19.02.2017, 07:02) aus folgendem Grund: Verschoben aus "Desktop- und Arbeitsumgebungen » Xfce-Forum".

wowi

Ubuntu-Forum-Team

  • »wowi« ist männlich

Beiträge: 4 264

Registrierungsdatum: 03.05.2007

Derivat: Xubuntu

Architektur: 64-Bit PC

Desktop: XFCE

  • Nachricht senden

2

17.12.2016, 22:32

Hi ebbi97a,

ich fürchte, hier ist eine Ferndiagnose sehr schwierig. Aber vielleicht helfen Dir meine ersten Gedanken doch weiter:
  • Ist die Sicherungsplatte schon relativ voll, ev. nur noch der Platz frei, der mit einer großen zu kopierenden Datei überschritten wäre?
  • timeshift scheint ja leider noch nicht so perfekt ausgereift zu sein. Vielleicht kommt es gerade bei Rücksicherungen mit den Partitionen durcheinander, weil Du ja inzwischen noch weitere Systeme angelegt hast?
  • Könnte nicht timeshift immer wieder die Partitionen "unerklärlicherweise" mounten?
Greetz
wowi

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

3

18.12.2016, 07:27

Hallo Wowi,
danke für deine Antwort. Leider glaube ich, daß ich deine 3 Möglichkeiten ausschließen kann, wenn auch nicht mit 100%iger Sicherheit. Obwohl die gesamte Hardware relativ neu ist (jünger als 2 Jahre und die Platte auf /dev/sdb jünger als ein halbes Jahr) kann ich auch einen Hardwarefehler nicht ausschließen - nur, wie findet man sowas raus?

  • Die Platte mit der Sicherung ist 4 TB groß, wowon die /home-Partition rund 1 TB innehat, dann kommen einige GB /swap und der Rest ist Sicherung, wovon 2,8 TB frei sind. Platzmangel scheidet also aus.
  • Könnte schon sein, daß Timeshift eine Macke hat - deswegen habe ich es mitsamt seiner Partition bei der 2. Neuinstalltion ebenfalls platt gemacht. Beim Neuinstallieren habe ich immer sämtlich betroffenen Partitionen formatiert - also nicht nur über möglicherweise fehlerhaftes Altes drübergebügelt. Auch ist die Möglichkeit, mehrere Systeme parallel - aber dennoch getrennt - zu sichern, sehr neu. Ich selbst habe sie quasi aus Versehen beim Entwickler angeregt und er ist sofort darauf eingestiegen. An einem Wochenende hatte er alles fertig. Den ultimativen Notfall hatte ich noch nie: ich habe immer nur gesichert, aber nie zurückgespielt.
    Selbst wenn das alles zweifelhaft sein sollte bleibt immer noch die Gretchenfrage: Wer startet Timeshift im Fehlerfall? Auf allen Systemen habe ich nämlich sämtliche Automatiken abgestellt. Sicherungen werden ausschließlich auf meinen ausdrücklichen Wunsch angefertigt; dazu muß ich Timeshift händisch starten. Wenn der Fehler auftritt passiert es aber aus dem Nichts heraus, daß /home sich "ablöst" und und die Sicherungspartition plötzlich das sudo-Paßwort haben will, um sich einhängen zu dürfen.
  • Ziemlich sicher konnte ich den Fehler durch kopieren großer Datenmengen (ab 10 GB auf einen Rutsch) auslösen: das System kopiert vor sich hin bis es auf einmal sagt (nicht wörtlich!), daß es nicht weiterschreiben kann, weil das schon Geschriebene nicht mehr da sei.
    Jetzt habe ich gerade mit fslint herumgespielt in der Hoffnung, damit in die "dunklen Ecken" des Dateisystems leuchten zu können; es ist aber nichts passiert.
  • Wer kann eine Partition sonst noch einhängen? Könnte irgendeine Bedingung das Starten von Timeshift auslösen? Wenn das so wäre, müßte auch die Benutzerschnittstelle von Timeshift sichtbar werden (wird sie aber nicht). Kann es an fehlerhaften Hardlinks liegen? Überleben solche das Formatieren einer Partition?
    Rätsel über Rätsel!
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von »ebbi97a« (18.12.2016, 07:38)

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

4

18.12.2016, 09:40

Nachtrag: Kopieren generell verwirrt das System; es hängt nicht an xfce.

Zitat von »ebbi97a«

Der Fehler ist reproduzierbar, jedoch nicht mit einer einzelnen bestimmten und definierten Aktion. Ich habe nur festgestellt, daß das Kopieren größerer Datenmengen ihn auslöst. Es geht so um die 10 GB los. Bei einer Einzeldatei dieser Größe tritt er fast sicher auf; bei vielen Dateien, die zusammen diese Größe übersteigen, bin ich mir nicht sicher. Vielleicht sollte ich noch präzisieren, daß die Kopieraktionen alle mit der graphischen Oberfläche (XfCE) gemacht worden waren, weil mir das Einhängen der externen Partitionen mit dem Midnight Commander zu umständlich war (das sollte ich wirklich noch überprüfen -- oder noch einfacher in der Shell ein Verzeichnis mit einigen GB Inhalt kopieren).

Gerade habe ich versucht, mit dem Midnight Commander in einem Terminalfenster 106 GB auf einen Rutsch von einer per USB angeschlossenen Platte nach /home zu kopieren (mit sudo!). Der Fehler trat wieder auf und ich konnte ihn als Bildschirmabzug einfangen. Daher vermute ich, daß die graphische Oberfläche nicht daran schuld ist. Leider ist das nicht vollständig schlüssig, weil ich das Terminalfenster worin MC lief, unter XfCE geöffnet hatte und nicht direkt in einem Textbildschirm (dann hätte ich keinen Bildschirmabzug machen können). Ich kann mich nicht besser ausdrücken, weil ich die richtigen Begriffe nicht kenne. Mit Textfenster meine ich die virtuellen Bildschirme, derer man 6 oder 7 Stück mittels irgendwelcher Steuertasten aufmachen kann. Zumindest geht das bei meinen Debian-Systemen ganz ohne X11 und Grafik so; hier kriege ich das gar nicht fertig. Konsolen sagt man - glaube ich - zu den Dingern; nicht virtuelle Bildschirme.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »ebbi97a« (18.12.2016, 09:49)

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

  • Nachricht senden

5

18.12.2016, 17:28

Welche Platten sind eingebaut, welche per USB angeschlossen?
Wie werden sie eingehängt?
Wie sieht die fstab aus?

"Desktop- und Arbeitsumgebungen »  Xfce-Forum" ist definitiv der falsche Bereich dafür.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

6

18.12.2016, 17:42

Hallo Fredl,
du wirst wohl recht haben mit dem falschen Bereich, aber anfänglich war mir gar nichts klar und ich wüßte immer noch nicht, wohin damit. Soll ich verschieben? Kann ich das? Wie geht das?

2 Platten sind eingebaut und an SATA angeschlossen:
  1. /dev/sda ist eine 1 TB SSHD von Seagate,
  2. /dev/sdb ist eine 4 TB von Western Digital.

Eine 500GB Wechselplatte ist zeitweise über USB angeschlossen und mit NTFS formatiert; dann hängt gelegentlich noch eine ext4 formatierte 1TB-Platte an USB.

Die beiden ersten Platten werden automatisch über /etc/fstab eingebunden:

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda5 during installation
UUID=57fad0b2-4ce5-4cae-82c3-d3794f3c2887 /               ext4    errors=remount-ro 0       1
# /home was on /dev/sdb1 during installation
UUID=948157c2-855b-47b4-b084-5eca13d5861e /home           ext4    defaults        0       2
# /var was on /dev/sda6 during installation
UUID=29463195-f864-40d1-a2e9-5ef11815dce3 /var            ext4    defaults        0       2
# swap was on /dev/sdb2 during installation
UUID=a40c36ec-d0b9-4888-be30-bacb69741931 none            swap    sw              0       0
# swap was on /dev/sda1 during installation
UUID=7d097b9f-e757-4220-98b3-f8c01bc208b0 none            swap    sw              0       0
2i1800:/arc-o	/2I1800/arc-o	nfs4	rw	0	0
2i1800:/arc-p	/2I1800/arc-p	nfs4	rw	0	0
2i1800:/arc-x	/2I1800/arc-x	nfs4	rw	0	0
ich@i5tuxedo:~$

Die Partition /dev/sdb3 ist für TimeShift reserviert, mit btrfs formatiert und nicht in fstab eingetragen; sie wurde nur Timeshift bekannt gemacht und wird von diesem unter ihrer UUID verwaltet und ggf. eingehängt.

Könnte es helfen, wenn ich mit fsck für das entsprechende Dateisystem über alle Partitionen gehe? Für 2 habe ich das schon gemacht ohne einen Fehler zu finden.

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

ich@i5tuxedo:~$ sudo parted -l
Modell: ATA ST1000LM014-1EJ1 (scsi)
Festplatte  /dev/sda:  1000GB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: msdos
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Typ       Dateisystem     Flags
 1      1049kB  16,5GB  16,5GB  primary   linux-swap(v1)  boot
 2      16,5GB  1000GB  984GB   extended
 5      16,5GB  32,1GB  15,6GB  logical   ext4
 8      32,1GB  396GB   364GB   logical   ext4
 6      396GB   446GB   49,5GB  logical   ext4
 7      446GB   1000GB  554GB   logical   ext4


Modell: ATA WDC WD40EZRZ-00W (scsi)
Festplatte  /dev/sdb:  4001GB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Dateisystem     Name       Flags
 1      1049kB  929GB   929GB   ext4            HOME
 2      929GB   964GB   35,3GB  linux-swap(v1)
 3      964GB   4001GB  3037GB  btrfs           SICHERUNG


Modell: TOSHIBA STOR.E ALU 2S (scsi)
Festplatte  /dev/sdc:  500GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags: 

Nummer  Anfang  Ende   Größe  Typ      Dateisystem  Flags
 1      1049kB  500GB  500GB  primary  ntfs
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von »ebbi97a« (18.12.2016, 18:02)

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

  • Nachricht senden

7

18.12.2016, 18:13

Lass einmal einen long-test auf der WD-Platte laufen und lies dann die SMART-Daten aus. Druck dir das Protokoll auch aus, für die Reklamation, wenn die noch Gewährleistung hat. (Abspeichern in $HOME ist da keine gute Idee...)

Quellcode

 
1

sudo smartctl -t long /dev/sdb
Es steht dann dort wie lange der Test dauert (kann schon lang sein, also nicht kurz vor dem Abdrehen starten)
Sobald diese Zeit um ist:

Quellcode

 
1

sudo smartctl -a /dev/sdb | sudo tee -a /root/smart.sdb


Wieso timeshift von selbst startet, kann ich nicht beantworten. Aber du hast ja Kontakt zum Entwickler...

Ich verschiebe das Thema.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

  • Nachricht senden

8

18.12.2016, 18:20

Dann zeig bitte noch die Ausgabe von

Quellcode

 
1

blkid # evtl. mit sudo davor
Die zwei Einträge für swap stimmen offensichtlich nicht mehr.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

9

18.12.2016, 18:48

Der SMART-Langzeittest wird morgen gegen 5 Uhr fertig; paßt gut, weil ich kurz nach 6 Uhr aufstehe.

Quellcode

 
1
2
3
4
5
6
7
8
9
10

i5tuxedo:~$ sudo blkid
/dev/sda1: UUID="7d097b9f-e757-4220-98b3-f8c01bc208b0" TYPE="swap" PARTUUID="00010f0f-01"
/dev/sda5: UUID="57fad0b2-4ce5-4cae-82c3-d3794f3c2887" TYPE="ext4" PARTUUID="00010f0f-05"
/dev/sda6: UUID="29463195-f864-40d1-a2e9-5ef11815dce3" TYPE="ext4" PARTUUID="00010f0f-06"
/dev/sda7: LABEL="Mint" UUID="fc669513-df7e-42df-9df1-7cf9374d439d" TYPE="ext4" PARTUUID="00010f0f-07"
/dev/sda8: LABEL="Manjaro" UUID="ff58a175-5282-4561-93f4-2ce6f4af4ed1" TYPE="ext4" PARTUUID="00010f0f-08"
/dev/sdb1: UUID="948157c2-855b-47b4-b084-5eca13d5861e" TYPE="ext4" PARTLABEL="HOME" PARTUUID="7228d8ae-baaa-4b54-91c0-8ce50bfa0e5c"
/dev/sdb2: UUID="a40c36ec-d0b9-4888-be30-bacb69741931" TYPE="swap" PARTUUID="1098fb85-b98b-45e7-9971-62c395146239"
/dev/sdb3: UUID="e29062e9-3de1-4d73-a8e7-1ff82f96b5f9" UUID_SUB="4afcdbd2-8920-482b-9ba4-f10955b54701" TYPE="btrfs" PARTLABEL="SICHERUNG" PARTUUID="d8170afc-1ea2-48de-a13a-7fdd7b5ff583"
/dev/sdc1: LABEL="USB-500GB" UUID="37DA426C6CE73F09" TYPE="ntfs" PARTUUID="0003b880-01"

Das mit den /swap-Partitionen ist mir durchgerutscht - ?( - die wurden bei den Neuinstallationen ja auch formatiert und haben wohl den UUID gewechselt.
_______________________________
Welches System hätten's denn gern?

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

  • Nachricht senden

10

18.12.2016, 19:09

Mit solcher Dauer hätte ich nicht gerechnet, aber wenn smart das sagt, ist's ok. Mal sehen was rauskommt.

Die UUIDs wurden nicht gewechselt, du hast halt jetzt 2 swaps. Ob beide aktiv sind, sagt dir

Quellcode

 
1

cat /proc/swaps
.
Da es wahrscheinlich nur eine davon ist, könntest du die andere für was anderes nehmen. Stören tut sie so jedenfalls auch nicht.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

11

19.12.2016, 06:11

Ergebnis des SMART-Tests der letzten Nacht

Danke für's Verschieben des Themas in einen besser passenden Bereich!

Das ist das Ergebnis des SMART-Tests mit den Kommandos
  • sudo smartctl -t long /dev/sdb
  • sudo smartctl -a /dev/sdb | sudo tee -a /root/smart.sdb

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92

i5tuxedo:~$ sudo smartctl -a /dev/sdb | sudo tee -a /root/smart.sdb
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.4.0-53-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     WDC WD40EZRZ-00WN9B0
Serial Number:    WD-WCC4E4TT41J2
LU WWN Device Id: 5 0014ee 20c97724d
Firmware Version: 80.00A80
User Capacity:    4.000.787.030.016 bytes [4,00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Mon Dec 19 07:01:02 2016 WAST
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:  (0x82)	Offline data collection activity
					was completed without error.
					Auto Offline Data Collection: Enabled.
Self-test execution status:      (  33)	The self-test routine was interrupted
					by the host with a hard or soft reset.
Total time to complete Offline 
data collection: 		(53940) seconds.
Offline data collection
capabilities: 			 (0x7b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					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: 	 ( 539) minutes.
Conveyance self-test routine
recommended polling time: 	 (   5) minutes.
SCT capabilities: 	       (0x7035)	SCT Status supported.
					SCT Feature Control supported.
					SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   100   253   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   253   181   021    Pre-fail  Always       -       2025
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       224
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   098   098   000    Old_age   Always       -       1723
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       188
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       10
193 Load_Cycle_Count        0x0032   167   167   000    Old_age   Always       -       99316
194 Temperature_Celsius     0x0022   119   111   000    Old_age   Always       -       33
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Interrupted (host reset)      10%      1719         -

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
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.

Das Ergebnis habe ich gesichert; hoffentlich ist es aussagekräftig.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »ebbi97a« (19.12.2016, 06:23)

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

12

19.12.2016, 06:32

Bin wohl nicht der Einzige mit sowas

Gerade gesehen:

Zitat von »Kraeutergnom«

Seit einigen Wochen schließt sich immer häufiger und schneller die Dateiverwaltung auf meinem Rechner, wenn ich Dateien von einem Ordner in einen anderen ziehe. Ich vermute, dass die betreffenden Sektoren auf der Festplatte fehlerhaft sind.
Wie und mit welchem Programm kann ich die Festplatte auf Fehler überprüfen und mein Dateisystem reparieren?

Wieder dieses Kopierphänomen!
Scheint also umfangreicher zu werden. :( Am meisten ärgert mich, daß ich meinen Rechner voreilig platt gemacht habe und damit die Arbeit von vielen Wochen entwertet habe. ;( Muß ich im Nachhinein als unüberlegte Panikhandlung einstufen, weil ich vor dem Winterurlaub noch was reißen wollte.

Vermutlich muß die abschließende Behandlung auf Ende Januar / Anfang Februar verschoben werden, weil ich in 4 Tagen eine Autoreise nach Westafrika anfange und erst 3-6 Wochen später zurückkommen werde. Mit dem kaputten Rechner muß ich noch etliche Dokumente für die Gruppe vorbereiten und das Gepäck (Auto und mich selbst) sauber und systematisch herrichten.
_________________________________________________________________________________

Nachtrag 12:06 h
Habe gerade 2 kleine Dateien mit Thunar 1.6.10 aus dem Schreibtisch in einen Dokumentordner verschoben und Thunar ist abgestürzt - allerdings ohne anschließende Partitionshexereien. Darauf hin ging ein Fehlermeldefenster von Xubuntu auf, dem ich die Freigabe erteilte. Wenn ich unter den jüngsten Erfahrungen so zurückdenke erkenne ich, daß das die letzten Monate sehr häufig vorkam und ich es meistens nur abnickte weil es lästig war - und ich bei Stichproben keine Datenfehler bemerkte. Irgendwo ist da ein Wurm versteckt! Auch nach Installation neuer Pakete mault die Routine am Schluß oft, daß sie irgendwelche Dateirechte auf /tmp nicht hinbiegen könne. Meistens laufen die Programme aber.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 8 mal editiert, zuletzt von »ebbi97a« (19.12.2016, 13:14)

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

  • Nachricht senden

13

19.12.2016, 14:00

Ich will deine Panik nicht verstärken, zumal du gerade andere Dinge im Kopf hast.
Der Test wurde nach 90% abgebrochen wegen host reset (Rechnerneustart?)
Das Ergebnis sieht an sich nicht soo schlecht aus, bis auf:

Quellcode

 
1

1 Raw_Read_Error_Rate     0x002f   100   253   051
Der Wert scheint rapide gefallen zu sein ggü. dem bisher schlechtesten Wert. Sowas kann sich auch wieder erfangen, allerdings: Ich hatte 1x (und nie wieder) eine WD Caviar, die von einer Minute auf die andere tot war. Meine Platten werden aber täglich automatisch geprüft und auftretende Probleme per email gemeldet. Müßig zu sagen, daß bis zu dem Zeitpunkt nicht die geringste Warnung kam.
Ich kann dir somit konkret nichts zuverlässig raten, nur auf obige Fakten hinweisen. Wenn es sich finanziell und zeitmäßig ausgeht, würde ich eine neue Platte besorgen, die Daten klonen und die WD als Reserve mitlaufen lassen, bis sich ein klares Bild ergibt.
Zumindest aber den smart-daemon so konfigurieren, daß er täglich einen short- und alle drei Tage einen long-test startet und ggf. per email warnt.

P.S.: Auto-OK für lästige Meldungen ist schlechte Windows-Gewohnheit, die man unter Linux ablegen sollte. Das meldet sich vorwiegend bei wirklich wichtigen Dingen, die also Aufmerksamkeit erfordern.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

14

19.12.2016, 14:47

vorläufig mache ich Pause

Zitat von »Fredl«

Ich will deine Panik nicht verstärken, zumal du gerade andere Dinge im Kopf hast.
Der Test wurde nach 90% abgebrochen wegen host reset (Rechnerneustart?)

Tatsächlich! Abgebrochen?

Angesichts des hohen Drucks, unter dem ich diese Woche stehe, lasse ich vorläufig (bis zur Rückkehr) alle Bemühungen sein und dokumentiere nur, was sich irgendwo halbwegs gesichert noch auffinden läßt. Alles andere kann das Chaos nur noch verschlimmern; als Rentner-Opa bin ich solcher Mehrfachbelastung nicht mehr gewachsen. Generell bin ich mit der Bildervortung monatelang im Rückstand und über 20000 Bilder warten noch auf ihre Archivierung. Da hat es bei Hard- und Software auch immer wieder gebrannt und ich bin unheimlich langsam geworden.

Quellcode

 
1
2
3
4
5

i5tuxedo:~$ w
 15:56:41 up 1 day,  4:49,  2 users,  load average: 0,16, 0,11, 0,20
USER     TTY      VON              ANMELD@   UNTÄ   JCPU   PCPU WAS
xxxxxxxx tty7     :0                So11   28:49 m 27:21   0.10 s /sbin/upstart -
xxxxxxxx pts/7    :0.0             15:56    1.00 s  0.00 s  0.00 s w

Der Rechner läuft übrigens laut w-Kommando seit über 16 Stunden durch, also kein Neustart.

Zitat von »Fredl«

Ich kann dir somit konkret nichts zuverlässig raten, nur auf obige Fakten hinweisen. Wenn es sich finanziell und zeitmäßig ausgeht, würde ich eine neue Platte besorgen, die Daten klonen und die WD als Reserve mitlaufen lassen, bis sich ein klares Bild ergibt.
Zumindest aber den smart-daemon so konfigurieren, daß er täglich einen short- und alle drei Tage einen long-test startet und ggf. per email warnt.

Die neue Platte muß ich wohl ins Auge fassen, aber die smart-tests werde ich vorher noch einbauen.
_____________________________________________________________________________________

Nachtrag 15:21h:
Nachdem die Hardware der /dev/sdb in Verdach geraten ist, habe ich doch schnell noch einen weiteren Test mit einem der beiden Parallelsysteme veranstaltet, die (mit Ausnahme - vielleicht nicht ganz unwichtig - einer einzigen swap-Partition!) ausschließlich auf /dev/sda daheim sind.

Von der USB-Platte mit NTFS habe ich einen Ordner mit 42 GB in das /tmp-Verzeichnis von Mint 18 kopieren wollen. Der Ordner enthielt zigtausende von Kleinstdateien (Landkartenkacheln), Bilder mittlerer Größe und einige große (>15GB) Abbilder von VirtualBox. Schon nach etwas mehr als 10% der Datenmenge brach der Kopiervorgang im bekannten Stil mit anschließendem Partitionszauber ab. Die gesamte Mint-Partition ist nur zu 3% belegt. Die WD-Platte sehe ich damit als vorläufig entlastet an; die andere ist von Seagate.
Bildschirmabzug:
»ebbi97a« hat folgendes Bild angehängt:
  • Bildschirmfoto_2016-12-19_16-16-17.png
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von »ebbi97a« (19.12.2016, 15:37)

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

  • Nachricht senden

15

19.12.2016, 15:54

Zitat von »ebbi97a«

Tatsächlich! Abgebrochen?
Steht zumindest so da:

Quellcode

 
1
2

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Interrupted (host reset)      10%
Kann auch bedeuten, daß der Controller ausgestiegen ist oder die Platte...

Zitat von »ebbi97a«

42 GB in das /tmp-Verzeichnis von Mint 18 kopieren
/tmp ist üblicherweise heute ein tmpfs im RAM. per default wird anfangs das halbe verfügbare RAM belegt. ->

Quellcode

 
1

df -h
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

16

19.12.2016, 17:46

Versuch aus anderer Perspektive

Zitat von »Fredl«

/tmp ist üblicherweise heute ein tmpfs im RAM. per default wird anfangs das halbe verfügbare RAM belegt. ->

Mit diesen ganzen Trixereien heutzutage weiß man überhaupt nicht mehr, was real ist.

Ich konnte in der Zwischenzeit das Suchen immer noch nicht ganz lassen, aber weil das wieder ein Schuß in den Ofen war, langt es jetzt wirklich. Habe den Spieß einfach rumgedreht und die Kopierorgie von der vormals benützten Quellplatte auf die vormals benützte Zielplatte nicht von kaputten Xubuntu aus, sondern vom heilen Mint aus durchgeführt. Es war ein Ordner von zusammen 178 GB mit 222223 Dateien. Ausgeführt mit dem MidnightCommander in der Shell und mit sudo.

Bis auf eine einzige Datei, die ich mir noch genauer anschauen muß, ging alles durch. Die angemeckerte Datei konnte ich überspringen und mit dem Rest weiter machen, weil im Unterschied zu Xubuntu der Partitionzauber mit der ausgehängten Zielpartition unterblieb! Allerdings waren die Kopien nicht fehlerfrei - viele hatten nur die Größe 0. Die Zielpartition ist immer noch eingehängt und ich kann das alles anschauen.


Unter diesen Umständen hat es für mich keinen Sinn mehr, weiter zu arbeiten (außer Wegwerftätigkeiten - aber nichts dauerhaftes). Kopieren von Dateien ist eine der altehrwürdigsten und grundlegensten Funktionen in der EDV und wenn das nicht verläßlich funktioniert kann man nur noch vom Glauben abfallen. 8|

Nochwas: df -h zeigt doch nicht die Verzeichnisse? Auf diesem Rechner habe ich /tmp im Gegensatz zu meinen Debian-Servern keine eigene Partition spendiert - kann es also auch nicht sehen. ?(
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von »ebbi97a« (19.12.2016, 19:21)

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

  • Nachricht senden

17

19.12.2016, 21:09

Zitat von »ebbi97a«

Trixereien heutzutage
Zumindest tmpfs für /tmp kenne ich seit ca. 10 Jahren.

Zitat von »ebbi97a«

Bis auf eine einzige Datei, die ich mir noch genauer anschauen muß, ging alles durch. Die angemeckerte Datei konnte ich überspringen und mit dem Rest weiter machen,
[...]
Allerdings waren die Kopien nicht fehlerfrei - viele hatten nur die Größe 0.
Damit sind wir wieder beim Punkt "Überspringen ohne weiter nachzudenken"
  • Wenn nach 70 Dateien das Ziel plötzlich nur noch read-only ist...
  • Es danach wieder von selbst read-write wird...
  • Kopien keinen Inhalt haben...
... würde ich mir nicht nur eine einzige Datei "genauer anschauen", sondern gleich abbrechen und die Ursache suchen. Alles andere ist verlorene Zeit (und vielleicht Restlebensdauer der Daten)

Zitat von »ebbi97a«

wenn das nicht verläßlich funktioniert
... könnte es an der Hardware liegen...

Außerdem fällt auf, daß sdb unter /media mit ihrer UUID als Name gemountet ist. Ein Hinweis, daß sie dynamisch eingehängt wurde und nicht per fstab. (Zumindest fand der Kopiervorgang über diesen Mountpunkt statt)
Wenn die zwischendurch kommt und geht, liegt die Inkonsistenz auf der Hand.

Nebenbei ist mir unklar warum du im Home als root arbeitest.

Zitat von »ebbi97a«

df -h zeigt doch nicht die Verzeichnisse?
In dieser Form zeigt es die Belegung aller eingehängten Dateisysteme.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

18

20.12.2016, 08:22

Erst mal Pause machen - abschalten - nachdenken

Zitat von »Fredl«

Damit sind wir wieder beim Punkt "Überspringen ohne weiter nachzudenken"

Wenn nach 70 Dateien das Ziel plötzlich nur noch read-only ist...
Es danach wieder von selbst read-write wird...
Kopien keinen Inhalt haben...

... würde ich mir nicht nur eine einzige Datei "genauer anschauen", sondern gleich abbrechen und die Ursache suchen. Alles andere ist verlorene Zeit (und vielleicht Restlebensdauer der Daten)

Du hast ja recht und ich schäme mich auch ganz arg.
Aber wenn die Hardware nicht mehr funktioniert bin ich mit meinem Latein am Ende. Da fällt mir einfach nichts ein. Zumal das Zeug ja alles neu ist. Sonst mühe ich mich meistens mit altem Schrott ab. Die erwähnte angemeckerte Datei habe ich später übrigens noch angeschaut und sie war in Ordnung: ein Video, das sich abspielen ließ. Daraus folgt für mich erstmal nichts. Das was ich hier mache ist ja gerade die Ursachensuche, weil meine eigene Phantasie dazu nicht ausreicht. Ich bin euch übrigens sehr dankbar, daß ihr darauf eingegangen seid.

Was soll ich bei leeren Dateien schauen? Da sieht man ja nichts. Unerklärlich! Ein Wunder!
Heiße ich Don Quijote?
Ich kann einfach nicht mehr; in 1 Monat mache ich weiter.

Diese Antwort schreibe ich jetzt schon mit dem 2. Neustart, weil immer wieder /home ins Nirwana geht. Zum Glück habe ich die externe Platte, auf welcher ich den aktuellen Stand des Entwurfs sichern kann. Es schaut ganz nach deiner gestrigen Warnung aus, daß eine Platte Knall auf Fall sterben kann.

Zitat von »Fredl«

Zitat von »ebbi97a«
wenn das nicht verläßlich funktioniert

... könnte es an der Hardware liegen...

Außerdem fällt auf, daß sdb unter /media mit ihrer UUID als Name gemountet ist. Ein Hinweis, daß sie dynamisch eingehängt wurde und nicht per fstab. (Zumindest fand der Kopiervorgang über diesen Mountpunkt statt)
Wenn die zwischendurch kommt und geht, liegt die Inkonsistenz auf der Hand.

Nebenbei ist mir unklar warum du im Home als root arbeitest.

Der Verdacht gegen die Hardware verdichtet sich also immer mehr. Mit meiner gestrigen chaotischen Testerei wollte ich das näher einkreisen: - ist es nur die sdb oder ist die sda auch betroffen? ist es überhaupt eine Platte oder was anderes?
3. Neustart - beim 4. werde ich mit Linux Mint weiterschreiben und nicht mehr mit Xubuntu.
Der letzte Versuch von gestern (die Kopierorgie mit > 170 GB) fand mit Mint statt, weil ich wissen wollte, ob eher das Betriebssystem schuld ist oder eine bestimmte Platte. Deswegen waren die Datenpartitionen dynamisch eingehängt, weil das andere System sie sonst überhaupt nicht verwendet. Und als root (sudo mc) habe ich gearbeitet, weil ich ohne gleich nach wenigen Dateien wegen fehlender Rechte hingefallen bin. Schließlich habe ich nicht gefährliches gemacht, sondern lediglich einen Haufen Daten kopiert, die wieder gelöscht worden wären.

Der ganze Vorgang hat keine größeren Erkenntnisse gebracht, außer:
  • Der Rechner hat grundlegende Fehler. Elementare Funktionen, wie das Kopieren von Dateien, verlaufen erratisch - manches klappt, manches nicht - und manches scheitert ohne Fehlermeldung, z.B. die "Kopien" der Länge 0.
  • Der von mir so bezeichnete Partitionszauber kann nicht stattfinden, weil die dazu neigende Partition gar nicht statisch eingehängt ist.
  • Meine Vermutung, daß sdb dadurch vom Verdacht entlastet sei, war ein Trugschluß.

_____________________________________________________________________________
9:28h:
Wie lange hat man denn auf Festplatten Garantie? Habe die Rechnung gefunden die sagt, daß meine am 14.7.2016 in München gekauft worden ist.

10:04h:
Frage hat sich erledigt. Habe angerufen und erfahren, daß ich 2 Jahre Garantie habe; kann mir also Zeit lassen, bis genügend Beweise zusammen sind.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 12 mal editiert, zuletzt von »ebbi97a« (20.12.2016, 10:06)

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

  • Nachricht senden

19

20.12.2016, 22:06

Daß das Video abspielbar war, lag an der Wiederholung des Kopiervorgangs. Es ist aber nicht die Regel, daß ein Dateisystem plötzlich read-only wird. Read-write wurde es wieder, weil die Platte wieder zu sich kam und -wie du bestätigt hast- dynamisch neu gemountet wurde. Nach wie vor könnte auch der Controller schuld sein, allerdings gebe ich meine Erfahrung wieder die ich nur mit WD gemacht habe. Um es besser einzugrenzen, müsste man wissen ob der gleiche Controller auch die andere Platte bedient. Und wenn ja, ob die auch ähnliche Phänomene zeigt.

Mach einen zweiten SMART-Test; genauso wie vorhin inklusive Speichern, aber unter neuem Dateinamen im Verzeichnis /root. Wenn sich der oben genannte Wert (oder ein anderer) weiter verschlechtert, hast du genug Fakten für eine Reklamation. Du kannst aber auch warten bis sie ins Koma fällt, dann hast du aber mangels Protokoll mehr mündlich/schriftlich zu argumentieren. Außerdem kannst du dann deine Daten nicht mehr sichern.
Ich erinnere mich, daß bei mir alles wirklich schnell ging. Es war die Systemplatte und der Rechner kannte im Sekundentakt immer weniger Kommandos. Bis er aus dem Netzwerk verschwand...
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

ebbi97a

User

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

20

21.12.2016, 06:46

Testergebnis

Zitat von »Fredl«

Mach einen zweiten SMART-Test; genauso wie vorhin inklusive Speichern, aber unter neuem Dateinamen im Verzeichnis /root. Wenn sich der oben genannte Wert (oder ein anderer) weiter verschlechtert, hast du genug Fakten für eine Reklamation. Du kannst aber auch warten bis sie ins Koma fällt, dann hast du aber mangels Protokoll mehr mündlich/schriftlich zu argumentieren. Außerdem kannst du dann deine Daten nicht mehr sichern.

Heute Nachmittag werde ich außer Haus sein und den Langtest starten. Dazu werde ich ein heiles System in diesem Rechner - nämlich Linux Mint - laufen lassen, welches die /dev/sdb außer einer Swap-Partition überhaupt nicht einbindet. Nach meinem Verständnis muß eine zu testende Platte nur elektrisch eingebunden sein, aber dem System nicht logisch zur Verfügung stehen. Entschuldige die schwammige Ausdrucksweise; ich will einfach nur verhindern, daß der Test während meiner Abwesenheit nicht weiterläuft, weil das (Betriebs-)System meint, daß ihm was Wichtiges (z.B. sein /home-Verzeichnis) fehle.

Habe mir inzwischen GSmartControl installiert, damit ich mir die Kommandos nicht merken muß und sie somit auch nicht falsch machen kann. Einen soeben damit gemachten Kurztest hänge ich hier an. Arbeite gerade mit Xubuntu (dem "kaputten" Betriebssystem) - am Nachmittag will ich ein anderes laufen lassen. Über die Controller kann ich nichts sagen; was der Rechner da hat weiß ich nicht. Ich erinnere mich nur, daß ich die zweite Platte mit einem eigenen Kabel an einen anderen Steckplatz angeschlossen habe. Die Ausgabe von sudo lshw hänge ich ebenfalls hier an.
__________________________________________________________________________________

Nachtrag 20:51h:

Wie man sehen kann, hing der Test ziemlich lange bei 90% fest, zeigte aber trotzdem an, daß nur noch 0 Sekunden zu warten wäre. Dank der graphischen Oberflächer erkannte ich, daß ich besser noch warten solle und nach einer Stunde war dann alles wirklich fertig.


Leider hat der Test wieder keine Fehler gefunden. Das ist die dritte Datei mit 4,95kB; hat dank meiner Unaufmerksamkeit den gleichen Namen wie die erste.
»ebbi97a« hat folgende Dateien angehängt:
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von »ebbi97a« (21.12.2016, 21:03)

  • 1
  • 2

Zurzeit ist neben Ihnen 1 Benutzer in diesem Thema unterwegs:

1 Besucher

Ähnliche Themen

Verwendete Tags

Btrfs, ext4, partition, Timeshift, xubuntu