Как просмотреть все загрузочные сообщения в Linux после загрузки?
Соответствующие вопросы:
Где Linux размещает сообщения о загрузке?
Имя файла журнала, в котором зарегистрирован процесс загрузки
Тем не менее, они не отвечают на этот вопрос. Этот вопрос касается того, как можно просмотреть все загрузочные сообщения.
Это для Gentoo, OpenRC, современных ядер, 4.9.6, если вы хотите получить конкретную информацию. Общее решение, которое работает для всех дистрибутивов, однако, было бы предпочтительным.
Проблема в том, что иногда ошибка или предупреждение будут прокручиваться так быстро, что их не будет видно. Также не всегда возможно просто прокрутить вверх по двум причинам (даже с параметром --noclear в inittab): при переключении на кадровый буфер прокрутка вверх до точки, до которой положение переключателя также больше невозможно, и, во-вторых, после запуска X, переключение на консоль и попытка прокрутки вверх не позволяют прокручивать вообще, пока новый текст не будет добавлен в буфер. Иногда некоторые сообщения просто не найдены ни в dmesg, ни в / var / log / messages.
Как я могу просмотреть все сообщения?
Я вижу здесь кого-то https://www.linuxquestions.org/questions/linux-newbie-8/please-how-to-pause-scrolling-messages-at-boot-323772/ предполагает, что нажатие блокировки прокрутки может приостановить ее. Однако в лучшем случае это не очень элегантное решение - некоторые сообщения будут прокручиваться слишком быстро, системы могут внезапно выдать много текста в эти дни при загрузке.
Это то, что я в идеале хочу:
- Dmesg | решение меньшего типа, если это возможно, или какой-то другой способ пошагового выполнения процесса загрузки.
- Способ гарантировать, что все напечатанное на экране также будет зарегистрировано.
Есть ли простой способ достичь любого из них?
Я знаю одно решение:
CONFIG_BOOT_PRINTK_DELAY: задерживать каждое загрузочное сообщение printk на N миллисекунд
Как ни странно, мне даже не позволяют выбрать BOOT_PRINTK_DELAY в моем menuconfig, я могу найти его при поиске, но в разделе "Взлом ядра" -> "Параметры printk и dmesg ->" у меня есть только "Показать информацию о времени на принтках" и "По умолчанию". уровень журнала сообщений ". Где опция задержки печати? Нужно ли мне сначала включить что-то еще, чтобы сделать его видимым? Какие? Было бы неплохо иметь это как часть ответа, если кто-нибудь знает.
Но в любом случае это требует перекомпиляции ядра, что делает этот уродливый и агрессивный хак для, казалось бы, тривиальной задачи. Правильный способ сделать это будет очень приветствоваться.
4 ответа
Таким образом, ваша консоль имеет два типа сообщений:
- генерируется ядром (через printk);
- генерируется пользовательским пространством (обычно вашей системой инициализации).
Сообщения ядра всегда хранятся в буфере kmsg, видимом через dmesg, Они также часто копируются в ваш системный журнал. (Это также относится к сообщениям в пространстве пользователя, написанным на /dev/kmsg, но это довольно редко.)
Между тем, когда userspace записывает свой причудливый текст состояния загрузки в /dev/console или же /dev/tty1, это нигде не хранится вообще. Просто идет на экран и все. Поэтому я думаю, что практически любое решение - за исключением предложения последовательной консоли Rowan - в конечном итоге будет либо очень специфичным для дистрибутива (из-за того, что каждая система инициализации выполняет регистрацию по-разному), либо "инвазивным хаком", который включает в себя хакерство strace или ядра или что-то подобное.
В лучшем случае ваша система инициализации сама записывает все важные события в системный журнал (/var/log/messages или тому подобное). Например:
systemd[1]: Starting BIRD routing daemon...
bird[478296]: /etc/bird.conf, line 2: syntax error
systemd[1]: bird.service: Control process exited, code=exited status=1
systemd[1]: Failed to start BIRD routing daemon.
(systemd и upstart также регистрируют сервисы stdout/stderr; многие другие системы инициализации просто перенаправляют его на консоль или в никуда).
Одно из предложений заключается в том, чтобы другой ноутбук запечатлел загрузочный экран с высоким разрешением и частотой кадров, а затем медленно воспроизвел получившийся результат (MOV - MP4 - AVI) - может быть, не лучшее решение, а просто развертывание и его отладка в любом случае, верно? Просто идея...
Ответ Гравити должен быть лучше описан, чем я мог бы достичь на этом этапе загрузки.
Что касается метода физического перенаправления, ваш BIOS должен поддерживать его. Серверные редукторы обычно делают. Системы Intel, IBM и SuperMicro обычно имеют параметр "Перенаправление консоли" под основным заголовком BIOS. Его нельзя использовать, если ваша материнская плата не имеет физического последовательного порта, например, только USB. Возможно, вам понадобится подключить физический порт к контактам на материнской плате, если он есть.
Переадресация консоли может вызвать дурачество, когда вы попадаете в точку, где операционная система пытается использовать последовательный порт для чего-то другого. Я бы сказал, что он в основном используется для отладки в конкретном случае, а не для постоянного использования.
Для использования вам необходимо установить соответствующие настройки порта на ком-порте вашего ресивера, который может быть основан на USB, затем вам нужно соединить два устройства нуль-модемным кабелем, который обменивает выводы приема и передачи между устройствами.
Приемное устройство должно быть полностью включено и следить за связью во время загрузки исходной системы. Принимающая система получит весь текстовый вывод.
Если во время загрузки ваша ОС начинает отображать текст в виде графической конструкции, а не в виде текста, принимающая система получит бред.
Ведение журнала OpenRC «По умолчанию OpenRC ничего не регистрирует. Чтобы регистрировать выходные данные OpenRC во время загрузки, раскомментируйте и установитеrc_loggerвариант в/etc/rc.conf. Журнал будет сохранен по адресу/var/log/rc.logпо умолчанию."
rc_logger="Yes"
затем
cat /var/log/rc.log # After reboot
Генту вики
OpenRC
Глава 3 Конфигурация 3.2 Ведение журнала