A large part of every Linux forum’s work is dealing with enquiries by Linux novices. While it can be very enjoyable to help others, it can also be rather tiresome to try to help people who have shown no inclination towards helping themselves. However I believe that in many cases, this is not due to inherent laziness on the questioner’s part. It is simply that novices have not been shown the first steps in Linux problem solving and do not realize how much they can do for themselves. It is hoped that this guide will be of use to anyone who is taking first steps in Linux.
I. Investigating problems yourself
1. Don’t panic! Collect information.
If a program crashes or doesn’t do what it is supposed to, but your system is otherwise usable, set to work calmly to find out whatever you can about the situation. Open a new file in your favorite editor, write down what you were doing at the time and any error messages that you received. Be sure to get them down literally and exactly – use copy and paste if you can.
Open a terminal and type [b]tail /var/log/messages[/b]. This will show you the last 10 lines of the main system log. If it contains any messages that are clearly relevant, put them in your file too. Errors from graphical programs go into a different file, usually a hidden file in your home directory called [b].Xsession-errors[/b]. Tail this one too and add to your report file if necessary.
If your system is shot (very unusual in Linux!) you will need an alternative way of getting in. If you are dual-booting with another Linux distro, use that. If not, you will need a “rescue disc”, and it’s a good idea to have one ready in advance. Many installation CDs can be run “live” to provide rescue facilities; if you haven’t installed from such a disc, the first thing you should do after installation is get and burn a live distro such as Knoppix. Keep it for emergencies such as this. Once you are in, mount your usual root and any other partitions and look for information as above.
2. Is it reproducible?
If you are in a position to try and reproduce the error, then do so. Obviously try to do it in a way that doesn’t damage your data. For example, use a special test file with the program, not a real data file. Or use a copy of the file that you can discard later. Remember, reproducible errors are easier to troubleshoot.
3. Is it your hardware?
Unreproducible problems are often hardware-related. If you suspect a hardware problem, it is worth looking in the boot log (usually [b]/var/log/boot[/b]) to see if the kernel recognised the hardware. You can’t use the tail command for this because the relevant information might be anywhere in the log; [b]less /var/log/boot[/b] will allow you to page through it. Add any relevant messages to your report file.
4. Read the documentation for the program.
This is particularly important if the program didn’t actually crash but nevertheless behaved in a way you didn’t expect. Look up the program’s online help file if there is one. Also look at the man page (use [b]man program_name[/b] in a terminal). The error may have been on your part.
5. Google the errors.
Google is your friend! Copy the exact error message and paste it into a Google search, preferably with the name of the program as well. You will almost certainly find threads in forums and mailing lists from people who have had the same problem. Often following the thread will give you a solution.
6. Think logically.
If by this point, you have an idea of what may have caused the problem, can you think of a way of testing your idea? Being able to use the command line is a boon at this point; there are many simple commands that can give you useful and relevant information about your system.
7. Now you can think about asking for help
If you have drawn a blank so far, it is time to seek help via a user forum. But please do go through steps 1-6 first. Most experienced Linux users are happy to help those who have shown initiative in helping themselves, but many get seriously irritated by people who expect to be spoon-fed. Remember that the people who use forums are fellow-travellers on the Linux road, not support staff who are paid to answer your questions.
II. Getting help from other people
1. Look first.
Start by searching your chosen forum. Someone may already have asked this question. If there is a FAQ, use it.
2. Don’t post off-topic
Find the right sub-forum for your post. If it’s very basic and there is a “newbie” forum, you can post there. Be careful not to post in a forum that’s labelled “not for support questions”. And don’t post in more than one section; most forums have rules against this.
3. Choose your post title carefully.
Never use titles like “N00b needs help!” or “Somebody help me PLEEEEZE!!!”. It really puts people off. Your title should indicate what your problem is. Then anyone who knows the answer will be encouraged to share it with you. Be as precise as you can. For example “Modem keeps hanging up during authentication” is much more useful than “Can’t get on the Internet”.
4. Be brief but informative.
In the body of your post, give the name and version of your Linux distribution, the name and version of the program that is playing up, and any relevant hardware details. Also include the precise error messages – this is where your report file will come in useful! Indicate briefly what you have done to try to solve the problem. That way you will come over as an intelligent and competent person.
5. Don’t use texting abbreviations.
It’s very annoying.
6. Do use the opportunity to learn.
Don’t follow advice blindly; you’re here to learn something. If you are asked to use command line tools to gather information, use your man pages to find out what those tools actually do. Then you can use them with confidence if you run into similar problems in the future. If you are asked to post a file, find out what that file does within your system. Important system files often have their own man pages.
7. Say thank you.
Linux is a community. Nobody’s paying us to help you. We do it because we’ve all been helped in the past and we want to pass it on. As well as saying thanks for the specific help, you can learn to do your bit to help other novices on their way, people who perhaps know even less than you do. And then you will experience a sense of satisfaction that Windows cannot give.
