Linux fsck unexpected inconsistency run fsck manually

/dev/sda2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

Всем привет. Столкнулся с ошибкой /dev/sda2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY на Астра 1.6 Смоленск, появляется почти на всех новых ПК после каждой перезагрузки! Подскажите в какую сторону копать чтобы найти источник проблемы. Системы обновлены до 6 версии. SSD новые также как и компы, объём 240Гб, фирма FOXLINE. Возможно что попалась партия плохих SSD ? Какие программы есть на Астру для тестирования SSD дисков?

Saniaib

New member

Спешу Вас обрадовать, никаких кроме консольной fsck . Грузитесь с live Орел, и проверьте диск.
fsck -a /dev/sda1
fsck -a /dev/sda2
fsck -a /dev/sdb1
fsck -a /dev/sdb2
Данная ошибка могла появиться из-за того, что. производитель использовал плохое ПО для заливки образа системы на SSD. Не благодарите )

DenFox2688

New member

Выполняю команду fsck -a /dev/sda2. Исправляются ошибки, а на следующий день опять такая же проблема.

Saniaib

New member

DenFox2688

New member

DenFox2688

New member

Вообщем ситуация сложная. Поставили другой новый SSD установили с диска по новой Астру и три раза перезагрузили после этого. Все три раза требовал проверку диска! Может надо найти более свежий образ 1.6 Смоленск с Астрой?

Montfer

New member

Вообщем ситуация сложная. Поставили другой новый SSD установили с диска по новой Астру и три раза перезагрузили после этого. Все три раза требовал проверку диска! Может надо найти более свежий образ 1.6 Смоленск с Астрой?

DenFox2688

New member

vladimirk1211

New member

DenFox2688

New member

DenFox2688

New member

Вложения

Николай Н.В

New member

А из консоли, командой shutdown now пробовали вылючаться ?
Возможно проблема в некорректном отключении пит.

Есть ещё такая интересная команда
sync записывает данные, буферизованные в памяти, на диск. Буферизуются, например,
измененные супер-блоки, измененные inode’ы, операции чтения и записи также откладываются .
можно попробовать выполнять sync перед отключением питания.

DenFox2688

New member

Что советуют в чате Астры в телеге:

«Это дикий глюк Астры
ЛЕЧИТСЯ СЛЕДУЮЩИМ ОБРАЗОМ.
В фстабе находишь свой диск и вместо записи при обнаружении ошибок монтировать в ридонли пишешь дефаулт.
Как то так.»

vladimirk1211

New member

Что советуют в чате Астры в телеге:

«Это дикий глюк Астры
ЛЕЧИТСЯ СЛЕДУЮЩИМ ОБРАЗОМ.
В фстабе находишь свой диск и вместо записи при обнаружении ошибок монтировать в ридонли пишешь дефаулт.
Как то так.»

Игнорируем ошибки. то есть лечим симптомы, а не причину. Это конечно должно помочь, но вот что, если действительно возникнут ошибки, которые нужно вылечить.

DenFox2688

New member

Игнорируем ошибки. то есть лечим симптомы, а не причину. Это конечно должно помочь, но вот что, если действительно возникнут ошибки, которые нужно вылечить.

Да спасибо. Я вас понял! Последствия этих ошибок проявляются например в том что не работают программы. Remmina перестаёт подключаться к серверу RDP но после лечения ошибок всё норм. Получается этим способом я просто не верну комп в рабочее состояние?

vladimirk1211

New member

Да спасибо. Я вас понял! Последствия этих ошибок проявляются например в том что не работают программы. Remmina перестаёт подключаться к серверу RDP но после лечения ошибок всё норм. Получается этим способом я просто не верну комп в рабочее состояние?

Я даже не ожидал, что у вас так явно могут проявляться ошибки. Судя по всему отключение обнаружения ошибок не ваш путь. Может какой-то модуль безопасности так влияет. Не пробовали отключить всё что можно отключить?

vladimirk1211

New member

Может на SSD прошивка кривая? Не смотрели прошивки на модель, которая у вас? Не пробовали Windows развернуть на них? Интересно как Windows себя поведет на этих SSD.

DenFox2688

New member

Я даже не ожидал, что у вас так явно могут проявляться ошибки. Судя по всему отключение обнаружения ошибок не ваш путь. Может какой-то модуль безопасности так влияет. Не пробовали отключить всё что можно отключить?

Отключил безопасность и ни чего не поменялось. Windows не пробовал ставить. Вот решение проблемы от офф тех. поддержки.

Данная ошибка сообщает о том, что файловая система повреждена и необходимо запустить утилиту fsck вручную.
Предварительно рекомендуем сделать резервные копии данных с жёсткого диска
Вы можете произвести исправление диска утилитой «fsck» с параметром «-y», пример: fsck -y /dev/sda2, после чего ошибка возвращаться не должна.
В случае если использование предложенной команды не поможет Вы можете настроить автоматическую проверку fsck при загрузке, для этого:
добавьте следующие параметры в файл /etc/default/grub, в строчке, начинающейся с GRUB_CMDLINE_LINUX_DEFAULT:
GRUB_CMDLINE_LINUX_DEFAULT=»quiet net.ifnames=0 fsck.mode=force fsck.repair=yes»
Обновите grub:
sudo update-grub
Перезагрузитесь и проверьте отработал ли fsck:
sudo tune2fs -l /dev/sda2 | grep «Last checked»
Команда покажет дату последней проверки fsck.

Источник

Исправляем ошибку: 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, необходимо попробовать перезагрузить компьютер и проверить, что ошибок больше нет и все функционирует как следует.

Источник

Automatically force fsck -fy when encountering «UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.»

I have FSCKFIX=yes in /etc/default/rcS , however, when I drove down to the site and connected a monitor to this server today, I saw this: I ran fsck.ext4 -fy /dev/sda1 and rebooted and now the server is back up and running. I understand there are situations where just blindly running fsck -fy is dangerous and can lead to data loss. However, in my case, this is a physically inaccessible server and all the data is backed up in the cloud. It is paramount that Ubuntu does any and all steps possible to try to get it online. Is there any way to force Ubuntu to always run fsck -fy , even if there are any «UNEXPECTED INCONSISTENCY» problems?

1 Answer 1

Let me preface this with a disclaimer that if you have regular issues with unclean filesystems, even though you shutdown your system cleanly, you have grave underlying problems and its possible fsck can do more harm than good !

AFAIK there is no mechanism for an automatic fsck only if inconsistencies are found.

However, you do an fsck at every boot with some kernel parameters.

GRUB_CMDLINE_LINUX_DEFAULT 

fsck.mode=force fsck.repair=yes 

to the existing things there.

yes here should do the same as your FSCKFIX=yes in /etc/default/rcS or a manual fsck -fy . Personally I think preen would be safer, but then again it would hang on startup if the disk needs some more fixes that fsck does not deem «safe » and wants user interaction.

to update grup and verify it with

grep fsck /boot/grub/grub.cfg 

or have a look with an editor in /boot/grub/grub.cfg

If you then reboot, the filesystem should be checked, you can verify the last time it was checked (should be your boot time) with

sudo dumpe2fs -h /dev/your/device | grep checked dumpe2fs 1.43.5 (04-Aug-2017) Last checked: Sun Feb 18 08:53:31 2018 

Do you confirm that this method will prevent the system to switch to busybox on boot in case of «UNEXPECTED INCONSISTENCY»? thanks.

Thanks for your help Robert. From my understanding, the system shows this busybox terminal on boot to let the user to do the fs check and approve the repair. According to tune2fs documentation, the default option for «fsck.mode» is «auto» (ensures that file system checks are done only when required) and the «fsck.repair» default value is «preen» (will only repair problems that can be safely fixed). So, don’t you think the fsck.repair set to «yes» would be enough to avoid blocking the system boot in case problem are detected on the FS. What is your opinion?

@Poltergeist no, not in this case. It depends. If you only have slight inconsistencies on your disk, then preen is enough. But as you can see in the screenshot, it detects problems than are not considered safe to automagically repair and specifically states that running it in auto or preen mode would result in the same warning and abort. The yes part overwrites this and tries to fix it anyway. So you will not be stuck on busybox on boot — if the inconsistencies can be repaired by one (manual or forced) fsck run.

Источник

При запуске linux пишет что то непонятное

/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

Не особо шарю так что помогите исправить эту проблему.

Прочитайте сообщение и сделайте что там написано. И впредь делайте это до того, как просить о помощи.

Если перепечатаешь текст с картинки (для поисковика), то подробно расскажу, что произошло и что делать.

fsck /dev/sda1 потом нажимаешь Y и если повезет то это дело закончится и после перезагрузки можно пользоваться системой дальше

2 ответа 2

Давайте построчно разберём, чего же от нас хочет 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 ) исправление ошибок; вторая выполнит перезагрузку сразу же по окончании этой операции.

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

Источник