staging.inyokaproject.org

Problem mit Dateisystemzugriff?

Status: Gelöst | Ubuntu-Version: Kubuntu 20.04 (Focal Fossa)
Antworten |

trisaster

Anmeldungsdatum:
12. April 2020

Beiträge: Zähle...

Seit heute spinnt mein Rechner so richtig herum und ich habe nicht mal eine wirkliche Ahnung, in welche Richtung es geht. Daher leider eine lange Schilderung.

Kubuntu liegt zusammen mit dem Benutzerordner auf einer SSD, weitere Daten liegen auf einer HDD. Habe heute zu Beginn ein reguläres Update gemacht, wie es fast jeden Tag vorkommt. Kurz danach trat der Fehler zum ersten mal auf. Keine Ahnung, ob es da einen Zusammenhang gibt, glaube aber nicht.

Ich arbeite gerade viel mit LibreOffice (Abschlussarbeit, super Timing). Das Spektakel fing heute Vormittag an. Auf einmal flackerte der Inhalt im LibreOffice-Fenster und der Mauszeiger zeigte das "Ladesymbol". Der Rechner war wohl wirklich beschäftigt, denn nicht einmal jeder Klick wurde da registriert, ein wenig so, als würde man während des automatischen Zwischenspeicherns klicken. Hektisch wollte ich das Dokument speichern, aber LibreOffice weigerte sich. An die Fehlermeldung kann ich mich nicht mehr genau erinnern. Das Speichern in einer neuen Datei scheiterte auch, egal ob auf der SSD ode HDD. Allerdings konnte ich Textabschnitte in einer simplen txt-Datei sichern, das war kein Problem. Danach schloss ich Writer und versuchte das Dokument neu zu öffnen. Doch da erschien die Meldung, das Dokument sei beschädigt, ein Reparaturversuch schlug fehl. Writer ließ sich aber generell nicht mehr starten. Ich weiß nicht mehr, ob es bereits zu diesem Zeitpunkt war, aber ich versuchte noch VirtualBox zu starten, doch das klappte nicht.

Nach einem Neustart und der Benutzeranmeldung erschien ein Fehler vom XServer. Erneuter Neustart und alles schien wieder normal, das Dokument konnte ich wieder öffnen, VirtualBox starten. Diesmal wurden mir kritische Updates angezeigt, die ich aber lieber erst einmal mied. Irgendwann scheiterte das Speichern wieder, allerdings ohne Geflacker im Fenster. Ich versuchte es dann doch mit den Updates, aber auch die scheiterten, weil angeblich auf die Adresse nicht zugegriffen werden konnte.

Wieder Neustart, wieder die gleiche Fehlermeldung vom XServer. Beim Versuch sie vollständig anzeigen zu lassen, hab ich den Inhalt irgendwie weggeklickt, daher konnte ich es nicht abschreiben, aber ich meine, es war irgendwas mit /tmp. Aber erneuter Neustart, ging wieder, auch das Update lief nun durch.

Nun trat der Fehler zum Dritten Mal auf, ich kann in LibreOffice wieder nicht speichern und keine Dateien öffnen. Ein Download des neuesten Debian-Paketes scheiterte mit der Meldung "/tmp/... konnte nicht gespeichert werden, weil die Quelldatei nicht gelesen werden konnte.", also wieder irgendwas mit dem /tmp-Verzeichnis.

Hat irgendwer eine Idee, was da faul sein könnte? Fehler in der SSD, vielleicht dem RAM, der Grafikkarte? Oder doch eher ein Softwarefehler? Vielen Dank im Voraus.

Backups werden fleißig angelegt, seit heute noch häufiger und noch verteilter, das ist nicht das Problem, würde aber gern ungestört weiter arbeiten können.

seahawk1986

Anmeldungsdatum:
27. Oktober 2006

Beiträge: 10978

Kannst du mal die Ausgabe von dmesg anhängen? Da sollte man sehen, wenn ein Dateisystem aufgrund von I/O Fehlern read-only eingehängt wird. Den Festplattenstatus kann man natürlich auch mal prüfen (was für eine SSD hast du?), genauso wie den RAM mit memtest (das am Besten über Nacht laufen lassen).

Mit

snap list 

kannst du dir die installierten Snap-Pakete listen lassen und in /var/log/apt/history.log sollte drin stehen, welche Pakete die Paketverwaltung zuletzt aktualisiert hat.

trisaster

(Themenstarter)

Anmeldungsdatum:
12. April 2020

Beiträge: 34

Danke für die Antwort!

Die Ausgabe von dmesg ist als txt-Datei angehangen. Da sind eine Menge USB-Meldungen drin, die aber vermutlich nicht interessieren. Am Ende waren aber zwei Meldungen rot hervorgehoben.

Die SSD ist eine Crucial CT500MX500SSD1. Habe mir den Status mit GSmartControl angesehen, die HDD ist nicht auffällig, aber bei der SSD steht "Warnung: This firmware returns bogus raw values in attribute 197" (Current Pending Sector Count). Die Daten selbst scheinen in Ordnung. Den Log von GSmartControl habe ich ebenfalls angehangen.

dmesg.txt (24.3 KiB)
Download dmesg.txt
CT500MX500SSD1_2021-06-03.txt (15.9 KiB)
S.M.A.R.T-Daten
Download CT500MX500SSD1_2021-06-03.txt

seahawk1986

Anmeldungsdatum:
27. Oktober 2006

Beiträge: 10978

Die Ausgabe von dmesg reicht nicht zurück bis zum Bootvorgang - da es schwer ist sowas im Terminal zu kopieren, ist es vermutlich einfacher, wenn du das gleich in eine Datei umleitest

dmesg > ~/dmesg.log 

Retrospektiv könnte man sich auch die dmesg-Logdateien aus /var/log/ ansehen, die auch die Meldungen der früheren Boots enthalten sollten - wenn du noch weißt, wann die Probleme in etwa aufgetreten sind, lässt sich das vielleicht sogar noch nachverfolgen, was da passiert ist (falls das Laufwerk, das die Logdateien schreibt, nicht betroffen war).

Da der Wert für den UDMA_CRC_Error_Count in den S.M.A.R.T. Werten nicht 0 ist, würde ich mal schauen, ob das SATA-Kabel eventuell nicht fest sitzt bzw. ob es etwas hilft das auszutauschen.

trisaster

(Themenstarter)

Anmeldungsdatum:
12. April 2020

Beiträge: 34

Ah danke, wusste nicht mehr, wie das mit dem Umleiten funktionierte und es war schon nicht mehr alles im Terminal zu lesen. Nun, auf ein Neues.

Danke, ich schaue mal nach dem Kabel.

dmesg.log (110.8 KiB)
Download dmesg.log

seahawk1986

Anmeldungsdatum:
27. Oktober 2006

Beiträge: 10978

Ok, da sehe ich für den aktuellen Boot nichts auffälliges - ist der Fehler bei dem schon aufgetreten?

trisaster

(Themenstarter)

Anmeldungsdatum:
12. April 2020

Beiträge: 34

Ja, der Fehler ist seit dem Boot aufgetreten.

Habe die Stecker am SATA-Kabel gereinigt und auch die Buchsen an der SSD und dem Mainboard. Mal sehen, ob der Fehler erneut auftritt.

Edit: Das hat das Problem nicht gelöst, aber es wird immer obskurer. Ich hatte LibreOffice nach Auftreten des Fehlers noch lange offen und konnte das Dokument dann noch als DOC, PDF und als ODT speichern, Downloads im Browser klappten auch. Die PDF und DOC kann ich nach der Steckverbinder-Reinigung öffnen, aber ODT-Dateien kann ich keine einzige öffnen. Downloads gehen wieder nicht, mit der Meldung, es sei nicht genügend Speicherplatz frei. Dolphin zeigt für die root-Partition "0 Byte frei" an, also stimmt es, was der Browser sagt.

Aus einem mir unerfindlichen Grund ist die root-Partition nur 64,00 GB groß und mit 59,34 GB belegt, sagt zumindest die KDE-Partitionsverwaltung. Das home-Verzeichnis ist in einer separaten Partition (360 GB) und da ist noch einiges frei. swap ist 40 GB. Kann es sein, dass die root-Partition zu voll ist?

Edit 2: Wieder Neustart, nun sind angeblich 257,3 MB frei und alles läuft normal. Ich werde den Status im Auge behalten, bis der Fehler wieder auftritt.

Doc_Symbiosis

Avatar von Doc_Symbiosis

Anmeldungsdatum:
11. Oktober 2006

Beiträge: 4212

Hm, hast Du denn etwas, was auf der Root-Partition so viel Platz verbrauchen könnte? Fast 60GB ist ja schon extrem viel.

Installier vielleicht mal ncdu und schaue, wo der Platz denn verbraucht wird:

sudo apt install ncdu
sudo ncdu /

Wenn Du ein Ext-Dateisystem auf deiner Root-Partition hast, dann sind per Standard 5% für Root reserviert. Das könnte bei deinem Füllstand also durchaus zu Problemen führen...

trisaster

(Themenstarter)

Anmeldungsdatum:
12. April 2020

Beiträge: 34

Das würde tatsächlich alles erklären.

    2,4 TiB [##########] /media                                                                                                                                                                                                                                                
  259,6 GiB [#         ] /home
   27,3 GiB [          ] /usr
   23,1 GiB [          ] /var
   14,2 GiB [          ] /snap
    5,6 GiB [          ] /opt
    2,8 GiB [          ] /boot
   30,0 MiB [          ] /root
   23,4 MiB [          ] /etc
    1,9 MiB [          ] /run
  160,0 KiB [          ] /tmp
e  16,0 KiB [          ] /lost+found
    8,0 KiB [          ] /mnt
e   4,0 KiB [          ] /srv
e   4,0 KiB [          ] /cdrom
.   0,0   B [          ] /proc
    0,0   B [          ] /sys
    0,0   B [          ] /dev
@   0,0   B [          ]  libx32
@   0,0   B [          ]  lib64
@   0,0   B [          ]  lib32
@   0,0   B [          ]  sbin
@   0,0   B [          ]  lib
@   0,0   B [          ]  bin

/home und /media sind wie gesagtz separate Partitionen, also irrelevant. Habe einige Pakete manuell installiert, daher die 5,6 GB beu /opt, das passt. /snap wundert mich, da ich snap weitestgehend vermeide. Hab mit ncdu einmal /snap, /var und /usr durchsucht:

--- /snap --------------------------
    2,0 GiB [##########] /gnome-3-38-2004                                                                                                                                                                                                                                      
    1,7 GiB [########  ] /wine-platform-runtime
    1,6 GiB [########  ] /wine-platform-5-stable
    1,2 GiB [#####     ] /gnome-3-28-1804
    1,0 GiB [####      ] /pyqt5-runtime
  962,0 MiB [####      ] /kde-frameworks-5-qt-5-14-core18
  868,0 MiB [####      ] /kde-frameworks-5-core18
  781,8 MiB [###       ] /wine-platform-3-stable
  653,2 MiB [###       ] /gtk-common-themes
  592,4 MiB [##        ] /core
  562,6 MiB [##        ] /typora
  412,9 MiB [##        ] /p7zip-desktop
  400,5 MiB [#         ] /riot-web
  394,0 MiB [#         ] /core20
  355,6 MiB [#         ] /discord
  337,4 MiB [#         ] /core18
  264,5 MiB [#         ] /pdf2go
  236,9 MiB [#         ] /snapd
   13,1 MiB [          ] /irfanview
  812,5 KiB [          ] /gtk2-common-themes
    4,0 KiB [          ] /bin
    4,0 KiB [          ]  README
--- /var ---------------------------
   12,2 GiB [##########] /cache                                                                                                                                                                                                                                                
    6,1 GiB [####      ] /lib
    4,1 GiB [###       ] /log
  610,9 MiB [          ] /spool
  161,7 MiB [          ] /crash
    7,9 MiB [          ] /backups
    3,1 MiB [          ] /snap
   76,0 KiB [          ] /tmp
e   4,0 KiB [          ] /opt
e   4,0 KiB [          ] /metrics
e   4,0 KiB [          ] /mail
e   4,0 KiB [          ] /local
@   0,0   B [          ]  lock
@   0,0   B [          ]  run
--- /usr ---------------------------
   14,4 GiB [##########] /lib                                                                                                                                                                                                                                                  
    7,9 GiB [#####     ] /share
    4,0 GiB [##        ] /src
  440,7 MiB [          ] /bin
  425,7 MiB [          ] /local
   84,4 MiB [          ] /include
   37,6 MiB [          ] /sbin
   16,2 MiB [          ] /lib32
    4,7 MiB [          ] /libexec
    1,6 MiB [          ] /games
   16,0 KiB [          ] /etc
    4,0 KiB [          ] /lib64
e   4,0 KiB [          ] /libx32

Doc_Symbiosis

Avatar von Doc_Symbiosis

Anmeldungsdatum:
11. Oktober 2006

Beiträge: 4212

Naja, da müsstest Du nochmal genauer schauen. Also /var/cache mit 12Gb finde ich schonmal eine Ansage und /var/log mit 4GB ist für ein Desktop-System auch schon ganz schön ordentlich. Welches Logfile ist da denn so groß?

hakel2020

Anmeldungsdatum:
21. Januar 2021

Beiträge: 1169

161Mb crash Dateien und nie nachgeschaut, was da "Amok" läuft ?

14Gb lib ?

angeblich 257,3 MB frei und alles läuft normal.

Das kann nicht gut gehen!

Nimm' das nicht auf die "leichte Schulter". Wenn die Systemplatte komplett voll läuft, bekommt man das kaum wieder repariert.

Ein Pro würde vermutlich in so einer Situation, nur noch per Live Stick auf das System zugreifen.

Ich würde jetzt erst mal ausreichend Platz schaffen.

Logdateien?

System gepflegt - autoremove, autoclean etc.?

swap ist 40 GB.

Bei separaten home würde ich an dieser Stelle "frisch" aufsetzen, mit vernünftiger Partionierung. 2Gb Swap als Datei reichen im Jahr 2021.

trisaster

(Themenstarter)

Anmeldungsdatum:
12. April 2020

Beiträge: 34

Schon mal recht herzlichen Dank für die hilfreichen Antworten, ich denke das Problem ist vorerst gelöst, ich beobachte das heute nur noch ein wenig.

@Doc_Symbiosis: 3,9 GB stecken in /var/log/journal. Die meisten Dateien darin fassen 128 MB oder 8 MB. Habe nachgesehen, die Dateien enthalten keinen Klartext. Kann ich die Log-Dateien einfach löschen oder zumindest auf eine andere Festplatte verschieben?

Und in /var/cache/apt/archives stecken 12,0 GB der 12,1 GB.

@hakel2020: Nun ja, mir war bis gerade eben nicht bekannt, dass es so viele Crash-Daten gibt, da gucke ich als "normaler Anwender" ja in der Regel nicht rein, wenn alles läuft.

  • 72 MB davon gehen jedenfalls auf NextCloud

  • Danach kommt überraschend Falkon mit 45 MB

  • Auf Platz 3 ist Plasma Discover mit 43 MB

Danach kommen nur noch ein paar Sachen mit 1 MB und kleiner. Die großen Dateien sind alle so groß, weil sie am Ende einen "CoreDump" enthalten und der Rest beschreibt scheinbar einen einzigen Crash und listet nur gefühlt alle Dateien des Systems auf. Die Dateien sind alle am 28.05. bzw. 29.05. angelegt und zuletzt geändert. Ins Auge sticht mir die .crash-Datei von "Deepin Notifications", die einzige Datei von gestern, Eigentümer ist ein anderer Benutzer auf dem System, der aber seit Wochen nicht mehr angemeldet war.

"und alles läuft normal" sollte auch nicht heißen "na dann ist ja alles gut", sondern es bestätigte nur, dass in dem freien Platz wohl das Problem liegt.

System gepflegt? Nun ja, nicht wirklich, nach bestem Wissen und Gewissen würde ich sagen. Solche Sachen waren mir nicht bekannt. autoclean hat mir fast 7 GB gebracht, autoremove rund 500 MB. 7,5 GB frei sind auch nur gut 10%, aber das dürfte für die nächsten Wochen reichen. Hatte ohnehin geplant das System in ein paar Wochen neu aufzusetzen, aber eben erst nach meiner Abschlussarbeit. Ich nutze Linux jetzt seit gut einem Jahr aktiv, habe in der Zeit einiges gelernt und würde ein System heute auch anders aufsetzen. Die Information mit der swap-Partition ist gut, das hätte ich nicht gewusst. Ich kann nur noch mutmaßen, aber vermutlich hatte ich mit dem Wiki-Eintrag hantiert, in dem steht, dass für Suspend-to-Disk die RAM-Größe + 1 GB eingeplant werden sollte. Um das nutzen zu können, habe ich dann 32 GB (RAM) + sicherheitshalter 8 GB genommen.

Lidux

Anmeldungsdatum:
18. April 2007

Beiträge: 14945

Hallo trisaster,

Ausgabe von:

snap list

weil davon ja auch immer zwei Versionen installiert sind.

Gruss Lidux

hakel2020

Anmeldungsdatum:
21. Januar 2021

Beiträge: 1169

aber das dürfte für die nächsten Wochen reichen

Da wäre ich jetzt nicht so optimistisch. Mit diesen Befehlen hast du dir zumindest Luft geschafft, um das eigentliche Problem zu lösen.

Caches und Logs sollten eigentlich vom System beim Boot entrümpelt werden. Ich würde jetzt erst einmal auf STD verzichten, sorgfältig Backup machen und mein System beobachten. Bei SSD und 32GB Ram kann man auf Hibernate und Co. verzichten.

Im Journal sind keine Klartext Logs, das wundert mich etwas.

Crash - wenn du kein apport Freund bist, kannst du das Entfernen.

https://wiki.ubuntuusers.de/Systempflege/

https://wiki.ubuntuusers.de/Logdateien/

https://wiki.ubuntuusers.de/Apport/

Antworten |