Теория: Журналы и диагностика

Журналы — это память операционной системы. Они фиксируют всё, что происходит при загрузке и во время работы: какие устройства подключились, какие службы запустились, где произошли ошибки, а где система просто что-то предупредила. Без журналов невозможно понять, почему система не загружается, почему не работает сеть или почему диск внезапно «пропал».

Когда Linux запускается, ядро первым начинает записывать сообщения о каждом событии — от инициализации процессора до обнаружения USB-клавиатуры. Все эти строки сохраняются в буфере ядра, и прочитать их можно с помощью команды:

dmesg

Эта команда выводит последовательность сообщений ядра, начиная с самого старта системы. Здесь видны этапы загрузки, определения оборудования, подключения модулей и запуска драйверов.

Например, если система не видит жёсткий диск, в dmesg появится строка вроде:

[  2.843210] ata1: link is slow to respond, please check cable

А если драйвер не смог загрузиться:

[  3.112452] usbcore: failed to load module usbhid

Такой вывод помогает быстро локализовать проблему: ядро сообщило, что именно не сработало.

Чтобы читать журнал удобнее, вывод можно прокручивать:

dmesg | less

А ключ -T добавляет привычное отображение времени, вместо «сырых» секунд с момента старта:

dmesg -T

Теперь каждая строка сопровождается меткой времени, например:

[Wed Oct 30 12:45:13 2025] eth0: link is up, 1Gbps full-duplex

dmesg особенно полезен при загрузке системы или после вставки новых устройств. Если, например, подключить флешку и сразу выполнить dmesg | tail, можно увидеть, как ядро определило устройство и под каким именем оно появилось (/dev/sdb1, /dev/sdc1 и т.д.).

Диагностика

Если Linux не загружается, это почти всегда означает сбой на одном из этапов запуска. Процесс загрузки проходит строго по цепочке: сначала BIOS проверяет оборудование, затем управление получает загрузчик GRUB, после него запускается ядро, монтируется корневая файловая система и стартует система инициализации systemd. Каждый из этих шагов оставляет следы, которые можно проверить и восстановить. Разбираясь, на каком этапе нарушилась последовательность, удаётся точно определить источник проблемы и вернуть систему в рабочее состояние.

После загрузки ядра первым источником информации становится системный журнал systemd. Он объединяет сообщения ядра, служб и пользовательских процессов. Команда journalctl открывает доступ ко всем этим данным. Чтобы просмотреть события текущей загрузки, используется параметр -b:

sudo journalctl -b

Флаг -b (boot) ограничивает вывод рамками одного цикла загрузки. Если необходимо просмотреть предыдущую загрузку, добавляется номер -1. Например, journalctl -b -1 покажет логи прошлого старта, что особенно полезно при повторных перезагрузках после сбоя.

Для анализа конкретной службы используется параметр -u, обозначающий unit — элемент systemd. Например, sudo journalctl -u ssh выведет историю службы SSH: её запуск, остановку и возможные ошибки. Если при загрузке на экране появляется сообщение «A start job is running…», это значит, что systemd ожидает завершения какой-то операции. В таких случаях помогает команда journalctl -xb. Флаг -x добавляет расшифровку сообщений, а сочетание -xb показывает подробный журнал текущей загрузки. Часто в выводе можно увидеть строки вроде Failed to mount /home или Dependency failed for local-fs.target, что указывает на проблему с записью в /etc/fstab или отсутствующее устройство.

Когда нужно понять, кто работал в системе, используются команды last и who. Первая читает журнал /var/log/wtmp и выводит историю входов, перезагрузок и выходов. Пример:

last

Вывод показывает список пользователей, время входа и длительность сессии. Если система неожиданно перезагружалась, в списке появятся частые записи reboot. Команда who отображает текущие активные сеансы и терминалы:

who

Эти данные помогают установить, кто подключён к системе в данный момент и через какие интерфейсы.

Для оценки общей стабильности применяется команда uptime.

uptime

Она показывает, сколько времени система работает без перезапуска и какова средняя нагрузка процессора за последние 1, 5 и 15 минут. Если Linux функционирует непрерывно неделями и начинает работать медленнее, вероятной причиной могут быть накопленные фоновые процессы или утечки памяти.

При медленной загрузке полезен инструмент systemd-analyze blame. Он измеряет длительность запуска каждой службы:

systemd-analyze blame

В выводе отображается время, затраченное на запуск конкретных компонентов, что помогает выявить «узкие места». Если требуется визуализировать процесс загрузки, применяется bootchart, создающий график с распределением времени по процессам.

Когда система не загружается вовсе, диагностика проводится по уровням. Если при включении появляется сообщение grub rescue> или мигающий курсор, значит, загрузчик GRUB не смог найти конфигурацию или раздел /boot. В таком случае можно вручную указать ядро и корневой раздел:

set root=(hd0,1)
linux /boot/vmlinuz-5.10.0 root=/dev/sda1
initrd /boot/initramfs-5.10.0.img
boot

Если загрузка проходит, конфигурация GRUB требует восстановления. Это выполняется командами:

sudo grub-install /dev/sda
sudo update-grub

Когда GRUB работает, но система останавливается на сообщении «Loading initial ramdisk…» или «Can’t mount root filesystem», ошибка находится в образе initramfs. Этот временный образ содержит драйверы и скрипты, необходимые для монтирования корня. Проверка выполняется из живой системы. Раздел монтируется в /mnt, после чего можно убедиться, что в каталоге /boot присутствуют актуальные файлы:

sudo mount /dev/sda1 /mnt
ls /mnt/boot

Если образы отсутствуют, их создают заново:

sudo update-initramfs -c -k all

Параметр -c означает создание, а -k all — обновление для всех установленных ядер.

Если система зависает при старте systemd, чаще всего причина заключается в записи /etc/fstab, указывающей на несуществующее устройство. Для восстановления можно загрузиться в аварийный режим. В меню GRUB добавляется параметр ядра:

systemd.unit=emergency.target

После запуска открывается минимальная консоль с правами root. Здесь можно отредактировать /etc/fstab, закомментировать лишние строки и перезагрузить систему.

Когда загрузка доходит до графического интерфейса и экран остаётся чёрным, проблема часто связана с видеодрайверами. В этом случае помогает загрузка в rescue.target, переустановка драйвера и анализ логов с помощью journalctl -xb | less. Ошибки модулей ядра обычно помечаются как Failed или dependency failed.

Если система уходит в перезагрузку сразу после старта, стоит проверить файловую систему:

sudo fsck /dev/sda1

Команда проверяет структуру раздела и исправляет повреждения, которые мешают монтированию корня.

Для глубокой отладки параметр systemd.log_level=debug, добавленный в строку ядра в GRUB, включает подробный вывод событий systemd. Это позволяет наблюдать каждый шаг загрузки — от монтирования разделов до запуска служб.

Путь диагностики всегда один. BIOS инициализирует устройства, GRUB загружает ядро, initramfs монтирует корень, systemd запускает службы. Если сбой происходит до GRUB — повреждён загрузчик; если на initramfs — ошибка файловой системы; если при запуске systemd — сбой службы или неверная конфигурация /etc/fstab. Каждый уровень имеет свой набор инструментов: lsblk показывает разделы, dmesg — сообщения ядра, journalctl -xb — состояние служб, fsck — исправляет повреждения.