Рано или поздно это случается, а именно крах системы или раздела, невозможность проверить файловую систему и т.д. Поэтому системный администратор должен знать что делать в таких ситуациях, так сказать знать как «Отче наш».
1) fsck при загрузке ОС
Когда случается сбой питания в работу вступает fsck: file system consistency check and interactive repair или если на русском, то «проверка целосности файловой системы и интерактивное восстановление» . По умолчанию проверка дисков отключена. Что бы её включить при загрузке системы, добавим такую строчку
fsck_y_enable="YES"
в файл /etc/rc.conf . В этом случае, при некорректном завершении работы сервера, будет автоматически запускаться проверка всех файловых систем.
Сама проверка состоит из 5-ти этапов:
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 5 - Check Cyl groups
На самом деле, Phase 1 ещё подразделяется на 1a и 1b . Это можно заметить только тогда, когда случился серъёзный крах.
Всё это хорошо, но есть одно НО! Когда происходит проверка файловой системы, то пока раздел не провериться, он не смонтируется и станет доступным, соответственно, увеличивается время загрузки сервера. Разработчики и это предусмотрели и сделали возможным запуск проверки в «фоне». Хотя на самом деле это только попытка, но всё же лучше, чем ничего. по умолчанию она включена. Правда по этому поводу точаться дискуссии на тему «нужно ли включать проверку в фоне или нет». Решать вам.
Есть один неприятный момент в процессе проверки ФС при загрузке. Если раздел достаточно большой, то его проверка может занять длительное время, при этом, fsck как бы зависает на каждом из этапов. Иными словами визуально непонятно, то ли идёт проверка, то ли сервер завис. Ну и при всём при этом непонятно, сколько уже проверено и сколько будет проверяться. Что бы немного облегчить жизнь системным администраторам, разработчики внедрили недокументированую возмножность. нажатие комбинации Ctrl+T показывает текущее состояние проверки: сколько уже проверено, в процентах. Если через пару минут захотите узнать опять состояние — нужно снова нажать Ctrl+T и так каждый раз (либо просто зажать и держать, тогда получите динамически обновляемые данные).
Есть несколько параметров, которые прописываются в /etc/rc.conf и касаются fsck . Ниже приведены их дефолтные значения:
fsck_y_enable="NO" # Включить проверку при запуске, если работа была завершена некорректно.
fsck_y_flags="" # Дополнительные флаги для fsck -y
background_fsck="YES" # Попытка запустить проверку в фоне
background_fsck_delay="60" # Время задержки перед запуском fsck в фоне.
fsck_y_enable="YES"
И так, вот примеры работы fsck :
— если сервер выключался корректно, то при загрузке мы увидим такое сообщение:
Nov 10 14:36:33 mail kernel: Starting file system checks:
Nov 10 14:36:33 mail kernel: /dev/da0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS
Nov 10 14:36:33 mail kernel: /dev/da0s1a: clean, 942456 free (2944 frags, 117439 blocks, 0.3% fragmentation)
Nov 10 14:36:33 mail kernel: /dev/da0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS
Nov 10 14:36:33 mail kernel: /dev/da0s1d: clean, 503428 free (60 frags, 62921 blocks, 0.0% fragmentation)
Nov 10 14:36:33 mail kernel: /dev/da0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS
Nov 10 14:36:33 mail kernel: /dev/da0s1e: clean, 2301104 free (50872 frags, 281279 blocks, 1.0% fragmentation)
Nov 10 14:36:33 mail kernel: /dev/da0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS
Nov 10 14:36:33 mail kernel: /dev/da0s1f: clean, 162210122 free (2260506 frags, 19993702 blocks, 0.5% fragmentation)
Nov 10 14:36:33 mail kernel: Mounting local file systems:
Наличие ключевой фразы FILE SYSTEM CLEAN; SKIPPING CHECKS свидетельствует о предыдущем корректном завершении.
— если некорректно, то такое
Starting background file system checks in 60 seconds.
Jan 26 18:39:19 mail kernel: Starting file system checks:
Jan 26 18:39:19 mail kernel: /dev/da0s1a: 56013 files, 201857 used, 3349718 free (1702 frags, 418502 blocks, 0.0% fragmentation)
Jan 26 18:39:19 mail kernel: /dev/da0s1d: DEFER FOR BACKGROUND CHECKING
Jan 26 18:39:19 mail kernel: /dev/da0s1f: DEFER FOR BACKGROUND CHECKING
Jan 26 18:39:19 mail kernel: /dev/da0s1e: DEFER FOR BACKGROUND CHECKING
Но такое происходит не всегда. Если попытка не увенчалась успехом, то мы увидим такое:
** /dev/ad2s1g (NO WRITE)
** Last Mounted on /var
INCORRECT BLOCK COUNT I=446041 (4 should be 0)
CORRECT? yes
INCORRECT BLOCK COUNT I=446045 (4 should be 0)
CORRECT? yes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE I=89148 OWNER=root MODE=100600
SIZE=376 MTIME=Aug 13 13:49 2006
RECONNECT? yes
CLEAR? yes
UNREF FILE I=89152 OWNER=root MODE=100600
SIZE=755 MTIME=Aug 13 13:49 2006
RECONNECT? yes
CLEAR? yes
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? yes
SUMMARY INFORMATION BAD
SALVAGE? yes
BLK(S) MISSING IN BIT MAPS
SALVAGE? yes
2242 files, 1607116 used, 973436 free (2196 frags, 121405 blocks, 0.1% fragmentation)
2) Ручной запуск fsck
Сразу замечу, что проверка делается ТОЛЬКО НА НЕ СМОНТИРОВАННОМ РАЗДЕЛЕ!
Иначе можете потерять все данные.
И так, рассмотрим только те параметры, которые часто используются. А именно
-y|-n
: этот параметр будет отвечать соответственно YES|NO
на все вопросы при возникновении несоответствий.
-B|-F
: соответственно фоновый и нефоновый режимы
-f
: проверить раздел, даже если он был отключён корректно.
fsck -y -f /dev/ad2s1g
Если запустить без параметра -y , то при проверке и нахождении несоответствий будет выдаваться вопрос, на что можно ответить Y или N . обычно отвечают Y . Не очень удобно каждый раз отвечать Y , поэтому лучше запускать с параметром Y
** /dev/ad2s1g (NO WRITE)
** Last Mounted on /var
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=446041 (4 should be 0)
CORRECT?
Есть хорошая новость: комбинация CTRL+T работает и в ручном режиме.
Рано или поздно это случается, а именно крах системы или раздела, невозможность проверить файловую систему и т.д. Поэтому системный администратор должен знать что делать в таких ситуациях, так сказать знать как «Отче наш».
1) fsck при загрузке ОС
Когда случается сбой питания в работу вступает fsck: file system consistency check and interactive repair или если на русском, то «проверка целосности файловой системы и интерактивное восстановление» . По умолчанию проверка дисков отключена. Что бы её включить при загрузке системы, добавим такую строчку
fsck_y_enable="YES"
в файл /etc/rc.conf . В этом случае, при некорректном завершении работы сервера, будет автоматически запускаться проверка всех файловых систем.
Сама проверка состоит из 5-ти этапов:
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
На самом деле, Phase 1
ещё подразделяется на 1a
и 1b
. Это можно заметить только тогда, когда случился серъёзный крах.
Всё это хорошо, но есть одно НО! Когда происходит проверка файловой системы, то пока раздел не провериться, он не смонтируется и станет доступным, соответственно, увеличивается время загрузки сервера. Разработчики и это предусмотрели и сделали возможным запуск проверки в «фоне». Хотя на самом деле это только попытка, но всё же лучше, чем ничего. по умолчанию она включена. Правда по этому поводу точаться дискуссии на тему «нужно ли включать проверку в фоне или нет». Решать вам.
Есть один неприятный момент в процессе проверки ФС при загрузке. Если раздел достаточно большой, то его проверка может занять длительное время, при этом, fsck как бы зависает на каждом из этапов. Иными словами визуально непонятно, то ли идёт проверка, то ли сервер завис. Ну и при всём при этом непонятно, сколько уже проверено и сколько будет проверяться. Что бы немного облегчить жизнь системным администраторам, разработчики внедрили недокументированую возмножность. нажатие комбинации Ctrl+T показывает текущее состояние проверки: сколько уже проверено, в процентах. Если через пару минут захотите узнать опять состояние - нужно снова нажать Ctrl+T и так каждый раз.
Есть несколько параметров, которые прописываются в /etc/rc.conf и касаются fsck . Ниже приведены их дефолтные значения:
fsck_y_enable="NO"
# Включить проверку при запуске, если работа была завершена некорректно.
fsck_y_flags=""
# Дополнительные флаги для fsck -y
background_fsck="YES"
# Попытка запустить проверку в фоне
background_fsck_delay="60"
# Время задержки перед запуском fsck в фоне.
fsck_y_enable="YES"
И так, вот примеры работы fsck :
Если сервер выключался корректно, то при загрузке мы увидим такое сообщение:
Nov 10 14:36:33 mail kernel: Starting file system checks:
Nov 10 14:36:33 mail kernel: /dev/da0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS
Nov 10 14:36:33 mail kernel: /dev/da0s1a: clean, 942456 free (2944 frags, 117439 blocks, 0.3% fragmentation)
Nov 10 14:36:33 mail kernel: /dev/da0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS
Nov 10 14:36:33 mail kernel: /dev/da0s1d: clean, 503428 free (60 frags, 62921 blocks, 0.0% fragmentation)
Nov 10 14:36:33 mail kernel: /dev/da0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS
Nov 10 14:36:33 mail kernel: /dev/da0s1e: clean, 2301104 free (50872 frags, 281279 blocks, 1.0% fragmentation)
Nov 10 14:36:33 mail kernel: /dev/da0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS
Nov 10 14:36:33 mail kernel: /dev/da0s1f: clean, 162210122 free (2260506 frags, 19993702 blocks, 0.5% fragmentation)
Nov 10 14:36:33 mail kernel: Mounting local file systems:
Наличие ключевой фразы FILE SYSTEM CLEAN; SKIPPING CHECKS свидетельствует о предыдущем корректном завершении.
Если некорректно, то такое
Starting background file system checks in 60 seconds.
Jan 26 18:39:19 mail kernel: Starting file system checks:
Jan 26 18:39:19 mail kernel: /dev/da0s1a: 56013 files, 201857 used, 3349718 free (1702 frags, 418502 blocks, 0.0% fragmentation)
Jan 26 18:39:19 mail kernel: /dev/da0s1d: DEFER FOR BACKGROUND CHECKING
Jan 26 18:39:19 mail kernel: /dev/da0s1f: DEFER FOR BACKGROUND CHECKING
Jan 26 18:39:19 mail kernel: /dev/da0s1e: DEFER FOR BACKGROUND CHECKING
Но такое происходит не всегда. Если попытка не увенчалась успехом, то мы увидим такое:
** /dev/ad2s1g (NO WRITE)
** Last Mounted on /var
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=446041 (4 should be 0)
CORRECT? yes
INCORRECT BLOCK COUNT I=446045 (4 should be 0)
CORRECT? yes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE I=89148 OWNER=root MODE=100600
SIZE=376 MTIME=Aug 13 13:49 2006
RECONNECT? yes
CLEAR? yes
UNREF FILE I=89152 OWNER=root MODE=100600
SIZE=755 MTIME=Aug 13 13:49 2006
RECONNECT? yes
CLEAR? yes
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? yes
SUMMARY INFORMATION BAD
SALVAGE? yes
BLK(S) MISSING IN BIT MAPS
SALVAGE? yes
2242 files, 1607116 used, 973436 free (2196 frags, 121405 blocks, 0.1% fragmentation)
2) Ручной запуск fsck
Сразу замечу, что проверка делается ТОЛЬКО НА НЕ СМОНТИРОВАННОМ РАЗДЕЛЕ!
Иначе можете потерять все данные.
И так, рассмотрим только те параметры, которые часто используются. А именно
-y|-n
: этот параметр будет отвечать соответственно YES|NO на все вопросы при возникновении несоответствий.
-B|-F
: соответственно фоновый и нефоновый режимы
-f
: проверить раздел, даже если он был отключён корректно.
fsck -y -f /dev/ad2s1g
Если запустить без параметра -y , то при проверке и нахождении несоответствий будет выдаваться вопрос, на что можно ответить Y или N . обычно отвечают Y . Не очень удобно каждый раз отвечать Y , поэтому лучше запускать с параметром Y
** /dev/ad2s1g (NO WRITE)
** Last Mounted on /var
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=446041 (4 should be 0)
CORRECT?
Есть хорошая новость: комбинация CTRL+T работает и в ручном режиме.
Иногда по разным причинам (в результате сбоя, некорректного завершения работы) файловые системы накапливают ошибки. Сами ошибки представляют собой «рассогласованные» структуры данных. Естественно, при возникновении такой ситуации необходимо как можно скорее привести повреждённую в порядок. С этой задачей отлично справляется утилита fsck . Она действительно очень эффективна и системные администраторы очень часто в первую очередь используют именно ее для восстановления или починки файловых систем.
Утилита fsck (F ile S ystem Consistency Check ) изначально глубоко проверяла все структуры данных подряд, т. е. целиком всю файловую систему. Для поиска ошибок она задействовала методы эвристического анализа для ускорения и оптимизации процесса поиска ошибок. Однако, даже в этом случае для больших по объёму файловых систем эта процедура могла занимать много часов.
Позднее была реализована схема оценки состояния файловой системы, в основе которой лежит признак «чистого бита файловой системы». Если происходил сбой и файловая система (ФС) некорректно демонтировалась, то в суперблоке ФС устанавливался этот бит. По-умолчанию в Linux-системах на одном из этапов загрузки системы происходит проверка файловых систем, которые зарегистрированы в файлах /etc/fstab, /etc/vfstab, а также в /etc/filesystems. Таким образом, анализируя «чистый бит» ФС во время загрузки системы утилита определяет, стоит ли проводить проверку.
Журналируемые ФС в настоящее время позволяют утилите работать только с теми структурами данных, которым действительно необходима починка или восстановление. При необходимости fsck может восстановить всю ФС целиком благодаря всё тем же журналам ФС.
Для Linux-систем довольно часто (в особенности с использованием ФС ext) проверка ФС может быть организована таким образом, что она будет проводиться при прошествии некоторого числа демонтирований, даже если ФС полностью исправны. Это особенно актуально для настольных компьютеров, которые могут выключаться/включаться каждые сутки, перезагружаться в связи с особенностью их работы и применения, а также из-за свободного к ним доступа для подключения внешних устройств. В таких случаях проверка ФС (хоть и является полезной и благоприятной процедурой), оказывается слишком частой, а потому бессмысленной.
По-умолчанию в Linux проверка ФС проводится по прошествии 20 демонтирований. Для того, чтобы изменить количество демонтирований, после которых нужна проверка ФС нужно воспользоваться командой tune2fs :
$ sudo tune2fs -с 50 /dev/sda1 tune2fs 1.44.1 (24-Mar-2018) Setting maximal mount count to 50
У команды fsck следующий синтаксис:
Fsck [параметр] -- [параметры ФС] [<файловая система> . . .]
Основные параметры:
Опция | Описание |
-A | Проверяет все ФС |
-С [ |
Показывает статус выполнения. Здесь fd – дескриптор файла при отображении через графический интерфейс |
-l | Блокирует устройство для исключительного доступа |
-M | Запрещает проверять примонтированные ФС |
-N | Показывает имитацию выполнения, без запуска реальной проверки |
-P | Проверять вместе с корневой ФС |
-R | Пропускает проверку корневой ФС. Может использоваться только совместно с опцией -A |
-r [ |
Выводит статистику для каждого проверенного устройства |
-T | Не показывать заголовок при запуске |
-t <тип> | Задаёт ФС для проверки. Можно задавать несколько ФС, перечисляя через запятую |
-V | Выводит подробное описание выполняемых действий |
Кроме основных опций для fsck существуют и специфические, зависящие от выполняемой задачи и/или ФС. Об этом более подробно можно прочитать в соответствующих страницах , используя команду man fsck . В содержании основного руководства для утилиты (в разделе «SEE ALSO») есть ссылки на другие страницы, например fstab(5), mkfs(8), fsck.ext2(8), fsck.ext3(8) и т. д. Информацию по этим ссылкам можно просматривать выполняя команду man с соответствующими параметрами, например man fsck.ext3.
В следующей таблице приводятся дополнительные (специальные), а также наиболее часто используемые опции, позволяющие использовать команду с максимальной гибкостью и эффективностью:
Опция | Описание |
-a | Устаревшая опция. Указывает исправлять все найденные ошибки без одобрения пользователя. |
-r | Применяется для файловых систем ext. Указывает fsck спрашивать пользователя перед исправлением каждой ошибки |
-n | Выполняет только проверку ФС, без исправления ошибок. Используется также для получения информации о ФС |
-c | Применяется для файловых систем ext3/4. Помечает все повреждённые блоки для исключения последующей записи в них |
-f | Принудительно проверяет ФС, даже если ФС исправна |
-y | Автоматически подтверждает запросы к пользователю |
-b | Задаёт адрес суперблока |
-p | Автоматически исправлять найденные ошибки. Заменяет устаревшую опцию -a |
Для самой типичной ситуации, характерной для случаев, когда нужно восстановить (а точнее «починить») ФС, например на устройстве /dev/sdb2, следует воспользоваться командой:
$ sudo fsck -y /dev/sdb2
Здесь опция -y необходима, т. к. при её отсутствии придётся слишком часто давать подтверждение. Следующая команда позволит произвести принудительную проверку ФС, даже в том случае, если она исправна:
$ sudo fsck -fy /dev/sdb2
Одной из самых полезных является опция, позволяющая помечать повреждённые сектора и эта же опция используется чаще всего. Обычно такие ситуации (с повреждёнными секторами) возникают после сбоев, вызванных нештатным отключением электропитания:
$ sudo fsck -c /dev/sdb2
Работу файловыми системами нужно проводить, когда они отмонтированны от разделов. Однако, если возникает ситуация, когда нужно всё же произвести проверку на примонтированных ФС, то перед тем как использовать команду fsck с соответствующей опцией, нужно сначала перемонтировать нужную ФС в режиме «только для чтения»:
$ sudo mount remount,ro /dev/sdb2 $ sudo fsck -fy /dev/sdb2
Для указания, какую ФС использовать для раздела:
$ sudo fsck -t ext4 -y /dev/sdb2
Если fsck не справляется с исправлением/починкой ФС (что случается очень редко), то это может быть из-за повреждённого суперблока ФС. Его также можно восстановить, поскольку для суперблоков создаются их резервные копии. Но сначала нужно узнать, по каким адресам эти копии записывались, а затем попытаться восстановить суперблок из одной их резервных копий:
$ sudo fdisk -l $ sudo mkfs -t ext4 -n /dev/xvdb1 $ sudo fsck -b 163840 /dev/xvdb1
Команда -l упомянута в данном примере для наглядности того, что сначала нужно представлять, с каким устройством работать, т. к. она выводит список (в данном выводе опущен) доступных разделов. Команда mkfs предназначена для создания ФС, но с опцией -n её можно использовать для получения информации о ФС, в том числе и о расположении суперблоков. Следует следить за тем, чтобы ключом -t для mkfs задавалась соответствующая фактическому состоянию файловая система, в данном случае ext4.
В данной статье мы рассмотрели работу и использование утилиты fsck. Как видно из статьи использование утилиты не предоставляет большой сложности. А возможности по проверки и восстановлению файловых систем в Linux у нее довольно большие, поэтому знание этой утилиты системному администратору просто необходимы.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter .
Из-за различных неполадок или неожиданного отключения компьютера файловая система может быть повреждена. При обычном выключении все файловые системы монтируются только для чтения, а все не сохраненные данные записываются на диск.
Но если питание выключается неожиданно, часть данных теряется, и могут быть потерянны важные данные, что приведет к повреждению самой файловой системы. В этой статье мы рассмотрим как восстановить файловую систему fsck, для нескольких популярных файловых систем, а также поговорим о том, как происходит восстановление ext4.
Как вы знаете файловая система содержит всю информацию обо всех хранимых на компьютере файлах. Это сами данные файлов и метаданные, которые управляют расположением и атрибутами файлов в файловой системе. Как я уже говорил, данные не сразу записываются на жесткий диск, а некоторое время находятся в оперативной памяти и при неожиданном выключении, за определенного стечения обстоятельств файловая система может быть повреждена.
Современные файловые системы делятся на два типа - журналируемые и нежурналируемые. Журналиуемые файловые системы записывают в лог все действия, которые собираются выполнить, а после выполнения стирают эти записи. Это позволяет очень быстро понять была ли файловая система повреждена. Но не сильно помогает при восстановлении. Чтобы восстановить файловую систему linux необходимо проверить каждый блок файловой системы и найти поврежденные сектора.
Для этих целей используется утилита fsck. По сути, это оболочка для других утилит, ориентированных на работу только с той или иной файловой системой, например, для fat одна утилита, а для ext4 совсем другая.
В большинстве систем для корневого раздела проверка fsck запускается автоматически, но это не касается других разделов, а также не сработает если вы отключили проверку.
В этой статье мы рассмотрим ручную работу с fsck. Возможно, вам понадобиться LiveCD носитель, чтобы запустить из него утилиту, если корневой раздел поврежден. Если же нет, то система сможет загрузиться в режим восстановления и вы будете использовать утилиту оттуда. Также вы можете запустить fsck в уже загруженной системе. Только для работы нужны права суперпользователя, поэтому выполняйте ее через sudo.
А теперь давайте рассмотрим сам синтаксис утилиты:
$ fsck [опции] [опции_файловой_системы] [раздел_диска]
Основные опции указывают способ поведения утилиты, оболочки fsck. Раздел диска - это файл устройства раздела в каталоге /dev, например, /dev/sda1 или /dev/sda2. Опции файловой системы специфичны для каждой отдельной утилиты проверки.
А теперь давайте рассмотрим самые полезные опции fsck:
Это были глобальные опции утилиты. А теперь рассмотрим опции для работы с файловой системой, их меньше, но они будут более интересны:
Теперь мы все разобрали и вы готовы выполнять восстановление файловой системы linux. Перейдем к делу.
Допустим, вы уже загрузились в LiveCD систему или режим восстановления. Ну, одним словом, готовы к восстановлению ext4 или любой другой поврежденной ФС. Утилита уже установлена по умолчанию во всех дистрибутивах, так что устанавливать ничего не нужно.
Если ваша файловая система находится на разделе с адресом /dev/sda1 выполните:
sudo fsck -y /dev/sda1
Опцию y указывать необязательно, но если этого не сделать утилита просто завалит вас вопросами, на которые нужно отвечать да.
Обычно эта команда справляется со всеми повреждениями на ура. Но если вы сделали что-то серьезное и повредили суперблок, то тут fsck может не помочь. Суперблок - это начало файловой системы. Без него ничего работать не будет.
Но не спешите прощаться с вашими данными, все еще можно восстановить. С помощью такой команды смотрим куда были записаны резервные суперблоки:
sudo mkfs -t ext4 -n /dev/sda1
На самом деле эта команда создает новую файловую систему. Вместо ext4 подставьте ту файловую систему, в которую был отформатирован раздел, размер блока тоже должен совпадать иначе ничего не сработает. С опцией -n никаких изменений на диск не вноситься, а только выводится информация, в том числе о суперблоках.
Теперь у нас есть шесть резервных адресов суперблоков и мы можем попытаться восстановить файловую систему с помощью каждого из них, например:
sudo fsck -b 98304 /dev/sda1
После этого, скорее всего, вам удастся восстановить вашу файловую систему. Но рассмотрим еще пару примеров.
Проверим файловую систему, даже если она чистая:
sudo fsck -fy /dev/sda1
Или еще мы можем найти битые сектора и больше в них ничего не писать:
sudo fsck -c /dev/sda1
Вы можете указать какую файловую систему нужно проверять на разделе, например:
sudo fsck -t ext4 /dev/sdb1
С помощью флага -A вы можете проверить все файловые системы, подключенные к компьютеру:
Но такая команда сработает только в режиме восстановления, если корневой раздел и другие разделы уже примонтированы она выдаст ошибку. Но вы можете исключить корневой раздел из проверки добавив R:
sudo fsck -AR -y
Или исключить все примонтированные файловые системы:
Также вы можете проверить не все файловые системы, а только ext4, для этого используйте такую комбинацию опций:
sudo fsck -A -t ext4 -y
Или можно также фильтровать по опциям монтирования в /etc/fstab, например, проверим файловые системы, которые монтируются только для чтения:
sudo fsck -A -t opts=ro
Раньше я говорил что нельзя. Но если другого выхода нет, то можно, правда не рекомендуется. Для этого нужно сначала перемонтировать файловую систему в режим только для чтения. Например:
sudo mount -o remount,ro /dev/sdb1
А теперь проверка файловой системы fsck в принудительном режиме:
sudo fsck -fy /dev/sdb1
Если вы не хотите ничего исправлять, а только посмотреть информацию, используйте опцию -n.
Пришлось и мне столкнуться с данной проблемой. Мой один товарищ, у которого установлена Убунту на старенький ноутбук ASUS, и который просто не хочет хоть иногда включать мозги, обратился ко мне с такой проблемой. На его ноуте установлена новая Убунту 12.10 и очень часто система просто не хочет грузиться, выбрасывая в черный экран, либо застывая на фиолетовом фоне. А вот в последнее время начало выскакивать такое вот сообщение, что-то типа «Операционная система не смогла загрузиться. Выберите для дальнейших действий нужную клавишу…» И дальше идет описание, что нужно нажать. Я уже точно не помню, какие клавиши предлагает нажать система, но смысл такой, что для автоматического исправления ошибок нажмите такую-то клавишу, для ручной отладки другую, и чтобы игнорировать это сообщение предлагается нажать третью кнопку. Автоматическое исправление ошибок ни к чему не приводило и загрузка операционной системы так и не доходила до логического завершения. Вот и решил я попробовать знаменитую команду fsck .
Для начала нужно загрузиться либо с загрузочной флешки с Ubuntu (Lubuntu, Xubuntu, Kubuntu и т.д.), либо с диска Ubuntu Live CD. Теперь нам нужно узнать, какой именно раздел с Убунту нам нужно просканировать для исправления файловой системы. Запускаем Терминал (Ctrl-Alt-T) и выполняем команду:
sudo fdisk -l
Данная команда покажет нам все диски, флешки, которые примонтированы к системе. Я приведу пример с моим личным компьютером, а не с ноутбуком приятеля. Вот, что вышло у меня:
ubuntu@ubuntu:~$ sudo fdisk -l
Disk /dev/sda: 640.1 GB
, 640135028736 bytes
255 heads, 63 sectors/track, 77825 cylinders, total 1250263728 sectors
Disk identifier: 0x0009d6f7
/dev/sda1 * 2048 61442047 30720000 83 Linux
/dev/sda2 61442048 73730031 6143992 82 Linux swap / Solaris
/dev/sda3 73730048 1250263039 588266496 83 Linux
Disk /dev/sdb: 500.1 GB
, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xb9ff6f01
Device Boot Start End Blocks Id System
/dev/sdb1 * 16065 100197404 50090670 83 Linux
/dev/sdb2 105322201 976771071 435724435+ 5 Extended
/dev/sdb3 100197405 105322139 2562367+ 82 Linux swap / Solaris
/dev/sdb5 105322203 832110591 363394194+ 7 HPFS/NTFS/exFAT
/dev/sdb6 832112640 860755218 14321289+ 83 Linux
/dev/sdb7 860758016 862613503 927744 82 Linux swap / Solaris
/dev/sdb8 862615552 976771071 57077760 83 Linux
Partition table entries are not in disk order
Disk /dev/sdc: 8115 MB
, 8115978240 bytes
250 heads, 62 sectors/track, 1022 cylinders, total 15851520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xc3072e18
Device Boot Start End Blocks Id System
/dev/sdc1 * 32 15847625 7923797 b W95 FAT32
Как видно из вывода команды sudo fdisk -l , у меня имеются 2 жестких диска (sda)640 Гб и (sdb)500 Гб, а также флешка (sdc)8Гб, с которой я собственно и загружался. Я знаю, что моя основаня система с Убунту 12.04 находится на диске sda, а раздел с операционной системой соответственно называется sda1.
Теперь когда мы знаем раздел, который нужно сканировать, можно собственно приступить к его проверке. В Терминале:
sudo fsck -y -f -c /dev/sda1
если увидете ошибку, то скорее всего нужно отмонтировать данный раздел:
sudo umount /dev/sda1
Ключи и параметры команды fsck:
y - всегда отвечать yes на все вопросы (имеется альтернатива: ключ p - начинает проверку в полностью автоматическом режиме);
f - принудительная проверка файловой системы (даже если файловая система помечена как полностью работоспособная)
c - ищет битые блоки (bad blocks), а после отмечает их соответствующим образом
/dev/sda1 - устройство или раздел, которые нужно проверить. Хотя команда может иметь и другой вид. Например:
sudo fsck -p /dev/sda1
В данном случае добавлен только ключ -p. Вы просто почитайте о всех ключах команды fsck и добавляйте именно нужные вам ключи. Чтобы узнать о всех возможностях программы введите в Терминале:
man fsck
Вот, что выдал Терминал после проверки:
ubuntu@ubuntu:~$ sudo fsck -y -f -c /dev/sda1
fsck from util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
Checking for bad blocks (read-only test): 0.00% done, 0:00 elapsed. (0/0/0 errdone
/dev/sda1: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information