How to view all boot messages in Linux after booting?

Solution 1:

So your console has two types of messages:

• generated by the kernel (via printk);
• generated by userspace (usually your init system).

Kernel messages are always stored in the kmsg buffer, visible via dmesg. They're also often copied to your syslog. (This also applies to userspace messages written to /dev/kmsg, but those are fairly rare.)

Meanwhile, when userspace writes its fancy boot status text to /dev/console or /dev/tty1, it's not stored anywhere at all. It just goes to the screen and that's it. So I think pretty much any solution – except for Rowan's serial console suggestion – will end up being either very distro-specific (due to each init system performing logging differently) or an "invasive hack" that involves strace or kernel hacking or such.

In the best case, your init system will itself log all important events to the syslog (/var/log/messages or such). For example:

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 and upstart also log the services' stdout/stderr as well; many other init systems just redirect it to the console or nowhere.)

Solution 2:

Grawity's answer is must better described than I would have been able to accomplish for that stage in the boot.

On the physical redirection method, your BIOS has to support it. Server geared boards usually do. The Intel, IBM, and SuperMicro systems typically have a Console Redirection option under the main heading of the BIOS. It cannot be used if your motherboard does not have a physical serial port, e.g. only USB. You may need to attach a physical port to pins on the motherboard if it has it.

Console Redirection can cause wackiness when you get to the point where the operating system is trying to use the serial port for something else. I would say it's primarily used for debugging in a particular case rather than constant use.

To use, you would need to set matching port settings on your receiver com port which could be usb based, then you need to link the two devices with a null modem cable which exchanges the transmit and receive pins between the devices.

The receiving device needs to be fully powered on and watching for the communication during the boot of the source system. The receiving system will get all text based output.

If during boot your OS starts displaying text via a grapical construct rather than as text, the receiving system will get gibberish.

Solution 3:

One suggestion is to have another laptop film the boot screen with high resolution and frame rates then slow play the resulting (MOV - MP4 - AVI) - maybe not the best solution but simply to deploy and its for debugging anyway right ? Just an Idea ...