Boot messages to service console
You may have heard about management consoles!? If a server is dead you can revive it via service console without driving the long way to the data center (often miles away).
While logged into the service console you of course have the chance to reboot the machine itself. To get to know what it is doing while booting you may want to see all the messages that are usually prompted to the terminal at the attached monitor. Unfortunately you aren’t next to the machine, and so there is no monitor attached to it, but you can force grub to prompt all messages both to terminal and to service console.
First of all you have to setup the serial console:
The --unit
parameter determines the COM port, here it’s COM1, if you need COM2 you should use --unit=1
. --speed
defines a baud rate of 57600 bps, see your manual. To learn more about the other parameter you are referred to the Grub manual for serial.
Next you have to tell Grub where to write the output:
This line tells grub that there are two devices, the typical console on the attached screen and our previous defined serial console. With this directive Grub waits 5 seconds for any input from serial console or the attached keyboard and will print its menu to that device where the input was generated. That means if you’re at home and press any key, Grub will show you all outputs to your serial connection, but your student assistant (who had to go to the server, by bike while raining!!) isn’t able to see whats happening. But if your assistance is faster than you and hits a key on the physically attached keyboard, he’ll see anything and you’ll look through a black window… If nobody produces any input the output is written to that device that is listed first.
Last but not least you have to modify the kernel sections of the boot menu and append something like that at the end of every kernel line:
That tells grub that all kernel messages should be printed to both the real console of the attached screen and the serial console. Keep in mind to modify ttyS0
to match your serial port (here it is COM1).
Grub decides for the device that is listed last to also send all stdin/stdout/stderr of the init process, that means only the last device will act as interactive terminal. E.g. checks of fsck
are only printed to the last device, so stay calm if nothing happen for a long time on the other one ;-)
Here is a valid example for copy and paste:
Here both Grub entries are booting the same kernel, but the first one will use the local console as interactive terminal whether the other entry takes the serial console for interactions.
Leave a comment
There are multiple options to leave a comment: