Ubuntu 22 не загружается в графический режим, диск на 100%, но 1.9 ГБ свободно.

Вопрос или проблема

Ubuntu 22.04 6.8.0-52-generic на Framework Laptop

Моя система сказала, что у меня заканчивается место (хроническая проблема), поэтому я удалил отключенные (устаревшие) снэпы. При попытке это сделать мне не удавалось удалить некоторые из них, потому что система говорила, что они обновляются. Я удалил другие и вернулся к ним позже, успешно удалив их.

После перезагрузки система зависла с сообщением:

/dev/nvme0n1p2: clean, 278464/3055616 files, 11924033/12207104 blocks

Я выключил и снова включил, коротко появился экран загрузки, затем снова зависло с тем же сообщением. Когда я нажал кнопку питания, он показал экран загрузки и выключился. Экран загрузки выглядит так:

Framework
  spinning thingy
  Ubuntu

Перезагрузился, используя <esc>, чтобы получить расширенные параметры загрузки и загрузился в режиме восстановления.

fsck:
  /lib/recovery-mode/recovery-menu: line 80  /etc/default/rcS: No such file or directory
  fsck from util-linux 2.37.2
  /dev/nvme0n1p2 is mounted.
  e2fsck: Cannot continue, aborting
system summary:
  === General Information ===
  System Mode: Read/Write mode
  CPU information: 8x4800MHz
  Network connectivity: none
  === Detailed disk usage ===
  Filesystem      Size  Used Avail Use% Mounted on
  tmpfs           1.6G  1.5M  1.6G    1% /run
  /dev/nvme0n1p2   46G   45G     0  100% /
  tmpfs           7.8G     0  7.8G    0% /dev/shm
  tmpfs           5.0M  4.0K  5.0M    1% /run/lock
  ef1varfs        184K  112K   68K   63% /sys/firmware/efi/efivars
  /dev/nvme0n1p4  366G   52G  295G   15% /home
  ...
  === System Database (APT) ===
  Database is consistent: yes (good)
clean:
  Trying to find packages you don't need (apt-get autoremove), please review carefully
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  0 upgrades, 0 newly installed, 0 to remove and 33 not upgraded
root:
# du --max-depth=1 /
...
54468596 /home     I thought it's not supposed to cross device boundaries?
...
du: cannot access '/proc/1714/task/1714/fd/4': No such file or directory
du: cannot access '/proc/1714/task/1714/fdinfo/4': No such file or directory
du: cannot access '/proc/1714/fd/3': No such file or directory
du: cannot access '/proc/1714/fdinfo/3': No such file or directory
...
21195164 /var
...
100932628 /

Затем я очистил файлы в /var/spool/cups, /var/log (journalctl –vacuum-time=3d) и /var/cache (apt-get clean). df все еще показывает 100%:

# df /
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/nvme0n1p2 47745772 45831444         0 100% /

Перезагрузка все еще зависает на том же месте.

Перезагрузка, <esc> немного позже, показывает:

...
  scroll of startup options
          Starting GNOME display manager
  [  OK  ] Created slice Slice /system/systemd-backlight.
           Starting Load/Save Screen Backlight Brightness of backlight:intel_backlight...
  [FAILED] Failed to start GNOME display manager
  See 'systemctl status gdm.service' for details.
  [  OK  ] Finished Load/Save Screen Backlight Brightness of backlight:intel_backlight...
  ...
  [  OK  ] Stopped GNOME display manager
           Starting detect the available GPUs and deal with any system changes...
  [  OK  ] Finished detect the available GPUs and deal with any system changes...
           Starting GNOME display manager
  [FAILED] Failed to start GNOME display manager
  See 'systemctl status gdm.service' for details.
  [  OK  ] Stopped GNOME display manager
           Starting detect the available GPUs and deal with any system changes...
  [  OK  ] Finished detect the available GPUs and deal with any system changes...
           Starting GNOME display manager
  [FAILED] Failed to start GNOME display manager
  See 'systemctl status gdm.service' for details

Перезагрузка, <esc>

...
  [  OK  ] Started Userspace Out-Of-Memory (OOM) Killer.
  systemd-oomd.service
Перезагрузка, <esc>
  выберите root:
    # systemctl status gdm.service
    gdm.service - GNOME display manager
       Loaded: loaded (/lib/systemd/system/gdm.service: static)
       Active: inactive (dead)

Вопросы:

  1. Не запускается ли диспетчер дисплея из-за нехватки свободного места на диске? Диск показывает, что доступно 1914328 блоков по 1К, что составляет 1,9Гб. Этого недостаточно для запуска?
  2. Могут ли жалобы на /proc/1714 быть связаны с проблемой? Как их устранить?
  3. Ответственен ли киллер недостатка памяти (OOM) за то, что диспетчер дисплея не запускается?
  4. Следующие шаги?

Я смотрел статьи, предлагающие проблемы с драйвером дисплея для nvidia, но это не графическая карта nvidia.

/var/lib/snapd/cache была не пуста. Я сначала думал, что все файлы имеют счетчик ссылок на inode равный 2, поэтому предполагал, что удаление не повлияет. Однако оказалось, что у некоторых файлы счетчик inode равен 1, поэтому удаление этих файлов снизило использование диска до 83%, и GNOME Display Manager тогда запустился.

Для вопроса №1, 1.9G действительно недостаточно для запуска GNOME Display Manager.

Я не знаю об ответах на вопросы 2 и 3.

Ответ или решение

Ваш запрос описывает весьма сложную ситуацию, связанную с загрузкой Ubuntu 22.04 на ноутбуке Framework. Проблема проявляется в неспособности системы загрузить графический интерфейс, выдает ошибку, и диск заполнен на 100%, хотя показывает наличие 1.9 ГБ свободного места. Рассмотрим ситуацию более детально.

Теория (Theory):
Ваши симптомы указывают на несколько потенциальных проблем:

  1. Недостаток свободного пространства. Несмотря на то, что система указывает наличие 1.9 ГБ, Linux требует достаточно места для работы различных служб и временных файлов, создаваемых во время работы системы. Это может включать в себя журналы, кеши, обновления и процессы, которые начинают работать при каждом запуске. В достаточной степени загруженный корневой раздел может приводить к разнообразным проблемам, включая сбой запуска графического менеджера GNOME.

  2. Проблемы с файловой системой. Сообщение о "clean" на экране указывает на то, что файловая система проверена и не содержит ошибок. Но тем не менее, низкий уровень доступного пространства все равно может мешать нормальной работе. Удаление файлов в корневом разделе, даже если у них есть только одна ссылка (inode count равен 1), может помочь освободить значительное количество места, как вы уже смогли заметить.

  3. Ошибка в определении доступных блоков памяти. На некоторых системах могут возникать ошибки с отображением реально доступных блоков, которые могут вводить в заблуждение пользователей.

Пример (Example):
Из вашего опыта видно, что проблема с запуском дисплейного менеджера решилась после освобождения пространства в директории /var/lib/snapd/cache. Это указывает на то, что доступного места в корневом разделе действительно не хватало для старта GNOME Display Manager.

Применение (Application):
Теперь перейдем к вашему конкретному случаю и рекомендациям:

  1. Освобождение дискового пространства:

    • Убедитесь, что на корневом разделе остается как минимум 10% свободного пространства. Это правило поможет избежать подобных проблем в будущем.
    • Используйте команды apt-get autoremove и apt-get clean для удаления неиспользуемых пакетов и кеша.
    • Удалите или переместите крупные журналы и кеши, как вы это сделали с помощью journalctl --vacuum-time=3d.
  2. Проверка состояния службы:

    • Команда systemctl status gdm.service даст более подробную информацию о состоянии дисплейного менеджера GNOME и возможных ошибках.
    • Проверьте другие службы, которые могут не запускаться из-за нехватки ресурсов или других проблем, используя команду systemctl.
  3. Анализ ошибок загруженной системы:

    • Несмотря на то, что вопрос о /proc/1714 связан с временными процессами, он может указывать на проблемы в системе. Обычно, ошибки этого вида можно игнорировать, но если они продолжаются, рекомендуем исследовать глубже используя dmesg для анализа системных сообщений.
  4. Память и OOM Killer:

    • Появление OOM Killer может указывать, что в системе заканчивается оперативная память, что также может мешать запуску графического интерфейса. Рекомендуется проверить использование памяти командами free -h или htop.

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

Оцените материал
Добавить комментарий

Капча загружается...