Сбор диагностической информации при проблемах установки или загрузки

Сразу: включите логирование на уровне ядра и системных сервисов до воспроизведения проблемы. Без этого – всё в пустоту. В Red OS используйте journalctl --no-pager -b -1 для получения журнала предыдущей загрузки. Это отправная точка, где видно, как именно всё пошло наперекосяк.

Сценарий: система не поднимается. Подгружайтесь в режиме восстановления, монтируйте корень вручную:

mount /dev/sdXn /mnt && chroot /mnt

Далее – смотрим /var/log/messages, /var/log/boot.log, dmesg. Но главное – journalctl -xe в пределах именно того сеанса, в котором сбой. Не путайте его с текущим.

Не запускается служба? Выполните systemctl status имя-сервиса и journalctl -u имя-сервиса. Часто виновник – не права доступа, а отсутствие нужной зависимости. Пример: служба требует сокета, а тот не активен. Или SELinux мешает. Проверьте getenforce и ausearch -m avc.

Важно: не трогайте конфиги до получения полной картины. Удаление и переустановка – не диагностика, а лотерея.

Red OS специфичен: syslog по умолчанию может отсутствовать. Всё в journald. Используйте фильтры: journalctl _PID=1234, journalctl _COMM=имя. Это упрощает анализ многопоточных сбоев.

Файловая система ушла в readonly? Ищите в dmesg ключевые слова EXT4-fs error. Часто виноваты сбои питания или проблемы с диском. Проверяйте SMART:

smartctl -a /dev/sdX

Внимание! Не игнорируйте модули ядра. Сбой может вызывать драйвер, которого не видно напрямую в логах. Используйте lsmod и modprobe -r для проверки подозрительных компонентов.

Red OS не терпит невнимательности. Любой сбой – это следствие. Убирайте эмоции, логируйте всё, изолируйте переменные. Если вы не видите проблему – это не значит, что её нет. Она затаилась.

Как собрать логи установщика для диагностики сбоев

Сначала смотрим на каталог /var/log. Если ставили через графику – проверяем /var/log/anaconda. Там лежат anaconda.log, program.log, storage.log, x.log. Именно они содержат всё мясо. Хотите понять, почему система внезапно решила не вставать – ищите там.


mkdir /mnt/usb
mount /dev/sdb1 /mnt/usb
cp /var/log/anaconda/* /mnt/usb/
umount /mnt/usb


Если установщик вылетает до запуска GUI – проверяйте /tmp и /run. Часто /tmp/packaging.log или /run/install/repo.log может указать точку обрыва.

Внимание! Если логи стерлись после перезагрузки – значит установка ушла в RAM-диск. Снимите дамп live-сессии через rsync до ребута!

В Red OS характерна особенность – инсталлятор может писать прямо в journalctl. Проверяйте через:

journalctl -b -1 | grep anaconda

Бывает, что модуль репозитория не тянет зависимости – тогда в storage.log будет куча ошибок вида Missing package и Failed dependency. Расшифровка простая: ищите отвалившийся источник, недоступный .repo или кривой Kickstart.

Важно помнить: Anaconda логирует не всё. Иногда спасает только запуск установки с параметром inst.debug. Тогда увидите полную трассировку ошибок, в том числе из Python-скриптов установщика.

Ну а если всё висит на «Начало установки» и больше ни звука – смотрите x.log. Часто виноват графический драйвер или раскладка, особенно при нестандартных мониторах и KVM-переключателях.

Не теряйтесь. Логи – это черный ящик Red OS. Там всё, от начала до взрыва. Главное – не упустить момент и не дать системе стереть улики.

Какие системные данные нужны при сбоях запуска приложения

Текущая загрузка системы: top -bn1 | head -n 20. Если приложение стартует медленно или зависает – CPU, I/O или память перегружены. Проверяем.

Не забудьте про SELinux. В Red OS он включен по умолчанию. sestatus + ausearch -m avc -ts recent. Запрет по политике? Бывает. Чаще, чем думают.

ldd /путь/к/приложению покажет, есть ли битые или отсутствующие зависимости. Часто виноваты именно они. Не rpm, а именно ldd.

ls -laZ /путь/к/приложению. Метка контекста? Несовпадение? Пиши в журнал, сразу.

Внимание! Никогда не доверяй просто «работает у других». Смотри, в каком контексте запускается. systemctl status имя-сервиса покажет многое. Особенно строки с Environment и ошибки ExecStart.

А что в переменных среды? printenv. Иногда всё рушится из-за PATH, LD_LIBRARY_PATH или отсутствия LANG. Неожиданно? Да. Реально? Постоянно.

Проверь запущенные службы и сокеты: systemctl list-units --type=service, ss -tulnp. Порт занят? Демон уже запущен в другом экземпляре? Это не баг, это твоя ошибка.

Состояние файловой системы: df -h и mount. Приложение пишет в /var? А там tmpfs на 100Мб. Дальше понятно.

В Red OS есть особенность – systemd-таймеры, отрабатывающие на ранних стадиях. systemctl list-timers. Иногда именно они конфликтуют с ранним запуском.

Важно помнить: без strace и lsof – диагностика не полная. Стартуешь с strace -f -o log.txt ./имя_бинарника. Читаешь лог. Видишь, где отваливается. Бывает на первом же системном вызове.

Последний контрольный выстрел – rpm -V имя-пакета. Удивительно, но изменённый бинарник – не редкость. Кто правил? Когда? Почему? Не спрашивай. Ищи. Логируй. Рекаверь.

Способы воспроизведения ошибки для отправки в техническую поддержку

Повторите действия, вызвавшие сбой. Не меняйте среду. Не обновляйте пакеты. Оставьте всё как есть. Цель – получить тот же результат, не исправляя ничего до фиксации.

Проверьте: та же ли ошибка воспроизводится с другим пользователем, в другой сессии. Используйте script для записи всего сеанса:

script /tmp/session.log

Выполните команду. Завершите exit. Файл /tmp/session.log – точная копия терминального диалога.

Внимание! Не редактируйте лог. Даже если кажется, что это мелочь. Поддержке важна каждая строчка.

Отключите сторонние репозитории. Иногда вина на них. Проверка:

dnf repolist all

Оставьте только официальные источники. Повторите сбой. Разница есть? Зафиксируйте.

Сделайте снимок состояния системы. Утилита rpm -qa --last покажет последние установленные компоненты. Иногда виновник – свежий пакет.

Минимизируйте пример. Удалите лишнее. Если сбой при старте службы, проверьте вручную:

systemctl start имя_сервиса
journalctl -xeu имя_сервиса

Журнал – ядро понимания. Без него вы – слепы.

Важно помнить: чем проще путь до сбоя, тем быстрее поддержка поймет суть проблемы. Не усложняйте.

Если ошибка в графике – запустите сессии через startx и проверьте ~/.xsession-errors. Иногда там вся правда. Часто – неожиданная.

Заблокируйтесь на одной версии ядра. Проверьте с предыдущей:

grubby --info=ALL
grubby --set-default=/boot/vmlinuz-имя

Если баг только на новом ядре – bingo. Это уже почти решение.

При нестабильной сети – сохраните дамп сессии:

curl -v http://адрес-пакета.rpm > /dev/null 2>&1 | tee curl-debug.log

Такой лог иногда решает всё. С первого взгляда.

Всё это – фундамент. Без этого даже гуру техподдержки не смогут помочь. Действуйте точно. Без эмоций. Только факты. Только консоль. Только Red OS.