It is currently Fri, 23 Aug 2019 23:03:23 GMT

Author Message
 Guidelines for reporting Linux bugs

Last updated: 20 Jul 92

*** This file specifies how you should file bug reports and bug report
*** updates (such as fixes and workaround reports). PLEASE READ before
*** you do anything!!

If you are having problems with Linux, the first thing you should do is
POST your problem or possible bug to comp.os.linux or send it out on
one of the several mailing lists. In this way, others can verify your
problem and find out if it's actually a bug.

If it's determined that your problem is a bug specific to Linux, or
is a problem caused by a certain setup that others should be aware of,
use the 'ibug' program along with the 'linux.temp' template which will
mail the bug report to "". Ibug is
available on the major Linux ftp sites and has been posted to comp.os.linux.

If your problem is indeed a bug, PLEASE SUBMIT IT using ibug whether or
not there is a workaround. A list of all verified bug reports will be
periodically posted to comp.os.linux to let users know what the
known bugs are.

Note: Ibug is NOT a program for use with Linux, as Linux does not
support mailing over the internet (yet). It's meant to be used on your
"other" UNIX machine(s) to report bugs for the Linux project. Whenever
Linux lets you mail onto the Internet, feel free to use it!

IF YOUR NET CONNECTION IS NOT A UNIX SYSTEM, the ibug program won't work.
Simply grab the "linux.temp" template posted to comp.os.linux (or mail
me for a copy of it), fill it out and mail it by hand to

IF YOU HAVE PROBLEMS getting mail to the ml-linux-bugs, send the report
directly to me (

Use ibug to fill out and mail the linux.temp bug report template.
Please don't mangle the header lines such as From: and Revision:
because that may cause the report generation scripts to break.

You need to fill out the following information in the template:

From: your complete email address, so I can get back to you. My scripts
  won't pay much attention to the information that sendmail puts in the
  header. This should be the email address that we can use to respond to

Subject: don't edit. Should read "LINUX BUG REPORT".

Revision: one line, the revision and patch level of the Linux kernel/release
  that you're under. Also include any patches that you've applied.

Setup: One line, brief description of your system's setup. e.g. "386SX, 4Megs
  Ram, SVGA, 105MB IDE HD". You can expound in the Description: section below.

File: The name of the file (full pathname) or program (along with the version
  of that program) that's causing problems. You can also use well-known
  terms such as "kernel" or "bootimage", etc.

Summary: a BRIEF one line summary of the problem, e.g. "X11 crashes when
  exiting xterm" or something like that.

Description: The complete description of the problem or bug. Be as verbose
  as you want. Please include the following information:

     - If it's a program you've compiled or that you're trying to compile,
       specify where you got it from (site and directory), the version of
       the compiler you're using, and any changes/patches you've made.
     - If it's a binary, specify where you got it from, and how big it
     - If there's any error message, reproduce it accurately! If possible,
       write it to a file and upload it to the system you want to report
       the bug from.
     - Be very specific as to the results: don't just say "nothing happens"--
       that could man "program stops and waits for something", "program
       enters an infinite loop", or any number of other things.
     - Always include the command lines and setup that you went through
       to produce this bug. Also mention how you verified the bug (i.e.
       if you verified that you didn't do something stupid, mention it
     - If there is a workaround (or possible workaround) for the problem,
       PLEASE INCLUDE IT in this section!
     - You can expound on any other information in the other report
       fields in this section as well.

  ALWAYS reproduce the bug BEFORE you report it! It could have been due to
  the auras of Linus and the UNIX deities being out of sync (a rare
  occurrence, of course). And always try to verify the bug as much as
  possible, and isolate it to a single problem. If you have already verified
  that you didn't do something stupid, mention it. For example, make
  sure that you transferred your files using binary format in ftp, and so on.

*** If you have an UPDATE to the bug report (i.e. that a bug is fixed,
there's a patch or workaround for it, etc.) you should fill out the
"linux.fix.temp" template using ibug (or by hand) and mail it to This template should contain the SAME
"Summary" line as the original bug report along with a description of
the fix or update. This way I can modify the original bug report
so the report and its fix will go together.

Thanks, and please send me ( any suggestions or problems!

Matt Welsh        ...!mcnc!rti!dg-rtp!welshm
UNIX-SQA, Data General Corporation RTP        Office: +1 919 248 6070
  "Do not taunt Happy Fun Ball."

 Sat, 14 Jan 1995 21:48:34 GMT   
 Guidelines for reporting Linux bugs

The first thing is - check the FAQ.
Then, think about the problem yourself - I've seen some fairly silly
Help with ... reports which seemed to assume that 'GCC/Linux/any of a
large number of other utillities must be broken because they don't work
for me'. Use simple logic - the volume of traffic in this group
indicates that most things *do* work, so if they don't work for you the
most likely reasons are that you didn't understand the (sometimes
sketchy) documentation or you didn't follow it, or you are running an
old version of Linux/gcc/whatever and trying to run software set up for
a more recent version, etc.
If you still can't solve it, see if there's someone
knowledgable you can ask - colleague at work, fellow student, etc.
If all this fails, then post the problem.
The benefits are:
1) You'll learn more by trying to solve the problem yourself.
2) You'll understand the problem better if you really do need to post
the report, and your report will be clearer. You'll be able to save
everyone sending you stock answers like 0.95's tar is broken, etc.
because you will have checked the FAQ, chekced your version of tar, etc.
and your message will be able to say I'm running this version...
3) There will be less pressure to split comp.os.linux because there
won't be as many silly bug reports/help requests which really have been
answered over and over again.
4) The experts who can answer your questions will be less likely to have
become tired of answering repetitive pleas for help.

Jim Segrave (Segrave Software Services)

 Mon, 16 Jan 1995 08:41:28 GMT   
 Guidelines for reporting Linux bugs

Exactly. I somewhat assumed in the guidelines that the FAQ would have
been read first, however it is painfully obvious that this doesn't happen
most of the time, with all of the volume in this group.

I'll change the Guidelines to reflect this: That posting your problem
to the group and/or reporting a bug to me is a LAST RESORT. You have to
remember, however, that not everyone out there using Linux is a UNIX
guru. That doesn't mean they have to be to figure out problems, but
as you know, the amount of information one gets when running into UNIX
problems in general is very small. Without some amount of UNIX system
administration or programming experience, most problems can be very very
difficult to "figure out" on your own.

But you're right: it's a much better idea to work problems out on your
own system, internally, before posting a plea to the net for help (if
you must at all). However this mechanism is set up for those who have
problems with Linux that aren't their fault-- i.e. "tar is broken in
0.95" and so on.

IMHO, the FAQ needs to be revised quite a bit, to take into account
the list of "common problems" that people are running into. For instance,
the /etc/nologin problem. Or the tar problem, and so on. Things that
aren't "bugs" per se, but common problems people have with Linux.
The current FAQ doesn't mention most of these problems!

That, I think, would be the most useful thing to do.


Matt Welsh        ...!mcnc!rti!dg-rtp!welshm
UNIX-SQA, Data General Corporation RTP        Office: +1 919 248 6070
  "Where's the KABOOM?! There was supposed to be an Earth-shattering KABOOM!!"

 Tue, 17 Jan 1995 22:06:23 GMT   
   [ 3 post ] 

Similar Threads

1. Bug report bounced + bug report

2. Unconfirmed bug reports in my bug database

3. BUG REPORT: bug in eepro100.c driver

4. how to enter a bug report against linux?

5. BUG REPORT: emacs-19.23 dies with SIGSEGV under Linux 1.0.9

6. bug report (linux-2.4.20-suse12 +e1000 +xeon +ht)

7. Linux 2.5.5-dj1 - Bug Reports

8. linux kernel bug report

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software