Problem Solving HOWTO
Dag Wieërs dag@wieers.com
v0.0.3 draft, 18 October 1999
This document describes in full detail which steps to take when trying
to solve hardware or software problems with Linux yourself. It helps
the reader to find information spread all over its harddisk and
teaches him how to use debugging tools. This document should be the
first stop for DIY ;)
______________________________________________________________________
Table of Contents
1. About the Problem Solving HOWTO
1.1 New Versions of this Document
1.2 Feedback
2. Software information
2.1 Finding Information on your System
2.2 Finding Information on the Net
2.3 Use the source, Luke !
3. Software problem determination
3.1 Reading information
3.2 Spotting useful error-information
3.3 Understanding the meaning of an error
4. Software problem checklist
5. Software debugging tools
5.1 ksymoops
5.2 gdb
5.3 nm
5.4 objdump
5.5 strace
5.6 ltrace
5.7 Using your syslog
5.8 strings
5.9 file
5.10 ldd
5.11 lsof / lslk / fuser / stat / readlink
5.12 perl
5.13 od / hexdump
5.14 time
6. Hardware information
6.1 Getting system information
7. Hardware problem determination
8. Hardware problem check-list
9. Hardware debugging tools
9.1 memtest
9.2 fsck
9.3 pnpdump
9.4 isapnp
9.5 lspci
9.6 dmesg
10. Types of Problems
10.1 the "hey, it should behave otherwise"-problem
10.2 the "it returns something i don't understand"-problem
10.3 the "i really don't have a clue"-problem
10.4 the "i don't know how exactle to do this"-problem
10.5 the "this must be a bug"-problem
11. Types of Information
11.1 README-Information
11.2 CHANGES-Information
11.3 Manuals
11.4 Sample files
11.5 Website
11.6 Sources
______________________________________________________________________
1. About the Problem Solving HOWTO
"We'd like to help you learn to help yourself." -- Simon and
Garfunkel, Mrs. Robinson
1.1. New Versions of this Document
If you need to know more about the Linux Documentation Project or
about Linux HOWTO's, feel free to contact the supervisor Tim Bynum
linux-howto@sunsite.unc.edu.
Tim Bynum will post the listing to several national and international
newsgroups on a monthly basis. In addition, the Problem Solving HOWTO
can be found on the World Wide Web at
New versions of the Problem Solving HOWTO are always placed at this
site first, so please be sure to check if the copy you are reading is
still up to date!
1.2. Feedback
If some information seems to be wrong, deceptive or missing, I'd
appreciate if you mailed me the improvements. Since I'm just human
this document isn't bug-free, but your contribution can and will make
a difference.
Additions or improvements can be mailed to: dag@wieers.com
2. Software information
2.1. Finding Information on your System
...
2.2. Finding Information on the Net
...
2.3. Use the source, Luke !
...
3. Software problem determination
3.1. Reading information
...
3.2. Spotting useful error-information
...
3.3. Understanding the meaning of an error
...
4. Software problem checklist
· Did you get the latest version ?
· Did you read the documentation ?
· Is there a FAQ ?
· Is there an INSTALL or README ?
· Check the CHANGES, Changelog or HISTORY ?
· What are the commandline options ? --help, -h, man , info
· Is there a verbose-option ? -v, --verbose, -V, -vv
· Is there a debug-option ? -d, --debug
· Is there a logging facility ? -o, -l
· What is the syntax of the configuration-file
· Is there a verbose-option ?
· Is there a debug-option ?
· Is there a logging facility ?
· What files does the program use ?
· Are the permission correct ?
· Are you the right user, do you have priviliges ?
· Is the program suid ? should it be ?
· Use a debugging-tool ?
· Use strace to examine all the system calls.
· Use ltrace to examine the library calls.
· Get in touch with the developers ?
· First check the documentation again
· Then check their website (if possible)
· Is there a user-forum ? Send it there.
· Is there a developer-forum ? Send it there.
· Send to author(s).
When you finally find a solution that was not stated somewhere in the
documentation, you might want to provide both problem and answer to
the author or one of the developers. This way you prevent someone else
making the same mistakes you made, because wouldn't it be great if the
answer was already available to you ?
If you've got enough expertise about a particalur program and there
wasn't any beginners-document available, you might want to consider
volunteering to write a FAQ about it, the author(s) would be glad !
5. Software debugging tools
5.1. ksymoops
...
5.2. gdb
...
5.3. nm
...
5.4. objdump
...
5.5. strace
...
5.6. ltrace
...
5.7. Using your syslog
...
5.8. strings
...
5.9. file
...
5.10. ldd
...
5.11. lsof / lslk / fuser / stat / readlink
...
5.12. perl
...
5.13. od / hexdump
...
5.14. time
...
6. Hardware information
...
6.1. Getting system information
/proc-filesystem uname
7. Hardware problem determination
...
8. Hardware problem check-list
· ...
9. Hardware debugging tools
9.1. memtest
9.2. fsck
9.3. pnpdump
9.4. isapnp
9.5. lspci
9.6. dmesg
10. Types of Problems
10.1. the "hey, it should behave otherwise"-problem
...
10.2. the "it returns something i don't understand"-problem
...
10.3. the "i really don't have a clue"-problem
...
10.4. the "i don't know how exactle to do this"-problem
...
10.5. the "this must be a bug"-problem
...
11. Types of Information
11.1. README-Information
...
11.2. CHANGES-Information
...
11.3. Manuals
...
11.4. Sample files
...
11.5. Website
...
11.6. Sources
...