Problem Solving HOWTO Dag Wieërs 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 ;) About the Problem Solving HOWTO

"We'd like to help you learn to help yourself." -- Simon and Garfunkel, Mrs. Robinson

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 . 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!

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:

Software information Finding Information on your System

...

Finding Information on the Net

...

Use the source, Luke !

...

Software problem determination Reading information

...

Spotting useful error-information

...

Understanding the meaning of an error

...

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 <cmd>, info <cmd> 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 !

Software debugging tools ksymoops

...

gdb

...

nm

...

objdump

...

strace

...

ltrace

...

Using your syslog

...

strings

...

file

...

ldd

...

lsof / lslk / fuser / stat / readlink

...

perl

...

od / hexdump

...

time

...

Hardware information

...

Getting system information

/proc-filesystem uname

Hardware problem determination

...

Hardware problem check-list

...

Hardware debugging tools memtest fsck pnpdump isapnp lspci dmesg Types of Problems the "hey, it should behave otherwise"-problem

...

the "it returns something i don't understand"-problem

...

the "i really don't have a clue"-problem

...

the "i don't know how exactle to do this"-problem

...

the "this must be a bug"-problem

...

Types of Information README-Information

...

CHANGES-Information

...

Manuals

...

Sample files

...

Website

...

Sources

...