Now that the hard bit is out of the way (installing Ubuntu) you can begin to customize your new operating system. By default, Ubuntu presents you with a pretty blank canvas with which to personalize your experience. Some people choose to stick with the chocolate colored background, while others go for a full make over.

In this chapter, we'll take a look at getting up and running with Ubuntu, including a quick tour around the desktop. We will also take a look at some of the ways in which you can customize your Ubuntu installation, such as ensuring that date and time settings are correct, as well as show you how to do some basic administration tasks, such as identifying any problems with hardware. By the end of this chapter, you should feel comfortable enough to move on through the rest of the book.

NOTE

Throughout this chapter, we introduce you to several key applications relevant also to other chapters of this book. We include them here because they are essential to getting your system to work as you intend. You will find it worthwhile referring back to this chapter as you work your way through the book.

Troubleshooting 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 some 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 vi or emacs, depending on your taste. 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!)