StartX не работает. (Недостаточно места?)

StartX не работает. (Недостаточно места?)

Мой Debian работал отлично до вчерашнего дня. Я установил reaver, aircrack и kismet и игрался с ними некоторое время (могут ли они быть виновниками?). Но теперь x-сервер не подключается. У меня не установлен менеджер рабочего стола, поэтому я всегда вручную startxнажимал -ed(wm=awesome) без каких-либо проблем. Теперь я не могу. Я опишу симптомы здесь. Надеюсь, вы, ребята, диагностируете проблему и предложите решения.

  1. Что startxговорит: Компилятор раскладки клавиатуры XKEYBOARD ( xkbcomp) сообщает:

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

    В xorg.0.logфайле говорится по сути то же самое. ( Keyboard initialization failed, could be missing or incorrect setup of xkeyboard-config)

    Что странно, так это то, что он сообщает, что может быть недостаточно места. В последний раз, когда я проверял, места было более чем достаточно (20 гигов).

  2. Когда я удалил reaver, kismet и aircrack: все прошло нормально, но появилось сообщение, что невозможно обновить mandb, так как там недостаточно места.

  3. ls on /: Когда я cd /;ls, /tmpкаталог - единственный каталог, который выделен зеленым цветом (bg = зеленый, fg = черный). Я думаю, что это подозрительно.

  4. Когда я удаляю .Xsessionsфайл, а затем startx: сообщения об ошибках, связанных с клавиатурой, исчезают, но клиенты AIGLX по-прежнему приостанавливаются (сервер завершает работу с ошибкой)

  5. Что я df -iговорю: Все в порядке, используется только 10% инодов.

  6. Что df -hговорит: Что??? Там написано, что корневой раздел полностью заполнен. (24 из 24 гигабайт) Я так и сделал, apt-get cleanи там все равно написано, что он полностью заполнен.

Ладно, ребята, мы все знаем, в чем проблема: root полностью заполнен. Конечно, я этого не делал. Загрузка 20 гигабайт данных заняла бы слишком много времени, чтобы я не заметил (у меня скорость загрузки 20 кбит/с). Кроме того, запись такого количества данных в виде лога или чего-то в этом роде заняла бы достаточно много времени. (Root в любом случае защищен от записи.)

Кто-то на форумах утверждал, что решил проблему с помощью pacman -Scc. Я пробовал, apt-get cleanно не получилось.

Поэтому теперь я обращаюсь к вам за помощью. Пожалуйста, подскажите, что мне следует попробовать дальше.

решение1

Когда dfсообщается, что раздел заполнен, duкоманда является следующим шагом в диагностике проблемы. Я бы cdперешел в корень файловой системы и выполнил

sudo du -smx * .[^.]* | sort -n
  • Параметр -s( --summarize) печатаетобщийразмер каждого файла/каталога.
  • Данная -mопция выводит объем дискового пространства, используемый каждым файлом/каталогом, в мегабайтах.
  • Параметр -x( --one-file-system) заставляет duоставаться на исходной файловой системе. Это исключает нерелевантную (для этой цели!) информацию, такую ​​как все файлы в /run, /sys, /devи/или /proc(спасибо, MariusMatutiae).
  • Включает [^.].*скрытые файлы, исключая родительский каталог ..).
  • Наконец, сортировка списка по номерам позволяет удобно отображать каталоги, занимающие больше всего места, в конце списка.

Затем я перехожу в каталог, занимающий больше всего места, и повторяю процесс для его подкаталогов. В конце концов вы должны найти каталог, который использует больше места, чем должен.

Кстати, /tmp/предполагается, что он доступен для записи всем (что приводит к зеленому фону). Его содержимое должно автоматически удаляться ОС регулярно – но вам может потребоваться вручную удалить старые файлы, которые не были автоматически очищены.

Лично я всегда монтирую /homeв отдельную файловую систему, и всякий раз, когда это со мной случалось, я обнаруживал, что виновником являются файлы журналов в /var/log.

Связанный контент