Как просмотреть все загрузочные сообщения в Linux после загрузки?

Question

Соответствующие вопросы:

Где 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 ->» у меня есть только "Показать информацию о времени на принтках" и "По умолчанию". уровень журнала сообщений ". Где опция задержки печати? Нужно ли сначала включить что-то еще, чтобы сделать его видимым? Какие? Было бы неплохо иметь это как часть ответа, если кто-нибудь знает.

Но в любом случае это требует перекомпиляции ядра, что делает этот уродливый и агрессивный хак для, казалось бы, тривиальной задачи. Правильный способ сделать это будет очень приветствоваться.

Answer 1

Итак, ваша консоль имеет два типа сообщений:

• генерируется ядром (через 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; многие другие системы инициализации просто перенаправляют его на консоль или в никуда).

Answer 2

Одно из предложений заключается в том, чтобы другой ноутбук запечатлел экран загрузки с высоким разрешением и частотой кадров, а затем медленно воспроизвел получившийся результат (MOV - MP4 - AVI) - может быть, не лучшее решение, а просто развертывание и его отладка в любом случае, верно? Просто идея ...

Answer 3

Ответ Гравити должен быть лучше описан, чем я мог бы достичь на этом этапе загрузки.

Что касается метода физического перенаправления, ваш BIOS должен поддерживать его. Серверные редукторы обычно делают. Системы Intel, IBM и SuperMicro обычно имеют параметр перенаправления консоли под основным заголовком BIOS. Его нельзя использовать, если ваша материнская плата не имеет физического последовательного порта, например, только USB. Возможно, вам придется подключить физический порт к контактам на материнской плате, если он у него есть.

Перенаправление консоли может вызвать дурацкий случай, когда вы доберетесь до точки, когда операционная система пытается использовать последовательный порт для чего-то другого. Я бы сказал, что он в основном используется для отладки в конкретном случае, а не для постоянного использования.

Для использования вам необходимо установить соответствующие настройки порта на ком-порте вашего ресивера, который может быть основан на USB, затем вам нужно связать два устройства нуль-модемным кабелем, который обменивает контакты приема и передачи между устройствами.

Приемное устройство должно быть полностью включено и следить за связью во время загрузки исходной системы. Принимающая система получит весь текстовый вывод.

Если во время загрузки ваша ОС начинает отображать текст в виде графической конструкции, а не в виде текста, принимающая система получит бред.