RHEL 7.3 Error in service module при логине

где искать подробности загрузки служб?

В логах.

Понятно) А куда смотреть, поясните для новичка?

В поиске логи systemd смотрят из системы journalctl’ем, что в моем случае невозможно.

Почему невозможно? Загрузитесь в однопользовательском режиме и смотрите.

Вангую, что контекст безопасности как-то испорчен. Попробуйте временно отключить SELinux.

На настройки GRUB стоит неизвестный мне пароль, использовать ‘e’ не могу. Есть способ его снять?

При загрузке c LiveCD разделы подключаются, п

GRUB запрашивает Enter Username: авторизованного пользователя я не знаю, но ни известный пользователь, но root не подходят.

Очевидно, я должен добавить запись аналогичную основной но с опцией single mode в /boot/grub2/grub.cfg Подскажите как это сделать?

В поиске логи systemd смотрят из системы journalctl’ем, что в моем случае невозможно.

Можно собрать файловую систему и за-chroot-иться в неё. Но да, journal - зло. :-)

Вроде собираю разделы верно, но journalctl выводит пустой журнал. Single mode это выход в моем случае, пока не понял как обойти…

SELinux отключен изначально, похоже дело не в нем

В итоге отредактировал конфиг GBUB2 на /boot - закомментил секцию, где устанавливается юзер и пароль. Добавлением rd.break получил консоль.

Но в journalctl -list-boots вижу только одну текущую загрузку..

Журналы можно открывать явным указанием конкретного файла. Но перед этим надо настроить их фиксацию на диск.

Итого: 1) man journald.conf , параметр «Storage=»

2) Воспроизведение проблемы

3) Чтение ранее заархифированного журнала (путь зависит от монтирования)

journalctl --file /var/log/journal/<hash>/<name>.journal

Установил Storage=persistent, но /var/log/journal не появляется. В созданный вручную каталог по итогу проблемной загрузки ничего не пишется. По датам все логи в /var/log ведутся видимо до даты сбоя, актуальных нет.

Что-то мне подсказывает, что система сильно развалена, и восстанавливать её вот так будет нетривиально (хотя и решаемо, конечно).

Можно проверить, что сервис журналирования вообще жив:

systemctl status -l systemd-journald

Рекомендую также сопоставить граф загрузки проблемной системы, и условно-аналогичной здоровой. Например, так:

# рисуем схему текущей загрузки:
systemd-analyze plot > lastboot.svg
# смотрим её удобным редактором, например:
eog lastboot.svg &

Кстати, а может информации в /var/log/messages и dmesg всё же хватит для начала?

Похоже, что-то сломалось в PAM.
Вангую, постаралась xfs. Она при ребуте умеет полностью разваливаться в отдалённую китайскую провинцию Кху Ям, потерять что-то отдельное тоже наверное сумеет.

Большого опыта с xfs у меня нет, но ошибок при проверке xfs_rapair не находит, все Ok. Какие проверки можно сделать?

При загрузке вижу ~15 демонов в [FAILED] среди них auditd, dbus, dmesg, sysstat, syslog-ng, network, ligind… проблема на уровне systemd похоже.

Есть способ через опции загрузчика получить больше информации, чем [FAILED] Failed to start Login service See ‘systemctl status systemd-logind.service’ for details пробовал rd.debug, но вывод тот же

В систему войти не могу, при reset на окне логина, загрузке с liveCD, на подключенном диске в /run тоже ничего нет

Коллеги, может кто возмездно) поможет разобраться, буду благодарен.

Коллеги, может кто возмездно) поможет разобраться, буду благодарен.

В соответствующем разделе форума можно опубликовать запрос этот. Наверняка найдутся желающие.

Вообще на самом деле, если знания пока поверхностные, то видится самым реальным, перенакат системы. Естественно, с полным бэкапом всего необходимого (в т.ч. соседних разделов, при наличии таковых).

RHEL 7.3

Система-то древненькая (сейчас 7.9), её бы обновить для начала. Может проблемы как класс и уйдут сразу. Т.е. если по шагам:

а) Проверяем, что нужный репозиторий подключён;

yum repolist
yum repolist all

При таком раскладе, должны быть видны пакеты новых версий, примерно таких порядков:

$ yum list kernel systemd
kernel.x86_64                        3.10.0-1160
systemd.x86_64                    219-78.el7_9.2

б) Делаем yum verify (может, сразу много станет понятно). Процедура длительная. Можно заодно в лог сразу сбросить, для наглядности:

yum verify 2>&1 | tee verify.log

Может сразу всё понятно станет, кстати;

в) Делаем

yum update 2>&1 | tee update.log

Можно, кстати, не всем скопом обновить, а небольшими полосами, с перезагрузками. Может методом исключения сразу корень проблем и выявится. Например, первая порция:

yum update   systemd rsyslog openssh rpm yum 2>&1 | tee update.log1

Если такой подход устраивает, то могу что-то пояснить конкретнее.