Linux FAQ - Section 12
How to get further assistance

• Q12.1. You still haven't answered my question !
• Q12.2. What to put in a request for help
• Q12.3. I want to mail someone about my problem.

If you think an answer is incomplete or inaccurate, please mail Ian Jackson at ijackson@gnu.ai.mit.edu.

Read the appropriate Linux Documentation Project books - see Q2.1 `Where can I get the HOWTOs and other documentation ?'.

If you're a Unix newbie read the FAQ for comp.unix.questions, and those for any of the other comp.unix.* groups that may be relevant.

Linux is a Unix clone, so almost everything you read there will apply to Linux. Those FAQs can, like all FAQs, be found on rtfm.mit.edu in /pub/usenet/news.answers (the mail-server@rtfm.mit.edu can send you these files, for those who don't have FTP access). There are mirrors of rtfm's FAQ archives on various sites - check the Introduction to *.answers posting, posted, or look in news-answers/introduction in the directory above.

Check the relevant HOWTO for the subject in question, if there is one, or an appropriate old-style sub-FAQ document. Check the FTP sites.

Try experimenting --- that's the best way to get to know Unix and Linux.

Read the documentation. Check the manpages (type man man if you don't know about manpages. Try man -k <subject> --- it often lists useful and relevant manpages.

Check the Info documentation (type C-h i, i.e. Control H followed by I in Emacs) --- NB: this isn't just for Emacs; for example the GCC documentation lives here as well.

There will also often be a README file with a package giving installation and/or usage instructions.

Make sure that you don't have a corrupted or out-of-date copy of the program in question. If possible, download it again and reinstall it --- perhaps you made a mistake the first time.

Read comp.os.linux.announce --- this often contains very important information for all Linux users.

General X-Windows questions belong in comp.windows.x.i386unix, not in comp.os.linux.x. But read the group first (including the FAQ), before you post !

Only if you have done all of these things and are still stuck should you post to the appropriate comp.os.linux.* newsgroup. Make sure you read the next question, Q12.2 `What to put in a request for help', first.

Question 12.2. What to put in a request for help

This advice applies both to postings asking for advice and to personal email sent to experts and fellow users.

Make sure you give full details of the problem, including:

• What program, exactly, you are having problems with. Include the version number if known and say where you got it. Many standard commands tell you their version number if you give them a --version option.
• Which Linux release you're using (MCC, Slackware, Debian or whatever) and what version of that release.
• The exact and complete text of any error messages printed.
• Exactly what behaviour you were expecting, and exactly what behaviour you observed. A transcript of an example session is a good way of showing this.
• The contents of any configuration files used by the program in question and any related programs.
• What version of the kernel and of the shared libraries you are using. The kernel version can be found by typing uname -a, and the shared library version by typing ls -l /lib/libc.so.4.
• Details of what hardware you're running on, if it seems appropriate.

Use a clear, detailed Subject line. Don't put things like `doesn't work', `Linux', `help' or `question' in it --- we already knew that ! Save the space for the name of the program, a fragment of the error message, summary of the unusual behaviour, etc.

If you are reporting an `unable to handle kernel paging request' message, follow the instructions in the Linux kernel sources README for turning the numbers into something more meaningful. If you don't do this noone who reads your post will be able to do it for you, as the mapping from numbers to function names varies from one kernel to another.

Put a summary paragraph at the top of your posting.

At the bottom of your posting, ask for responses by email and say you'll post a summary. Back this up by using Followup-To: poster. Then, do actually post a summary in a few days or a week or so. Don't just concatenate the replies you got --- summarise. Putting the word SUMMARY in your summary's Subject line is also a good idea. Consider submitting the summary to comp.os.linux.announce.

Make sure your posting doesn't have an inappropriate References header line. This marks your article as part of the thread of the article referred to, which will often cause it to be junked by the readers with the rest of a boring thread.

You might like to say in your posting that you've read this FAQ and the appropriate HOWTOs - this may make people less likely to skip your posting.

Remember that you should not post email sent to you personally without the sender's permission.

Question 12.3. I want to mail someone about my problem.

Please put everything in your email that you would put in a posting asking for help.

Finally, remember that despite the fact that most of the Linux community are very helpful and responsive to emailed questions you'll be asking for help from an unpaid volunteer, so you have no right to expect an answer.