tags:

views:

392

answers:

2

I'm developing an embedded system which currently boots linux with console output on serial port 1 (using the console boot param from the boot loader). However, eventually we will be using this serial port. What is the best solution for the kernel console output? /dev/null? Can it be put on a pty somehow so that we could potentially get access to it?

+2  A: 

If you just want to read kernel printk messages from the console, and not actually run getty or a shell on it, you can use netconsole. You can supply the following to your bootloader kernel options (or to modprobe netconsole):

[email protected]/eth1,[email protected]/12:34:56:78:9a:bc

where 4444 is the local port, 10.0.0.1 is the local ip, eth1 is the local interface to send the messages out of. 9353 is the remote port, 10.0.0.2 is the remote ip to send the messages to, and the final argument is your remote (eg: your desktop) system's mac address.

Then to view the messages run:

netcat -u -l -p 9353

You can read more about this in Documentation/networking/netconsole.txt

bmdhacks
thanks for the answer. On the final product, I suppose I could send netconsole to 127.0.0.1 and then read from the port in a shell if i needed to
MattSmith
+3  A: 

You can access the printk message buffer from a shell using dmesg. The kernel buffer is of finite size and will overwrite the oldest entries with the most recent, so you'd need to either check dmesg periodically or hook up netconsole as @bmdhacks suggests.

If there is no console you'll miss any oops information printed out by a kernel crash. Even using netconsole may not help there, if the kernel dies and begins to reboot before TCP manages to deliver the output to the remote socket. We generally modify kernel/panic.c:panic() to save register contents and other state to an area of NOR flash, so there will be at least some information available for post-mortem debugging.

DGentry