☰

StartX funktioniert nicht. (Nicht genug Speicherplatz?)

tag-icon • tag-icon linux hard-drive x-server
StartX funktioniert nicht. (Nicht genug Speicherplatz?)

Mein Debian hat bis gestern einwandfrei funktioniert. Ich hatte Reaver, Aircrack und Kismet installiert und eine Weile damit gespielt (könnten sie der Übeltäter sein?). Aber jetzt stellt der X-Server keine Verbindung her. Ich habe keinen Desktop-Manager installiert, also habe ich immer manuell startx-ed(wm=awesome) ohne Probleme ausgeführt. Jetzt geht das nicht mehr. Ich werde die Symptome hier aufschreiben. Ich hoffe, ihr werdet das Problem diagnostizieren und Lösungen vorschlagen.

  1. Was startxsagt: Der XKEYBOARD Keymap-Compiler ( xkbcomp) meldet:

    Error: cannot close "/tmp/server-0.xkm" properly (not enough space?) ... output file "tmp/server-0.xkm" removed.
Errors from xkbcomp are not fatal.
AIGLX:suspending AIGLX clients for VT switch (EE) server terminated with error (1) ...

    In der xorg.0.logDatei steht im Wesentlichen das Gleiche. ( Keyboard initialization failed, could be missing or incorrect setup of xkeyboard-config)

    Merkwürdig ist, dass es meldet, dass möglicherweise nicht genügend Speicherplatz vorhanden ist. Als ich das letzte Mal nachgesehen habe, war mehr als genug Speicherplatz (20 GB) übrig.

  2. Als ich Reaver, Kismet und Aircrack gelöscht habe: Alles läuft gut, aber es heißt, dass ManDB nicht aktualisiert werden kann, weil nicht genügend Speicherplatz vorhanden ist.

  3. ls an /: Wenn ich drücke cd /;ls, ist das /tmpVerzeichnis das einzige, das grün hervorgehoben ist (bg = grün, fg = schwarz). Ich finde das verdächtig.

  4. Wenn ich die Datei lösche .Xsessionsund dann startx: Die Fehlermeldungen bezüglich der Tastatur sind weg, aber AIGLX-Clients werden immer noch angehalten (Server wird mit Fehler beendet)

  5. Was ich df -isage: Alles ist in Ordnung, nur 10 % der Inodes werden verwendet.

  6. Was df -hsagt: Was???? Es heißt, die Root-Partition sei vollständig belegt. (24 von 24 GB) Das habe ich getan, apt-get cleanund es heißt immer noch, sie sei vollständig belegt.

Okay, Leute, wir alle wissen, was das Problem ist: Das Root-Verzeichnis ist vollständig belegt. Natürlich habe ich das nicht gemacht. Es würde viel zu lange dauern, 20 Gigabyte Daten herunterzuladen, als dass ich es nicht bemerken würde (ich habe eine Downloadgeschwindigkeit von 20 kbps). Außerdem würde es lange genug dauern, so viele Daten als Protokoll oder so etwas zu schreiben. (Das Root-Verzeichnis ist sowieso schreibgeschützt.)

Jemand in den Foren behauptete, das Problem durch behoben zu haben pacman -Scc. Ich habe es versucht apt-get cleanund es hat nicht funktioniert.

Deshalb wende ich mich jetzt an euch, um Hilfe zu erhalten. Bitte macht mir Vorschläge, was ich als nächstes versuchen sollte.

Antwort1

Wenn dfgemeldet wird, dass eine Partition voll ist, duist der Befehl der nächste Schritt bei der Diagnose des Problems. Ich würde cdzum Dateisystem-Root gehen und ausführen

sudo du -smx * .[^.]* | sort -n
  • Die Option -s( --summarize) druckt diegesamtGröße für jede Datei/jedes Verzeichnis.
  • Die -mOption druckt den von jeder Datei/jedem Verzeichnis verwendeten Speicherplatz in Megabyte.
  • Die Option -x( ) erzwingt , dass auf dem ursprünglichen Dateisystem verbleiben soll. Dies lässt irrelevante (für diesen Zweck!) Informationen wie alle Dateien in , , und/oder weg (danke, MariusMatutiae).--one-file-systemdu/run/sys/dev/proc
  • Dies [^.].*schließt versteckte Dateien ein, während das übergeordnete Verzeichnis ausgeschlossen wird ( ..).
  • Und schließlich können Sie durch numerisches Sortieren der Liste bequem am Ende der Liste die Verzeichnisse anzeigen, die den meisten Platz beanspruchen.

Dann wechsle ich in das Verzeichnis, das den meisten Speicherplatz beansprucht, und wiederhole den Vorgang für dessen Unterverzeichnisse. Irgendwann sollten Sie ein Verzeichnis finden, das mehr Speicherplatz beansprucht als es sollte.

Übrigens /tmp/soll es allgemein beschreibbar sein (was zu dem grünen Hintergrund führt). Sein Inhalt sollte regelmäßig automatisch vom Betriebssystem gelöscht werden – aber Sie müssen möglicherweise alte Dateien, die nicht automatisch bereinigt wurden, manuell löschen.

Ich persönlich mounte immer /homein ein separates Dateisystem und wann immer mir das passierte, fand ich heraus, dass die Ursache in den Protokolldateien in lag /var/log.

verwandte Informationen