Собственно, дело было так: понадобилось мне для нужд домашней лаборатории установить на виртуальную машину Ubuntu одну занятную программу под названием tpot. Установить-то я ее установила, однако, малость просчиталась в отношении нагрузки, которую могла бы выдержать система, и при первой же перезагрузке ВМ меня ожидало следующее:
Для тех, кто худо или бедно знаком с основными компонентами дистрибутивов Linux, не будет большой новостью сказать, что gdm.service (он же GNOME) являет собой ни что иное, как модуль, ответственный за отрисовку красивого графического интерфейса. Но вот, о ужас, что-то пошло не так, и вышеобозначенный сервис внезапно не смог запуститься.
Ну, справедливости ради, не только он один - немногим позже на экране появились сообщения о невозможности (failed to start) elasticsearch, kibana и других сервисов, обыкновенно запускаемых при включении системы.
На первый взгляд, картина довольно удручающая - однако, не спешите думать, что операционная система безвозвратно утеряна вместе со всеми данными. Сейчас будем чинить.
Шаг 1: Вход в терминал
Пожалуй, наилучшая из имеющихся у меня новостей состоит в том, что в ОС семейства Linux графический интерфейс нужен главным образом для красоты, в то время как подавляющая часть содержательных действий выполняется через терминал. Поэтому, одно лишь то, что у нас слетела графическая оболочка, еще не означает невозможности взаимодействия с системой.
Проблема заключается разве что в том, что пока что у нас нет и терминала, только окно с множественными сообщениями об ошибке. Для того, чтобы переключиться в режим, дозволяющий ввод и исполнение команд, требуется нажать ctrl+alt+F1.
Примечание: в зависимости от конкретного хоста это также может быть одна из клавиш F1..F6. Возможны варианты.
И вот перед нами оказывается окно с приветливым предложением ввести свои аутентификационные данные. Логинимся в систему, после чего имеем практически полный эквивалент обычного терминала с возможностью исполнения большинства команд, активации режима суперпользователя и навигации по файловой системе:
Шаг 2: Так что же все-таки произошло?
Теперь, когда у нас имеется худо-бедно полноценный доступ к системе, хотелось бы все-таки разобраться, в чем состоит причина неполадки. Конечно, существовала вероятность того, что по ходу установки tpotce были загружены какие-то конфликтующие файлы, мешающие работе GNOME, однако, гораздо более прозаичная истина состояла в том, что установщик попросту попытался установить больше вспомогательных пакетов, чем могла бы уместить файловая система, ввиду чего на компьютере не осталось памяти даже на запуск базового набора служб.
В этом было нетрудно удостовериться, вбив команду df -h, позволяющую просмотреть количество свободного места на отдельно взятых разделах диска:
Из вывода программы видно, что интересующий меня раздел /dev/sda2 (где, собственно, и "живет" изрядная часть ОС) оказался забит под завязку. По меньшей мере, причина выявлена, и остается лишь как-то расчистить пространство на диске.
Шаг 3: Очистка памяти
Первое и наиболее очевидное в таком случае действие состояло в том, чтобы попросту "снести" перегрузившую систему программу вместе со всеми ее зависимостями. Без особого труда добравшись до директории, куда был выгружен архив с tpotce (используя команды cd и ls для навигации по файловой системе) и запустив деинсталляционный скрипт (./uninstall.sh), я столкнулась с новой неожиданностью:
Горькая ирония сложившейся ситуации состояла в том, что на жестком диске не осталось памяти даже на то, чтобы запустить вышеобозначенный uninstall.sh, а, следовательно, требовалось искать обходные пути.
Вторым очевидным решением было избавиться от части установленных пакетов поодиночке, благо, те были установлены через обычный пакетный менеджер (apt) - ну, а поскольку загружено их было действительно очень много, для вывода списка недавно установленных программ я использовала команду
grep -i "installed" /var/log/dpkg.log
Однако ж, получив весьма внушительный список того, чем именно забит виртуальный жесткий диск, было выявлено еще-кое что интересное: оказалось, что apt также не работает ввиду дефицита памяти.
Далее, мною были предприняты следующие шаги:
3.1. Очистка swap
Во-первых, я попыталась освободить память подкачки:
swapoff -a && swapon -a
... что, впрочем, не возымело должного эффекта - uninstall.sh по-прежнему жаловался на дефицит свободного места на диске.
3.2. Очистка кэша пакетного менеджера
Далее, я попыталась убрать лишние файлы из кэша apt, небезосновательно подозревая, что тот мог быть забит изрядным количеством различного "мусора" - повторюсь, пока что моей задачей было не полное удаление всех свежеустановленных пакетов, а лишь очистка пространства, достаточного для запуска нужных мне программ.
sudo apt-get clean
Увы, пока что результат оставался тем же.
3.3. Ручное удаление файлов
После того, как очистка еще одного буфера
sync; echo 3 > /proc/sys/vm/drop_caches
не привела к желаемому результату, я пришла к выводу, что настало время пустить в дело тяжелую артиллерию - то есть, попросту прогуляться по файловой системе и вручную удалить (команда rm) наиболее тяжеловесные файлы.
Последнее требует определенного представления о том, как вообще устроено хранилище в дистрибутивах Linux, то есть, куда же, собственно говоря, были размещены все эти файлы. Давайте перейдем в корневой каталог (cd ~) и посмотрим, что вообще там есть:
- /bin. Базовый набор исполняемых файлов для ключевых компонентов системы... Хм, едва ли.
- /boot. Все, что связано с загрузкой ОС. Не наш случай.
- /dev. Даже не думай.
- /etc. Главным образом, файлы конфигурации - едва ли небольшой текстовый файл займет много места.
- /home. Домашний каталог пользователя. Звучит заманчиво, но я-то помню, что там ничего нет.
- /lib. Библиотеки - и вот это уже интересно, потому что последние вполне способны занять много места.
Перейдя в вышеобозначенную директорию, осматриваюсь на месте - в первую очередь меня, конечно, интересует то, какие именно файлы занимают больше всего места. Для этого использую команду du -h, где флаг -h указывает на необходимость вывода размера файлов/директорий в "человекочитабельном" (human-readable) виде.
Тут, впрочем, имеется один важный нюанс: прежде, чем радостно броситься удалять (rm) наиболее жирные файлы, необходимо убедиться, что это действительно одна из свежезагруженных библиотек, а не жизненно важный компонент самой ОС. Вся прелесть Linux состоит в том, что обладающий правами sudo пользователь имеет доступ ко всем файлам и действительно может делать с ними что угодно, что не исключает возможности ненароком "выстрелить себе в ногу" и действительно порушить всю ОС без возможности восстановления. При этом, имена у большинства библиотек не слишком-то говорящие, поэтому настоятельно рекомендую прогуглить назначение каждого кандидата на удаление, прежде чем перейти к решительным действиям.
Так или иначе, а освободив таким образом некоторое количество памяти в sda2, мне удалось наконец-то запустить деустановщик и благополучно перезагрузить систему.
Вот мы и дома.
Конечно, Ubuntu по-прежнему сетует на то, что на диске осталось критически мало места, однако, имея доступ к привычному GUI и большему количеству доступных инструментов, дальнейшей процесс очистки будет протекать гораздо легче. Так что если когда-либо вам доведется столкнуться с подобного рода проблемой, не спешите переустанавливать всю систему и помните, что отсутствие графического пользовательского интерфейса - далеко не самая худшая вещь, которая может приключиться с пользователем Linux.
Оставайтесь на связи.