Критическая ошибка смотрите лог файл или обратитесь к администратору astra linux как исправить
Обновлено: 04.07.2024
Оригинал: How to Use ‘fsck’ to Repair File System Errors in Linux
Автор: Marin Todorov
Дата публикации: 1 октября 2018 года
Перевод: А. Кривошей
Дата перевода: июль 2019 г.
Файловые системы отвечают за организацию хранения данных. Так или иначе, со временем файловая система может быть повреждена и некоторые ее части могут быть недоступны. Если ваша файловая система имеет такое несоответствие, рекомендуется проверить ее целостность.
Это можно выполнить с помощью системной утилиты fsck (file system consistency check). Эта проверка может быть выполнена автоматически во время загрузки или запущена вручную.
Когда нужно использовать fsck в Linux
Существуют разные сценарии, когда вам понадобится запустить fsck. Вот несколько примеров:
Система не загружается.
Файлы в системе поврежденны (часто вы можете увидеть ошибку ввода/вывода).
Подключенный диск (включая флэшки/SD-карты) не работает должным образом.
Опции fsck
Команда Fsck должна быть запущена с привилегиями суперпользователя (root). Вы можете использовать ее с разными аргументами. Их использование зависит от вашего конкретного случая. Ниже вы увидите некоторые из наиболее важных опций:
-A - используется для проверки всех файловых систем. Список берется из /etc/fstab.
-C - показывать индикатор выполнения.
-l - блокирует устройство, чтобы гарантировать, что никакая другая программа не попытается использовать раздел во время проверки.
-M - не проверять смонтированные файловые системы.
-N - только показывать, что будет сделано - не делать никаких реальных изменений.
-P - если вы хотите проверять файловые системы параллельно, включая корневую.
-R - не проверять корневую файловую систему. Это полезно только вместе с ‘-A‘.
-r - предоставить статистику для каждого проверяемого устройства.
-T - не показывает заголовок.
-t - исключительно указать типы файловых систем, которые будут проверяться. Типы могут быть разделены запятыми.
-V - предоставить описание того, что делается.
Как запустить fsck для исправления ошибок файловой системы Linux
Чтобы запустить fsck, вам нужно убедиться, что раздел, который вы собираетесь проверить, не смонтирован. Для этой статьи я буду использовать мой второй диск /dev/sdb, смонтированный в /mnt.
Вот что произойдет, если я попытаюсь запустить fsck на смонтированном разделе.
Чтобы избежать этого, размонтируйте раздел с помощью команды:
Теперь fsck можно запустить безопасно.
Понимание кодов выхода fsck
После запуска fsck она вернет код выхода. Эти коды можно увидеть в руководстве fsck, выполнив:
Исправление ошибок файловой системы Linux
Флаг -y автоматически даёт ответ "да" на любые запросы от fsck для исправления ошибок.
Точно так же вы можете запустить команду на всех файловых системах (без корневой):
Как запустить fsck в корневом разделе Linux
В некоторых случаях вам может потребоваться запустить fsck в корневом разделе вашей системы. Поскольку вы не можете запустить fsck на смонтированном разделе, вы можете попробовать один из следующих вариантов:
1. Принудительно использовать fsck при загрузке системы
2. Запустить fsck в режиме восстановления
Мы рассмотрим обе ситуации.
Принудительная проверка корневой файловой системы с помощью fsck при загрузке системы
Это относительно легко выполнить, единственное, что вам нужно сделать, это создать файл с именем forcefsck в корневом разделе вашей системы. Используйте следующую команду:
Во время следующей загрузки будет выполняться fsck. Если время простоя является критическим, рекомендуется тщательно спланировать эту проверку, так как если в вашей системе много используемых inode, fsck может занять некоторое, довольно значительное время.
После загрузки системы проверьте, существует ли этот файл:
Если он есть, вы можете удалить его, чтобы избежать запуска fsck при каждой загрузке системы.
Запуск fsck в режиме восстановления
Запуск fsck в режиме восстановления требует еще нескольких шагов. Сначала подготовьте систему к перезагрузке. Остановите все важные службы, такие как MySQL/MariaDB и т. д., а затем перезагрузите компьютер.
Во время загрузки удерживайте нажатой клавишу Shift, чтобы отобразилось меню grub. Выберите «Advanced options».
Затем выберите «Recovery mode».
В следующем меню выберите «fsck».
Вас спросят, хотите ли вы перемонтировать вашу корневую файловую систему. Выберите «yes».
Вы должны увидеть что-то похожее на это.
Затем вы можете вернуться к нормальной загрузке, выбрав «Resume».
Заключение
Из этого руководства вы узнали, как использовать fsck и выполнять проверки согласованности в разных файловых системах Linux. Если у вас есть какие-либо вопросы о fsck, пожалуйста, не стесняйтесь задавать их в разделе комментариев ниже.
На сегодняшний день в Linux основными службами сбора логов являются rsyslog и systemd-journald, они работают независимо друг от друга и входят в состав большинства современных дистрибутивов.
rsyslog
“auth,authpriv.* /var/log/auth.log”
“*.*;auth,authpriv.none -/var/log/syslog”
Журналы логов можно открыть любой утилитой для просмотра текста, например less, cat, tail. Откроем файл “/var/log/auth.log”
Это был пример успешного подключения по ssh.
А так выглядит неудачная попытка:
В этом файле также фиксируется выполнение команд с повышенными правами.
Откроем файл /var/log/syslog
grep 'pptpd' /var/log/syslog
Во время диагностики можно использовать утилиту tail, которая выводит последние строки в файле. Команда “tail -f /var/log/syslog” позволит наблюдать запись логов в реальном времени.
Ротация логов Linux
Запись логов происходит непрерывно и размер файлов постоянно растет. Механизм ротации обеспечивает автоматическое архивирование старых журналов и создание новых. В зависимости от правил, обработка журналов может выполняться ежедневно, еженедельно, ежемесячно или при достижении файлом определенного размера. По мере создания новых архивов, старые могут быть просто удалены или предварительно отправлены по электронной почте. Ротация выполняется утилитой logrotate. Основная конфигурация находится в файле “/etc/logrotate.conf”, также обрабатывается содержимое файлов в директории “/etc/logrotate.d/”
Новые правила можно записывать в основной файл конфигурации, но более правильным будет создание отдельного файла в директории “/etc/logrotate.d/” По умолчанию в директории уже содержится несколько файлов.
Рассмотрим файл “/etc/logrotate.d/rsyslog”, который содержит правила ротации для журналов службы rsyslog.
В начале правила указывается путь к файлу журнала, затем в фигурных скобках перечисляются директивы.
- rotate 7 - необходимо постоянно хранить 7 файлов
- daily - ежедневно будет создаваться новый файл
- compress - старые файлы необходимо архивировать.
На скриншоте видно, что в каталоге “/var/log/” находится основной журнал “syslog” и семь архивов, что соответствует правилам ротации.
Более подробное описание по настройке утилиты logrotate можно найти в мануале, выполнив команду “man logrotate”
journald
Служба сбора логов systemd-journald является частью системы инициализации systemd. Файлы журнал хранятся в директории “/var/log/journal/” в специальном формате и могут быть открыты с помощью утилиты journalctl. Формат записей такой же как у службы rsyslog.
Команда journalctl без параметров выводит на экран все записи, но учитывая, что объем журнала может достигать нескольких гигабайт, такой способ просмотра не подходит для практического применения. Рассмотрим некоторые опции утилиты.
Для более гибкого поиска опции можно совмещать. Выведем все ошибки службы pptpd
journalctl -u pptpd -p err
journalctl -S "2020-02-18 04:15" /usr/bin/sudo
Для того, чтобы узнать сколько места на диске занимают файлы журнала, выполним команду
Для ограничения объема журнала размером 1Gb выполним команду
Открытие бинарных файлов
В заключении рассмотрим несколько специальных файлов в директории “/var/log/”, в которых регистрируются попытки входа пользователей в систему. Это бинарные файлы, которые могут быть открыты только специальными утилитами.
/var/log/wtmp - содержит информацию об успешном входе пользователей в систему, для открытия используется утилита last
/var/log/btmp - в файле регистрируются все неудачные попытки входа в систему, открывается командой lastb с повышенными правами. Параметр -n определяет количество выводимых строк начиная с конца файла.
/var/log/lastlog - содержит время последнего входа для каждой учетной записи, может быть открыт одноименной утилитой lastlog
Astra может записывать лог своей работы в следующие назначения:
Описание ошибок и способы их устранения:
Состояние адаптера DVB.
Описывается несколькими значениями:
status —список флагов, описывающих состояние тюнера. Состояние, если есть сигнал SCVYL:
- SIGNAL — появляется да же при незначительном уровне сигнала
- CARRIER — found a DVB signal
- VITERBI — FEC (forward error correction) is stable
- SYNC — found sync data
- LOCK — signal locked
- signal — уровень сигнала
- snr — отношение сигнал/шум
- ber — bit error rate. important for determining the reception quality
- unc — некоррекные блоки данных. также как ber, показывает качество приема
Ошибка возникает, если количество активных подключений или открытых файлов превышают ограничение операционной системы. Для проверки текущего лимита используйте следующую команду:
где PID — уникальный идентификатор процесса. Для его поиска - выполните: ps ax | grep astra
Чтобы изменить системный лимит, выполните команду ulimit -n 65536 и перезапустите Astra. Команда присутствует в скрипте запуска init.d
Канал с указанным номером (pnr) в потоке не найден. Для проверки доступных каналов, необходимо просканировать источник.
Ошибка возникает при попытке использовать DVB адаптер, занятый другим процессом. Список адаптеров и их состояние можно проверить с помощью команды:
astra --dvbls
Пример вывода команды:.
Свободный адаптер:
Ошибка при обращении к устройству. Возможно DVB адаптер неисправен, или вам нужно произвести переустановку драйвера:
Чтобы определить, какой процесс использует адаптер, используйте следующую команду:
замените X на номер адаптера.
Ошибка возникает при попытке использовать TCP-порт занятый другим процессом. Для просмотра списка открытых портов используйте команду:
Сетевой адаптер не справляется с объемом данных, поступающих от Астры. Возможные причины:
- Проверьте настройки сетевого буфера;
- Проверьте режим работы сетевого адаптера: выполните команду ethtool eth* или mii-tool eth* . Скорость должна соответствовать типу адаптера 1Gbit, 10Gbit
- Сетевой адаптер должен быть Intel или Broadcom
- Проверьте настройки DVB-адаптеров и каналов. Если в настройках DVB адаптера установлен параметр budget=true, а в свойствах канала не указан номер канала (pnr), то будет передан весь транспондер
Ошибка в заголовке пакета с видео или аудио. Основные причины:
- Неверный ключ дешифровки;
- В случае приема потока от DVB адаптера необходимо проверить качество сигнала: astra --femon -a ADAPTER
CC-ошибка, увеличивается на 1 с каждым сбоем счетчика пакетов.
MPEG-TS поток разделяется на пакеты. Каждый пакет имеет номер со значением в диапазоне 0-15. Значение счетчика увеличивается с каждым пакетом и сбрасывается на 0 после 15 пакета.
Счетчик CC-ошибок увеличивается на 1 с каждым потерянным пакетом.
Потеря данных при приеме UDP/RTP. В Linux можно проверить с помощью команды netstat -su .
Если значение packet receive errors увеличивается, необходимо проверить настройки буфера сетевых соединений..
По возможности проведите диагностику на передающем сервере.
Слабый сигнал DVB или ошибки в сигнале. Необходимо проверить уровень сигнала и ошибки приема: astra –femon -a ADAPTER .
Дублирование потока при передаче по UDP. Несколько потоков имеют одинаковую группу мультикаста и номер порта.
Не найден ключ для дешифрования потока. Возможная причина:
Ошибка авторизации при попытке доступа к Web-интерфейсу или API.
В лог выводится так же логин и IP адрес, с которым была попытка произвести авторизацию.
Возможно, ваша лицензия была скомпрометирована или вы превысили количество серверов в лицензии.
Свяжитесь со службой поддержки.
Ошибка проверки контрольной суммы таблицы SDT.
Обычно не приводит к проблемам с изображением.
Как из консольного интерфейса можно очистить все каталоги (диски), если даже под рутом пишет «операция не разрешена»?
Стояла astra ce «орел», поставил se «смоленск» и на данный момент система не загружается: ни ce, ни se. Ни с диска (cdrom), ни с sdd
Роман,Это какой-то глюк. Было один раз. Логин - это ваше имя пользователя. Вы конечно можете это всё ввести, но иксы не стартанут. Помогает просто перезагрузка.
Виктор, у Вас получилось решить проблему? У нас такая же ситуация, ничего не помогает вообще
Шурик, вроде бы все установленно, но вот с пере установкой проблема
Андрей, попробуйте еще раз запустить dist-upgrade, по крайней мере посторное обновление помогает в 9-м апдейте вылечить ошибку с файлом fifo
Шурик,тоже самое выдает , чтение списка пакетов готово
чтение информации о состоянии готово
расчет обновлений готово
следующие пакеты устанавливались автоматически и больше не требуются
Шурик,да , под рутом, или нужно под установленным пользователем (который при установке создан)
Андрей, да, именно под ним, рут ограничен в правах. нужно под админом с высоким уровнем целостности. повышение прав для установки обновления через sudo -s и дальше монтируете всё, сто нужно и обновляете
Шурик,Спасибо , сейчас буду пробовать , да вроде бы проверка целосности проходит , пишет все хорошо
Андрей, если терминал не запускается, значит, не всё, возможно, он не обновился
Добрый день. Я работаю в школе, к нам поступили ноутбуки с Astra Linux. До этого поступила цифровая лаборатория, которая рассчитана на ОС Windows. При подключении датчиков по usb в Windows драйвера устанавливаются автоматически, возможно ли как-то их подключить в Astra Linux?
Евгений, думаю, что вам нужно связаться с производителем этой лаборатории
Читайте также: