Форум русскоязычного сообщества Ubuntu
Страница сгенерирована за 0.042 секунд. Запросов: 23.
- Сайт
- Об Ubuntu
- Скачать Ubuntu
- Семейство Ubuntu
- Новости
- Форум
- Помощь
- Правила
- Документация
- Пользовательская документация
- Официальная документация
- Семейство Ubuntu
- Материалы для загрузки
- Совместимость с оборудованием
- RSS лента
- Сообщество
- Наши проекты
- Местные сообщества
- Перевод Ubuntu
- Тестирование
- RSS лента
© 2012 Ubuntu-ru — Русскоязычное сообщество Ubuntu Linux.
© 2012 Canonical Ltd. Ubuntu и Canonical являются зарегистрированными торговыми знаками Canonical Ltd.
Исправление Read-Only File System в Linux
21.10.2022
itpro
CentOS, Linux, Ubuntu
Один комментарий
В некоторый случаях файловая система в Linux может перейти в состояние read-only, при котором вы можете только читать данные с диска, а при попытке записи любых изменение или создании нового файла появдляется ошибка Read-only file system.
Ошибки файловой системы и опция remount-ro
Проверьте параметры монтирования дисков при загрузке Linux. Настройки монтирования файловых систем при загрузке задаются в файле /etc/fstab.
Обратите что в fstab есть строка монтирования корневой директории вида:
UUID=aaaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaa / ext4 errors=remount-ro 0 1
Параметр errors=remount-ro означает, что данная директория будет смонтирована в режиме чтения, если на файловой системе устройства обнаружены проблемы. В этом случае нужно выполнить проверку диска с помощью FSCK.
Обычные файловые системы такие как EXT4/BTRFS/XFS можно монтировать как в режиме записи, так и только для чтения (в отличии от файловых систем ISO или SquashFS, которые доступны только для чтения).
В случае обнаружения ошибок на диске вы можете использовать одну из трех опций errors=[continue|remount-ro|panic]
- continue – игнорировать ошибки,
- remount-ro – перемонтировать диск в режиме только для чтения
- panic – остановить загрузку системы
Вы можете вывести соответствие между UUID диска и именем устройства:
В данном примере вы получили, что вашему UUID соответствует устройство /dev/sda3.
Также можно имена устройства и точки монтирования с помощью команды:
Т.к. в данном примере ошибки обнаружены в корневой директории которая является точкой монтирования, вы сможете выполнить ее проверку только загрузившись с LiveCD. Для исправления ошибок файловой системы используется команда:
$ sudo fsck –y /dev/sda3
$ sudo fsck –y UUID=aaaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaa
Если вы не можете прямо сейчас выполнить проверку диска, и вы хотите немедленно вывести файловую систему из режима read-only, нужно выполниться команду:
$ sudo mount -o remount,rw /
Обязательно запланируйте проверку файловой системы на ближайшее время.
Read-only файловая система в виртуальных машинах
Файловая система раздела Linux на виртуальной машине можете перейти в read-only в случае недоступность системы хранения данных (СХД). Самый простой способ восстановить работу ОС – выполнить сброс виртуальной машины (фактически перезапуск с параметрами по умолчанию).
Может оказаться, что ВМ с Linux вообще не загружается и вам доступна только командная строка initramfs с предупреждениями:
UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY. Fsck exitrd with code 4. The root file system of /dev/sdx requires a manual fsck.
Initramfs это начальная файловая система в оперативной памяти, которая основана на tmpfs, которая содержит утилиты и скрипты, необходимые для работы с дисками, файловыми системами и тд. После запуска initramfs отобразится проблемная ситуация.
Если же ошибок нет – просто вводим exit. Иначе выполняем проверку диска:
Здесь указан том (в данной случае /dev/sda1), для которого требуется выполнить ручную проверку. С помощью следующей команды можно проверить все подключенные файловые системы:
$ fsck –A –y /dev/sda1
После этого перезагрузите ВМ.
Предыдущая статья Следующая статья
Читайте далее в разделе CentOS Linux Ubuntu
Установка KMS сервера vlmcsd на Linux для активации Windows и Office
Установка и настройка прокси сервера Squid в Linux
Мониторинг срока регистрации (освобождения) домена в Zabbix
Включаем двухфакторную аутентификацию (2FA) для SSH входа в Linux
Ubuntu read only file system как исправить
Если при попытке создать или изменить любой файл или каталог ваша ВМ пишет:
Read-only file system
То выполните следующие действия:
- Проверьте не закончился ли проект, в рамках которого предоставляется ВМ. После окончания проекта все машины переводятся в режим «только чтение».
- Если проект действующий, то скорее всего произошла ошибка файловой системы и необходимо перезагрузить машину (Как перезагрузить виртуальную машину?). После перезагрузки файловая система вернется в прежнее состояние.
- Если перезагрузка не помогла, напишите в службу поддержки support@cc.spbu.ru (см. Как правильно обратится в службу поддержки?).
© «Санкт-Петербургский государственный университет», РЦ ВЦ
Ubuntu Server- Read-only filesystem?
Всем привет, может кто подскажет путь в верном направлении
есть физический сервер на Ubuntu 20.04.3 LTS Server на нём у разрабов крутится jenkins
возникает одна и та же проблема, файловая система падает в Read-Only, после перезагрузки ос не грузится(ниже фото-извиняюсь за качество)
spoiler
после fsck /dev/mapper/. и исправления кучи ошибок, убунта поднимается, я пробовал переустанавливать ос и менял ssd, но проблема не уходит.
в логах(syslog) я не нахожу(или не вижу) как обнаружить проблему, есть там перерыв по логам почти в 6 часов, но ошибок не вижу
заранее спасибо за любые советы
- Вопрос задан более двух лет назад
- 560 просмотров
5 комментариев
Средний 5 комментариев
файловая система падает в Read-Only
Прямо посреди работы? Или все-таки при перезагрузке, потому что в ФС проблемы из-за некорректной перезагрузки?
Если первое, то можно попробовать смонтировать для логов отдельный tmpfs и при наступлении ситуации заглянуть туда — на диск-то уже ничего не запишется, а в память — без проблем.
что говорят логи операционки ??
Андрей @MoscowStyle Автор вопроса
Андрей @MoscowStyle Автор вопроса
Adamos, я верно понял вставить флешку и настроить писать логи на неё?
MoscowStyle, зачем — флешку? Tmpfs — это виртуальная ФС в памяти.
Решения вопроса 0
Ответы на вопрос 3
у админа три руки
Чтобы сильно уменьшить вероятность подобных событий, выношу из корня разделы /var и /tmp.
В результате на корневую файловую систему почти ничего не пишется, за исключением вручную запускаемых обновлений или установки нового софта, изменения настроек (а всё это делается не каждый день).
Ответ написан более двух лет назад
Комментировать
Нравится 3 Комментировать
Виктор Таран @shambler81 Куратор тега Linux
Покажите ваш фстаб ?
/etc/fstab
А потом почитайте что такое
errors = remount -ro
Собственно все что вам нужно заменить errors = remount -ro на defaults и перезагрузитья
ну и проверить диск на логические и физические ошибки.
Вернуть все на место, или так и оставить
Ответ написан более двух лет назад
Нравится 2 2 комментария
Андрей @MoscowStyle Автор вопроса
% # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # /dev/mapper/vgftpbd--p2-root / ext4 errors=remount-ro 0 1 # /boot/efi was on /dev/sda1 during installation UUID=5E34-26AD /boot/efi vfat umask=0077 0 1 /dev/mapper/vgftpbd--p2-swap_1 none swap sw 0 0
а почему возникает эта ошибка?
Виктор Таран @shambler81 Куратор тега Linux
MoscowStyle, Ошибка может быть и логической и физической.
Если о на 1 раз возникла то диск сразу переходит ro
диск, внезапное неоднократное отключение сервака от питания, кабель сата.
Ответ написан более двух лет назад
Нравится 1 6 комментариев
Андрей @MoscowStyle Автор вопроса
диск уже второй и проблема та же, с питанием всё нормально, кабель сата не проверял
MoscowStyle, ну вы же понимаете что повреждается файловая система.
Там же врятли прогеры чет спецом ломают
Попробуйте кабель сменить, порт, диск еще раз
Виктор Таран @shambler81 Куратор тега Linux
Был у меня сервак на котором диски горели как спички, сгорело 5 винтов за пол года, а потом 8 лет ни 1. Тут как повезет.
А 1 раз бывало что проблема была в биосе одного из дисков при полностью рабочем смарте и прохождение всех тестов
(3 недели поисков и 2 из них убеждение hetzner что такое физически возможно)
Один диск начинал гонять хламный поток данных между интерфейсом и биосом, забивая 100% I-o внутри диска. тем самым просаживая общий I-o диска на 99.9%
При том это периодически, не имея четких циклов, но прогон большого количества данных на запись восстанавливало работоспособность диска опять на какое-о время о 30 секунд до нескольких дней.
В итоге на шине 0 данных,
i-o диска соответственно 0
ошибок 0
а скорость чтения 300кб секунду на nvme диске
В общем проверяйте железо от дисков и проводов доконтроллеров и не крашнутая ли память ( на одном сервере некорректное завершение записи было связано с памятью).
Может сломаться че угодно
А могла быть просто логическая ошибка при отключение питания.
Тут как повезет, но точно не нужно удивляться такое вообще нормально.