В статье рассмотрен сценарий аварийного восстановления системы, когда раздел не монтируется из-за повреждения структуры inode. Описана утилита fsck, которая проверяет и исправляет целостность файловой системы (EXT4). Приведен практический пример с сервером AstraOps, где через Live-CD (SystemRescue) были выполнены проверки корневого раздела (/dev/vda1), что позволило восстановить работоспособность системы.
Если вы столкнулись с невозможностью загрузки операционной системы, одна из возможных и частых причин - это невозможность примонтировать какой-либо раздел, к примеру /home. Причин этому несколько: повреждение структуры inode из-за частых выключений «на горячую» (в том числе из-за резких скачков электроэнергии) или же банальное умирание жесткого диска. Также проблема может быть вызвана нехваткой свободных inode - в этом случае вы не сможете создавать новые файлы, однако раздел при этом смонтируется, и система загрузится.
Прежде чем приступим к решению проблемы, хотел бы вкратце рассказать про inode, что это такое.
Inode - это структура данных, в которой хранятся метаданные файла: права доступа, размер, временные метки и указатели на блоки данных на диске. Inode - это своего рода «бирка» на полке с книгами, по которой система находит содержимое файла, чтобы не перебирать каждую книгу и искать о ней информацию. В файловой системе Ext4 количество inode ограничено и задается при форматировании. Когда мы часто создаем и удаляем файлы, inode могут освобождаться не сразу, но это не мешает монтированию раздела - проблема возникает, когда структура самих inode повреждается из-за сбоев питания или ошибок диска. Если же свободные inode закончились, вы просто не сможете создать новый файл, получив ошибку «No space left on device», но система продолжит работу.
Если раздел не монтируется из-за повреждения структуры inode, операционная система обычно сама сообщает об этом при загрузке и предлагает выполнить проверку. Для этого нам достаточно выполнить одну простую команду:
fsck -y /dev/<раздел>
К примеру, раздел /home не смог примонтироваться. Командами blkid или lsblk, либо через cat /etc/fstab мы выяснили, что /home - это /dev/sda5. Значит, делаем:
fsck -y /dev/sda5
По завершению команды перезагружаемся и пользуемся дальше.
Вся сложность заключается только в доступе к терминалу. Либо через root (обычно система предлагает ввести пароль для root при неудачной загрузке для решения проблемы), либо загрузиться в режиме восстановления, войти в корень и уже выполнить проверку.
Основные ключи команды fsck:
-f- принудительное выполнение проверки, даже если файловая система помечена как «чистая»;-c- выявление в процессе проверки сбойных блоков и добавление их в список сбойных блоков;-y- автоматически отвечать «Да» на все запросы о восстановлении (рекомендуется для автоматического исправления);-a- автоматическое исправление найденных ошибок без запросов к пользователю (аналог устаревшего ключа-p).
Парадокс. Буквально вчера написал эту статью, как сегодня сервер сайта AstraOps столкнулся с этой же проблемой :) Поэтому появились скриншоты.
Загрузился я с помощью Live-CD SystemRescue.
Командой lsblk я посмотрел название разделов диска.
Операционная система размещена на разделе vda1.
Пройдемся по ней командой:
fsck -f -y /dev/vda1
Далее видим, как «фиксятся» inode раздела.
Можно прогнать и другие разделы для профилактики. Далее перезагружаемся и все работает в штатном режиме.
Это довольно частая проблема на Linux, по этому вам очень пригодиться данная статья.