Linux file system errors check forced

Contains a file system with errors check forced

/dev/sda1 contains a file system with errors, check forced.
/dev/sda1: Inodes that were part of corrupted orphan linked list found.

/dev/sda1: UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY.
(i. e., without -a or -p options)
fsck exited with status code 4
The root filesystem on /dev/sda1 reuires a manual fsck

Давайте построчно разберём, чего же от нас хочет Linux:

/dev/sda1 содержит файловую систему с ошибками; инициирована проверка.
/dev/sda1: были найдены inod-ы, являющиеся частью повреждённого связного списка.

/dev/sda1: НЕОЖИДАННАЯ НЕСОГЛАСОВАННОСТЬ ДАННЫХ: ЗАПУСТИТЕ fsck ВРУЧНУЮ. (т. е. без ключей -a и -p)
fsck завершила работу с кодом возврата 4
Корневая файловая система на /dev/sda1 требует ручного вызова fsck

В первых трёх строках нам сообщают, что на /dev/sda1 имеются повреждения файловой системы. Однако они не настолько страшны (inode — это заголовок файловой записи). Единственное, что потеряется при восстановлении — уникальный номер и, как результат, путь до соответствующего файла; так что он будет помещён в папку lost+found в корне /dev/sda1 . Главное, чтобы это не оказался какой-нибудь системный файл, ожидаемый во время загрузки ОС по конкретному пути.

Самой последней строкой вывода является (busybox) . Это приглашение командной строки минимальной версии консоли, внутрь которой вшит минимальный набор команд. Вариант аварийный, но его будет достаточно для «починки» раздела и перезагрузкив обычный режим.

Для «починки» введите команду:

Первая часть (аналог Windows-ского chkdsk ) выполнит проверку и безусловное (ключ -y ) исправление ошибок; вторая выполнит перезагрузку сразу же по окончании этой операции.

Кстати, вы не обесточивали компьютер прямо во время работы? Не выдёргивали диск, не отмонтировав его? Если нет, значит жёсткий диск начал «сыпаться», и по окончании проверки вам стоит как можно скорее скопировать всё его содержимое в другое место, пока ещё чего-нибудь не повредилось.

Исправляем ошибку: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

Хорошим решением будет перед следующим пунктом – сделать клон диска с данными (например с помощью clonezilla live cd), чтобы в случае, если команда fsck отработает неверно – иметь возможность их как-нибудь восстановить. И осуществлять все описание ниже действия уже с клонированным диском, чтобы с случае проблем, просто вернуть на место старый диск или же передать его тому, кто сможет восстановить данные.

Решение проблемы

Как видно из текста ошибки, проблема в том, что команд fsck не смогла корректно отработать в автоматическом режиме. Для устранения ошибки, необходимо запустить эту команду в ручном режиме. Для этого в консоли набираем:

/dev/sda1 – это тот раздел, проблемы с которым показаны в тексте ошибки “The root filesystem on /dev/sda1 requires a manual fsck”
После запуска этой команды, будут выводится различные предложения с исправлением обнаруженных ошибок, на каждом пункте необходимо будет нажать клавишу y на клавиатуре. Либо один раз нажать клавишу a и тогда все обнаруженные ошибки будут автоматически исправлены. После окончания работы fsck, необходимо попробовать перезагрузить компьютер и проверить, что ошибок больше нет и все функционирует как следует.

Error:/dev/sda5 contains a file system with errors, check forced. | Linux | Error

В этой статье объясняется, как решить проблему файловой системы /dev/sda5 с ошибками и initramfs в операционной системе Linux или Ubuntu.

Ошибка:
Я не могу открыть свою машину Linux из-за /dev/sda5 fs с ошибкой. Ниже приведен полный код ошибки в строке командной строки.

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

Шаг 1: Дождитесь появления подсказки (initramfs).

Шаг 2: Как только появится приглашение initramfs, введите следующую команду:

fsck -f /dev/sda5
Шаг 3: После выполнения команды проверки файловой системы появится окно, как показано ниже:

e2fsck 1.45.5 (070 янв-2020)
Проход 1: Проверка инодов, блоков и размеров

760051] Ошибка ввода/вывода буфера на устройстве sda5, логический блок 87556896, асинхронное чтение страниц

Ошибка чтения блока 87556896 (ошибка ввода/вывода) при получении следующего инода из сканирования. Игнорировать ошибку ? –> Здесь нужно ввести “y”, после чего будет продолжена следующая строка

Force rewrite ? yes (Введите “y”)
Тест 1 :- Проход 1: Оптимизация деревьев протяженности [ здесь иерархическое дерево файловой системы Linux]

Тест 2: – Прохождение 2: Проверка структуры каталогов [ Для проверки одной за другой ФС ].
Запись ‘system journal’ в /var/log/journal/ d2dd23rds удалила / неиспользуемый инод 19270. Очистить ? да (Введите “y”)

Мы получим то же самое вплоть до Pass 4 после нажатия на все y (“yes”), когда это будет сделано.

Вышеуказанное решение завершено, затем перезагрузите машину. Я пытаюсь открыть машину и получаю нормальное окно, как показано ниже.

Источник

Исправляем ошибку: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

Недавно столкнулся с ситуацией, когда сервер, работающий под Ubuntu перестал загружаться, просто зависал на сообщении random: crng init done
Далее я попытался загрузиться в Recovery Mode и увидел вот такую ошибку:

fsck from util-linux 2.26.2
/dev/sda1 contains a file system with errors, check forced.
/dev/sda1: Inodes that were part of a corrupted orphan linked list found.
/dev/sda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
fsck exited with status code 4
The root filesystem on /dev/sda1 requires a manual fsck
Busybox v1.22.1 (Ubuntu 1:1.22.0-15ubuntu1) built in shell (ash)
Enter ‘help’ for a list of built-in commands.
(initramfs) _

Предварительные действия

Хорошим решением будет перед следующим пунктом — сделать клон диска с данными (например с помощью clonezilla live cd), чтобы в случае, если команда fsck отработает неверно — иметь возможность их как-нибудь восстановить. И осуществлять все описание ниже действия уже с клонированным диском, чтобы с случае проблем, просто вернуть на место старый диск или же передать его тому, кто сможет восстановить данные.

Решение проблемы

Как видно из текста ошибки, проблема в том, что команд fsck не смогла корректно отработать в автоматическом режиме. Для устранения ошибки, необходимо запустить эту команду в ручном режиме. Для этого в консоли набираем:

/dev/sda1 — это тот раздел, проблемы с которым показаны в тексте ошибки «The root filesystem on /dev/sda1 requires a manual fsck»
После запуска этой команды, будут выводится различные предложения с исправлением обнаруженных ошибок, на каждом пункте необходимо будет нажать клавишу y на клавиатуре. Либо один раз нажать клавишу a и тогда все обнаруженные ошибки будут автоматически исправлены. После окончания работы fsck, необходимо попробовать перезагрузить компьютер и проверить, что ошибок больше нет и все функционирует как следует.

Источник

What should I do to force the root filesystem check (and optionally a fix) at boot?

Yesterday, one of our computers dropped to grub shell or honestly, I am unsure what shell it was when we turned on the machine. It showed that it can’t mount the root filesystem or something in this sense, because of inconsistencies. I ran, I believe:

Rebooted and the problem was gone. Here comes the question part: I already have in her root’s crontab:

@reboot /home/ruzena/Development/bash/fs-check.sh 

Thinking about it, I don’t know, why I created script file for such a short command, but anyways. Further, in the file:

So I don’t get it. How could the situation even arise? What should I do to force the root filesystem check (and optionally a fix) at boot? Or are these two things the maximum, that I can do? OS: Linux Mint 18.x Cinnamon 64-bit. fstab :

UUID=a121371e-eb12-43a0-a5ae-11af58ad09f4 / ext4 errors=remount-ro 0 1 

2 Answers 2

ext4 filesystem check during boot

Tested on OS: Linux Mint 18.x in a Virtual Machine

Basic information

/etc/fstab has the fsck order as the last (6th) column, for instance:

      UUID=2fbcf5e7-1234-abcd-88e8-a72d15580c99 / ext4 errors=remount-ro 0 1 

FSCKFIX=yes variable in /etc/default/rcS

This will change the fsck to auto fix, but not force a fsck check.

FSCKFIX When the root and all other file systems are checked, fsck is invoked with the -a option which means "autorepair". If there are major inconsistencies then the fsck process will bail out. The system will print a message asking the administrator to repair the file system manually and will present a root shell prompt (actually a sulogin prompt) on the console. Setting this option to yes causes the fsck commands to be run with the -y option instead of the -a option. This will tell fsck always to repair the file systems without asking for permission. 

If you are using journaling on your filesystem, your filesystem will never be marked dirty, so it will not normally be checked. 

Start with

Check and note last time fs was checked:

sudo tune2fs -l /dev/sda1 | grep "Last checked" 

These two options did NOT work

/etc/init.d/checkfs.sh /etc/init.d/checkroot.sh 

sudo tune2fs -l /dev/sda1 | grep "Last checked" sudo less /var/log/fsck/checkfs sudo less /var/log/fsck/checkroot 

I repeat, these two options did NOT work!

Both of these methods DID work

GRUB_CMDLINE_LINUX="fsck.mode=force" 

sudo update-grub sudo reboot 

sudo tune2fs -l /dev/sda1 | grep "Last checked" 

tune2fs' info is kept in the file system superblock 

sudo tune2fs -l /dev/sda1 | grep "Last checked" 

Summary

To force a fsck on every boot on Linux Mint 18.x, use either tune2fs , or fsck.mode=force , with optional fsck.repair=preen / fsck.repair=yes , the kernel command line switches.

Источник