Troubleshooting Ubuntu Post-Installation Configuration Problems

A lot of work has gone into Ubuntu to make it as versatile as possible, but sometimes you may come across a piece of hardware that Ubuntu is not sure about. Knowing what to do in these situations is important, especially when you are working with Ubuntu for the first time. Because Ubuntu (and Linux in general) is built on a resilient UNIX foundation, it is much more stable than other operating systems. You might find this surprising if you are used to the Blue Screens of Death found on a certain operating system from Redmond, Washington. However, even though things might seem to be working fine, Ubuntu could have a problem that might not affect the appearance of the system. Perhaps kernel modules for devices will not load, for example, or services cannot start for some reason. In this section, you learn how to examine some of Ubuntu’s built-in error logs to help you diagnose any unseen faults. Ubuntu has a command that enables you to see detailed messages that are output directly by the operating system: the dmesg command, which is commonly used with the grep command to filter output. The dmesg command takes its output directly from the /var/log/messages file, so you can choose to either run dmesg directly or enter less /var/log/messages instead. The output is fairly detailed, so be prepared for an initial shock when you see how much information is generated. You might find it easier to generate a file with the dmesg output by using the following command:

$ dmesg > dmesg.txt

This takes the output from the dmesg command and stores it in a new text file called dmesg.txt. You can then browse it at your leisure using your choice of text editor such as vi or emacs. You can even use the less command, like so:

$ less dmesg.txt

The messages are generated by the kernel, other software run by /etc/init.d, and Ubuntu’s runlevel scripts. You might find what appear to be errors at first glance, but some errors are not really problems (for example, if a piece of hardware is configured but not present on your system).

Thanks to Google, troubleshooting is no longer the slow process it used to be. You can simply copy and paste error messages into Google and click Find to bring up a whole
selection of results similar to the problem you face. Remember, Google is your friend, especially http://www.google.com/linux, which provides a specialized search engine for Linux. You can also try http://marc.info, which browses newsgroup and mailing list archives. Either way, you are likely to come across people who have had the same problem as you.

It is important to only work on a solution to one problem at a time; otherwise, you may
end up getting no work done whatsoever. You should also get into the habit of making backup copies of all files that you modify, just in case you make a bad situation worse. Use the copy command like this:

$ cp file file.backup

You should never use a .bak extension because this could get overwritten by another automatic process and will leave you frustrated when you try to restore the original file. If something breaks as a result of you changing the original file, you can always copy the original back into place using the command like this:

$ cp file.backup file

(Something as simple as this can really save your bacon, especially when you are under
pressure when you’ve changed something you shouldn’t have on a production system.
That is, if you are daft enough to make sweeping changes on a production system!)

Source of Infomation : Sams Ubuntu Unleashed 2008 Edition