Maus und dann alles friert ein - Licht an Maus leuchtet weiter

[Worf]

Danke für die wertvollen Hinweise, Kabel getauscht.
Frage:
a) RAM nach 7 kompletten Durchgängen und 40 Stunden komplett fehlerfrei. Daher stecke ich die Riegel jetzt nicht ab zum Reinigen und neu auf - oder sollte ich das trotzdem?
b) Der Platte trau ich doch nicht ganz, habe jetzt eine gute ssd bestellt, wovon ich schon eine anders verbaut habe (Samsung 860 Pro, 512GB), bevor es die nicht mehr gibt.
Muss ja sowieso bald sein.
Habe ja fsck mal beim Bootvorgang gemacht, wo das angeboten wird. Angeblich soll man das mehrfach machen?
Hier in diesem Artikel, den ich nicht ganz verstehe, wird aber nicht die Auswahl

fsck

sondern

root

angesprochen, müsste ich da mit dieser root-Zeile auch was machen?
https://forums.linuxmint.com/viewtopic.php?t=282317
Was ich vorher schon gemacht hatte, aber nur auf der Systempartition, bei mir 6:
Laufwerke reparieren beim Programm "Laufwerke": Da kann ich bei 3 der Partitionen auf Reparieren gehen, was [edit] inzwischen erfolgreich erledigt ist. Mache jetzt nochmals für das laufende System fsck beim Neustart, weil das ja nur so geht - sollte ich diese "root-Zeile" auch noch machen, bitte um Hinweis.

Details dateisystem reparieren via laufwerke wie gesamte platte

dateisystem reparieren via laufwerke wie gesamte platte

--> Bin mir nicht sicher, ob das gleichwertig mit der fsck beim Bootvorgang ist.
c) Damit ich mir das ganze Neueinrichten erspare, würde ich die mit einem guten Gerät (physisch beide Platten stecken und direkt am Gerät nicht via Rechner) klonen. Ist ja eine 500er. Ich hoffe, dem steht nichts entgegen.

[Harry_Brot]

Das wird schon klappen. Einfach machen - mehr als schief gehen kann es ja nicht!   ;o)
Trotzdem ist Vorsicht geboten. Die wichtigen Daten nach Möglichkeit vor der Prozedur sichern!!
Wenn nachher alles weg ist, wirst Du Dich ganz sicher nicht freuen.

[Worf]

Danke ja, habe ich mir auch gedacht: Mit einem Livestick (Install LM 20, der 18er hatte das nicht drauf) konnte ich per "Laufwerke" die dann ausgehängte System-Partition prüfen und reparieren. Das war allerdings in 1 Minute erledigt. Also unglaubwürdig.
Habe mich daher etwas mühsam mit den aktuellen Infos versorgt und das in Terminal gemacht - erstmal nur geprüft. Ich frage mich jetzt, ob es nötig ist auch noch die -p Funktion (preen) zum Reparieren durchlaufen zu lassen, weil ja keine Fehler erkannt wurden.
Werde jedenfalls auch noch die anderen 2 Partitionen so prüfen, weil das "Laufwerke" da sicher zu oberflächlich ist.
Siehe:

Code: [Auswählen]

mint@mint:~$ sudo umount /dev/sdc6
umount: /dev/sdc6: nicht eingehängt.
mint@mint:~$ sudo fsck.ext4 -v -f -c -y /dev/sdc6
e2fsck 1.45.5 (07-Jan-2020)
Es wird nach defekten Blöcken gesucht (Nur-Lesen-Modus):   0.00% erledigt, 0:00 verstrichen. (0/0/0 Fehlerledigt                                                 
/dev/sdc6: Updating bad block inode.
Durchgang 1: Inodes, Blöcke und Größen werden geprüft
Durchgang 2: Verzeichnisstruktur wird geprüft
Durchgang 3: Verzeichnisverknüpfungen werden geprüft
Durchgang 4: Referenzzähler werden überprüft
Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft

/dev/sdc6: ***** DATEISYSTEM WURDE VERÄNDERT *****

      731022 Inodes sind in Benutzung (5.62% von 13008896)
        3131 nicht zusammenhängende Dateien (0.4%)
         948 nicht zusammenhängende Verzeichnisse (0.1%)
             # von Inodes mit ind/dind/tind Blöcken: 0/0/0
             Histogramm der Tiefe von Erweiterungen: 648260/328
    28669895 Blöcke werden benutzt (55.13% von 52005632)
           0 defekte Blöcke
           2 große Dateien

      552984 reguläre Dateien
       93499 Verzeichnisse
          56 zeichenorientierte Gerätedateien
          25 Blockgerätedateien
           0 Fifos
       42298 Verknüpfungen
       84442 symbolische Verknüpfungen (82338 schnelle symbolische Verknüpfungen)
           7 Sockets
------------
      773311 Dateien
mint@mint:~$Wenn ich das jetzt falsch herauslese und doch Fehler erkennbar sind, bitte gebt mir einen Hinweis.

Nachtrag @flash63: woher hast du die aktuelle memtest86-Datei? Ich habe auf der orig. hp nirgends Versionshinweise gefunden, daher wollte ich nicht von dort downloaden?

Den Reperaturlauf konnte ich seltsamerweise nicht starten, Eingabe am Terminal hat darauf nicht reagiert, daher vorerst die anderen beiden Partitionen angeschaut:
Diese Mini-Partition in fat ergibt Fehlermeldungen bzw. Zugriffsprobleme, vermutlich weil FAT, aber ausgerechnet da wird nichts fehlerhaft sein:

Code: [Auswählen]

mint@mint:~$ sudo umount /dev/sdc3
umount: /dev/sdc3: nicht eingehängt.
mint@mint:~$ sudo fsck.ext4 -v -f -c -y /dev/sdc3
e2fsck 1.45.5 (07-Jan-2020)
ext2fs_open2: Ungültige magische Zahl im Superblock
fsck.ext4: Superblock ungültig, Datensicherungs-Blöcke werden versucht ...
Lesefehler - Block 25722880 (Das Argument ist ungültig).  Fehler ignorieren? ja
Rückschreiben erzwingen? ja
Der Superblock hat ein defektes Journal (Inode 8).
Bereinigen? ja
*** journal has been deleted ***
Der Bitschalter has_journal im Superblock ist nicht gesetzt, aber ein
Journal NULL ist vorhanden.
Bereinigen? ja
Die Größe des Dateisystems (laut Superblock) ist 52137216 Blöcke.
Die physikalische Größe des Gerätes ist 131328 Blöcke.
Entweder ist der Superblock oder die Partionstabelle beschädigt!
Abbrechen? ja
Schreibfehler - Block 25722880 (Das Argument ist ungültig).  Fehler ignorieren? ja
/dev/sdc3: ***** DATEISYSTEM WURDE VERÄNDERT *****

mint@mint:~$ sudo fsck.ext4 -v -f -c -p /dev/sdc3
fsck.ext4: Ungültige magische Zahl im Superblock beim Versuch, /dev/sdc3 zu öffnen
/dev/sdc3:
Der Superblock ist unlesbar bzw. beschreibt kein gültiges ext2/ext3/ext4-
Dateisystem. Wenn das Gerät gültig ist und ein ext2/ext3/ext4-
Dateisystem (kein swap oder ufs usw.) enthält, dann ist der Superblock
beschädigt, und Sie könnten versuchen, e2fsck mit einem anderen Superblock
zu starten:
    e2fsck -b 8193 <Gerät>
 oder
    e2fsck -b 32768 <Gerät>
/dev/sdc3 hat ein vfat-Dateisystem


Details mini partition hat fehler bzw kein zugriff

mini partition hat fehler bzw kein zugriff

[Flash63]

Nachtrag @flash63: woher hast du die aktuelle memtest86-Datei?

Von der memtest-Seite, bzw. von den div. Live-USB-Sticks.

Deine alte Festplatte wird Schäden am Dateisystem haben, nicht die Platte selbst. Lasse es so wie es ist, sichere deine wichtigen Daten zusätzlich auf anderen Datenträger (ext. Festplatte) und installiere Mint 20 Cinnamon auf der neuen SSD neu. Kopiere nicht über dd o.v. ein Fehlerhaftes System auf die neue SDD auch wenn das etwas mehr Arbeit wg. der zu intallieren Programme und Konfiguration bedeutet!

Formatiere die SSD mit ext4.
* ~20GB / Wurzelverzeichnis für das System
* ~450GB /home für dein pers. Verzeichnis & Daten
* ~4 GB /swap (bei 32GB RAM eigentlich unnötig)

Die alte Platte nach Datensicherung neu partitionieren (neue msdos Partitionstabelle), auch komplett mit ext4 formatieren und z.B als /daten direkt bei der Neuinstallation im System einhängen.

[Worf]

Oje, wenns sein muss. Zeitmäßig nicht leicht momentan.
Ist das eigentlich erklärbar, dass das System jetzt seit Tagen fehlerfrei läuft? Laienhaft stelle ich mir halt doch fehlerhafte Dateien vor, sodass dieses Fehlverhalten nur dann auftritt, wenn diese angesprochen werden 

Hier die reine Datenpartition (da war früher ubuntu drauf):

Code: [Auswählen]

mint@mint:~$ sudo fsck.ext4 -v -f -c -y /dev/sdc1
e2fsck 1.45.5 (07-Jan-2020)
Es wird nach defekten Blöcken gesucht (Nur-Lesen-Modus):   0.00% erledigt, 0:00 erledigt                                                 
Meine_Daten: Updating bad block inode.
Durchgang 1: Inodes, Blöcke und Größen werden geprüft
Durchgang 2: Verzeichnisstruktur wird geprüft
Durchgang 3: Verzeichnisverknüpfungen werden geprüft
Durchgang 4: Referenzzähler werden überprüft
Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft

Meine_Daten: ***** DATEISYSTEM WURDE VERÄNDERT *****

      848939 Inodes sind in Benutzung (5.16% von 16449536)
        2631 nicht zusammenhängende Dateien (0.3%)
         943 nicht zusammenhängende Verzeichnisse (0.1%)
             # von Inodes mit ind/dind/tind Blöcken: 0/0/0
             Histogramm der Tiefe von Erweiterungen: 712766/685
    44050442 Blöcke werden benutzt (66.95% von 65794423)
           0 defekte Blöcke
           1 große Datei

      578115 reguläre Dateien
      132285 Verzeichnisse
           0 zeichenorientierte Gerätedateien
           0 Blockgerätedateien
           0 Fifos
      587638 Verknüpfungen
      138530 symbolische Verknüpfungen (135480 schnelle symbolische Verknüpfungen)
           0 Sockets
------------
     1436568 DateienÜbrigens scheint die Reperaturfunktion bei mir nicht zu funktionieren, der Cursor steht dann einfach da und ich kann keine Aktion erkennen trotz der Eingabe

Code: [Auswählen]

~$ sudo fsck.ext4 -v -f -c -p /dev/sdc6Laut man fsck.ext4 ist diese Funktion aber aktiv:

Code: [Auswählen]

-p     Automatically repair ("preen") the file system.  This option will cause e2fsck to automatically fix any filesystem problems that can be safely fixed  without  human  intervention.
              If  e2fsck  discovers  a problem which may require the system administrator to take additional corrective action, e2fsck will print a description of the problem and then exit with
              the value 4 logically or'ed into the exit code.  (See the EXIT CODE section.)  This option is normally used by the system's boot scripts.  It may not be specified at the same time
              as the -n or -y options.Seltsam!

[Flash63]

Du hattest doch z.B. die Speicherriegel aus- und wider eingesetzt und SATA-Kabel getauscht, oder nicht? Die Reparatur der jeweiligen Partitionen ist ja anscheinend auch fehlerfrei durchgelaufen.

Unter Zeitdruck etwas neu einzurichten rächt sich meistens später.

[Worf]

Anschlüsse gereinigt und Satakabel getauscht, Riegel dann nicht entfernt, weil da ja der 40 Stundentest tadellos war.

[Worf]

Ich wollte auf LM20.3 warten, weils da hieß, da kämen wesentliche Fehlerbehebungen (zB kann ich da auch erst die proprietären nvidia-Treiber nutzen ...)

[Flash63]

Bugfixes kommen ständig. Gerade aktuelle Versionen enthalten i.d.R. wieder neue Fehler. Du meinst sicherlich das kommende Point-Release. https://wiki.ubuntuusers.de/Long_Term_Support/

zB kann ich da auch erst die proprietären nvidia-Treiber nutzen ...

Ich sehe keinen Grund warum das jetzt nicht möglich sein sollte.

[Worf]

Code: [Auswählen]

Ich sehe keinen Grund warum das jetzt nicht möglich sein sollte.Das hatte ich natürlich so installiert wie zuvor im LM 19xfce, aber machte gröbere Probeleme. Gibt einige Beiträge dazu und auch eine Empfehlung glaube auch von tommix,
zB hier:
https://www.linuxmintusers.de/index.php?topic=62854.msg834925;topicseen#msg834925
Gefunden:
tommix hatte mich darauf aufmerksam gemacht, dass erst ab 20.3 die nvidia-Fehler bereinigt sein sollen:
https://www.linuxmintusers.de/index.php?topic=62854.msg853332#msg853332

Darum zögere ich zusätzlich: müsste erst auf LM 19 zurück ........

[Worf]

Nach der Eingabe jetzt mit der preen-Funktion steht der Cursor immer noch bewegungslos und tut sich nichts (ersichtliches). Fenster schließen - Versuch erzeugt Meldung, dass noch ein Prozess läuft.
Entweder rennt da tatsächlich noch ein Fehlerbehebungsprogramm oder könnte es daran liegen, dass es aussteigt ohne Meldung wie hier angedeutet?
https://unix.stackexchange.com/questions/18526/what-does-fsck-p-preen-do-on-ext4
Edit:
Ist beendet, konnte das Fenster jetzt schließen. Mit -p allein bekam ich (allerdings nach 1 Sekunde!) eine Rückmeldung:

Code: [Auswählen]

mint@mint:~$ sudo fsck.ext4 -p /dev/sdc6
/dev/sdc6: sauber, 731022/13008896 Dateien, 28669895/52005632 Blöcke
mint@mint:~$
Seltsam. Offenbar kann man auch die ursprüngliche fsck (ohne .ext4) zum Reparieren verwenden, die wird offenbar zur Reparatur mit -a auch oft verwendet? Oder eben -p
Wenn ich eh neu aufsetzen muss, könnte ich das vorher noch tun oder  problematisch?
Edit: jetzt kapiert, fsck kann ich nur für die Partition 3 verwenden (FAT) und die bringt das:

Code: [Auswählen]

mint@mint:~$ sudo fsck -v -f -c -y /dev/sdc3
fsck von util-linux 2.34
CP0: Das Argument ist ungültig
Trying to set fallback DOS codepage 437
fsck.fat 4.1 (2017-01-24)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkfs.fat"
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
      4096 bytes per cluster
        32 reserved sectors
First FAT starts at byte 16384 (sector 32)
         2 FATs, 32 bit entries
    524288 bytes per FAT (= 1024 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 1064960 (sector 2080)
    131068 data clusters (536854528 bytes)
63 sectors/track, 255 heads
 526358528 hidden sectors
   1050624 sectors total
Reclaiming unconnected clusters.
Checking free cluster summary.
/dev/sdc3: 0 files, 1/131068 clusters
mint@mint:~$ sudo fsck -p /dev/sdc3
fsck von util-linux 2.34
fsck.fat 4.1 (2017-01-24)
/dev/sdc3: 0 files, 1/131068 clusters
mint@mint:~$Auch mit Paramenter -a gehts:

Code: [Auswählen]

mint@mint:~$ sudo fsck -a /dev/sdc3
fsck von util-linux 2.34
fsck.fat 4.1 (2017-01-24)
/dev/sdc3: 0 files, 1/131068 clusters
mint@mint:~$
Bei den ext4 wird abgebrochen, weil die offenbar nur noch mit e2fsck prüfbar sind.

[ehtron]

Hi

tommix hatte mich darauf aufmerksam gemacht, dass erst ab 20.3 die nvidia-Fehler bereinigt sein sollen:

das war wohl nicht @tommix
hätte mich auch gewundert, solch merkwürdige aussagen.

das system wird ständig verbessert..  der ubuntu unterbau ständig, grössere mint dinge beim mint point release.
natürlich sind in der letzten version fehler beseitigt, die anfgangs noch da waren.
(aber auch sicher neue hinzugefügt.)
(ist wie beim facelift beim auto, bis das ganz neue modell kommt)

[Worf]

Hatte mich auch gewundert, aber ich habe zu meiner Aussage ja auch den Link dazugestellt, siehe oben.

[Flash63]

Hallo,
mal etwas anderes. Warum verwendest Du überhaupt eine leistungsstarke aber energiehungrige Nvidia GTX1080? Das ist eine Karte für Spiele unter Windows. Die int. iGPU der i7-4790K (Intel Graphik HD 4600) ist doch leistungsstark genug für alle erdenklichen Aufgaben im Office-Bereich oder sogar einfachen Videoschnitt, und 4k mit 60Hz Bildwiederholrate wäre möglich. Auf dem Mainboard Asrock Z87 Extreme11/ac befindet sich auch ein HDMI und Display-Port für den Monitor. Irgendwie ist die ganze PC-Konfiguration für mich so nicht schlüssig. Jetzt mit der neuen SSD und auch ohne die nNvidia-Karte wäre das doch ein Top-System.

[Worf]

Hat verschiedene Gründe, das Motherboard hat u.a. eben keinen Displayport, das ist irreführend dargestellt .... aber ich muss das System eh mal umbauen.
Noch zu meiner Frage

Riegel dann nicht entfernt, weil da ja der 40 Stundentest tadellos war.

- sollte ich die Riegel dennoch abziehen, reinigen und neu einsetzen?
Würde zunächst mal die neue ssd dann einbauen.