Using NetConsole and NC with Unslung
This article pertains to:
The netconsole functionality is a new debugging feature of Unslung 6.10. Netconsole is a kernel driver that directs all output that normally would be sent to the serial console to the network instead. Thus, simply by listening on the network for special packets, one can see what's going on during the Unslung boot process; something that can be very helpful when trying to resolve certain types of problems or issues.
A limitation of the netconsole driver is that it only sees messages that originate from within the Linux kernel itself; you'll never see the output from (for example) the startup scripts at boot time. Unslung 6.10 has a means to address this as well; the same mechanism that enables netconsole will also set up the normal init process to output its data to the network via the "nc" (aka netcat) utility.
Enabling NetConsole and NC on Unslung
This is done simply by placing a special file on the root level of the flash filesystem on Unslung.
Begin by booting the device up without any disks (so that it boots from flash). In that mode, enable telnet, and telnet into the slug.
Simply creating "/.nc" (by the command "touch /.nc" for example) is sufficient to turn on netconsole at the next boot -- with the default values for IP addresses and ports. The defaults will assume that the slug will be at 192.168.1.77 and the host that will be receiving the netconsole output will be at 192.168.1.100.
That's probably not quite right for most folks, so you can change it by setting the correct values in that "/.nc" file. Use vi to make it look something like:
Adjust the addresses for your environment, of course. Note that you'll have a problem if you use DHCP -- it just won't work. At all. No how, no way. You'll have to switch to static IP addresses on the NSLU2 while you do this.
Ok, that's the NSLU2 then. Now you need something on your host. Most Linux systems will have "nc" or "netcat" (same program). Run that command in listen mode, specifying the default netconsole port, and the UDP protocol:
Now boot your slug. You'll see a connection established, and you'll begin to see console output from the device.
Now the output you'll see is exactly what ends up in the buffer printed out by the dmesg command -- and you'll note that's incomplete -- as noted above, what you are seeing with netconsole is only the kernel-originated messages. What's missing is the output generated by the startup scripts, something that would be most helpful when debugging early boot problems.
The Unslung netconsole mechanism is designed to assist in this regard as well. The creation of the same "/.nc" file also triggers the boot process to redirect output from the startup scripts via netcat to the same TCP address, same port number, but using tcp.
In order to view that output, open another window on the Linux monitoring system, and in that window start another copy of netcat:
Note that you'll need to restart fresh copies of these on the host system each time you reboot the NSLU2.
Now when you boot, you'll see console messages in the one netcat window, and the output from the boot scripts in the other.
Warning: Note that the presence of the netcat/netconsole mechanism is disruptive. It will result in the presence of additional processes, and will consume some additional memory. For this reason, you cannot always expect to see the same things with this debugging approach as you might see with a serial console.