[buug] Multiple problems

[Rick Moen]

Hi, Luis.  Others may be able to be of considerably more help, as I'm
not personally running FreeBSD at the moment.  You also may need to
resort to the main FreeBSD mailing lists
(http://www.freebsd.org/support.html#mailing-list) or to BAFUG's
(http://www.bafug.org/).  Or to the relevant Usenet groups.

Quoting Luis (lramos3 at satx.rr.com):

> 1-the os stoped booting and would stop when the last message was the
> discovery of the parallel port.  This happened on an ASUS A7V board
> and neither openbsd nor Linux had this problem.  Moving the scsi hd to
> an ASUS P2L97S board solved the problem.

OK, so, when you boot FreeBSD on the P2L97S, what is the _next_ step or
two that the kernel performs after discovering the parallel port?
Knowing that would seem logically likely to point you in the right
direction, in identifying what on the A7V FreeBSD didn't like.  (Also,
which FreeBSD release was this?)

My knee-jerk SWAG (silly wild-assed guess) would be that either the A7V
has some sort of hardware problem that trips up the kernel -- e.g.,
tangled hardware-resource assignments -- or that the (unidentified)
FreeBSD version didn't get along with cutting-edge Athlon systems.
Maybe going over all hardware and ROM BIOS Setup settings with a
figurative fine-toothed comb would help?  Maybe resetting the ROM BIOS
settings to factory defaults?

Also, I just noticed that you said "_stopped_ booting".  Does this mean
that it used to boot, and then later ceased doing so?  Or do you mean 
that it stops in the middle of booting?  These would be vastly different
categories of problem.

If that particular hardware (the A7V motherboard) _used_ to boot the 
(unidentified) FreeBSD version, and then ceased doing so, you would 
want to concentrate on identifying _what changed_ around the time the
symptom arose.

> 2-kde won't [start] with either 3.36 or 4.1, having [been] installed
> using /stand/sysinstall, neither through startx or startkde.

Any diagnostic messages sent out to stderr?  Anything in logfiles?

KDE is not a single thing, really, but rather a collection of X11
clients, a CORBA broker, some miscellaneous utilities, and a (default)
window manager, kwm.  When we say it doesn't "start", we mean in effect
that either X11 or kwm gets tripped up by something.  One way to
diagnose the problem is to narrow down what's doing the tripping up.

(I don't have any idea about your twm/sawfish issue in GNOME.  If you 
pursue the matter, or post elsewhere about it, make sure you identify
which FreeBSD release(s) it happened in.)

> 3-cups would not install via the ports collection....

It would help for you to be quite specific, in describing problems like
this:  I.e., I performed these steps (listed), and the following output
resulted (quoted).

> ...had to download the tgz file and followed the instructions,
> including using gmake instead of make.  However, the Canon 2100C
> bubblejet does not work and there is no Canon choice during printer
> setup.   What can I do?  Moving the printer to a Linux box was no
> problem, it worked fine.

On the Linux box, what print filter ("driver") did you use?  If memory
serves, there's nothing terribly different about CUPS on Linux as
compared to FreeBSD, so picking the same filter on one -- from the same
or a similar set of Ghostscript and Uniprint filters -- should give the
same results as on the other.

Any type of printing system on Unix has tended to be a horrible mess,
and CUPS is no exception, but I've found Grant Taylor's
linuxprinting.org database to always be useful.  He has entries for lots
of specific printers, where you can find recommended filters and
versions for them, and has a good page about CUPS in general here:
http://www.linuxprinting.org/cups-doc.html

I'm not going to be giving more-specific advice on printing problems, 
as it's not a strength of mine (and frankly, I don't want to get bogged
down in an area of Unix I just don't like to deal with).

> 4-can't use staroffice.  had to do a package installation as the cdrom
> would not install the program.

Again, it would help for you to be quite specific, in describing such
problems.  "I performed the following steps" (listed).  "FreeBSD gave
this output to the various steps" (quoted).

> What I'm looking for also, is systematic way of approaching these
> problems so I can solve them myself. 

Now, _that_ is a good and useful question.

One common problem in software diagnosis is the "too many suspects" 
problem:  Your KDE, GNOME/sawfish/twm, and CUPS problems are cases in
point.  Diagnosis often consists of identifying the logical suspects,
and then narrowing down the field until you identify the culprit, and 
you happen to have cited several rather ornate software setups, in which
one does not readily know where to look first because there are too many 
interrelated pieces whirring about.

Another common diagnostic technique is to look for relevant error
output.  Some useful debugging information goes to stdout.  Note that
such output is often suppressed when starting processes from window
managers' menus and such, but fully displayed when you do the same thing
from a command line.  To see this point illustrated, start Mozilla from
a window manager menu.  Now, start it from an xterm, like this: "mozilla
&"

So, you could start diagnosing a KDE problem by starting with a
deliberately simple starting point, by creating ~/.xinitrc as follows:

   /usr/bin/X11/xterm

(Note that you'll have to correct the pathspec, which is almost
certainly incorrect for FreeBSD.)  Now, do "startx".  What will result
is X11 starting up with just the one xterm client, and no window
manager.  Now, type "kwm" in that xterm.  (Again, you may need to figure
out and supply the correct FreeBSD pathspec.)  Does kwm start?  If not,
what does the stderr output state?  Can you start the KDE panel process?
(I _think_ it's called "panel".)

Note that the above technique addresses simultaneously the "too many
suspects" / simplicity problem and the concealed-stdout problem.  You
will possibly find other relevant error output in the system logs.  

Another common diagnostic technique is to start with a theory about 
what is causing the problem, and then gather information to try to test
it.  For example, you might hypothesise that the printing problem is
caused by the CUPS engine, rather than by the filter.  You might have
identified the filter you used for your Canon (and its version), and 
verified that it worked on Linux.  So, you might have good reason to
feel that the problem lies elsewhere.  OK, so, does the same filter on 
FreeBSD work if you use lpd or lprng instead of CUPS?

A variant of the "too many suspects" problem is the "too many
uncontrolled variables" problem:  If you're trying to isolate the
problem's cause, the worst thing you can do is change lots of variables
(elements of your configuration or operating state) at the same time:
Doing so _increases_ the field of suspects, rather than decreasing it.
Computer novices fail to solve their problems for this reason more than
any other.  To the extent feasible, change only one thing at a time, and
remember what you changed, when.

Last, in all Unix systems, remember that many problems are related to
ownership and permissions on files.  Thus, it is often useful to observe
that a problem exists only for non-root users, but not for the root
user.  (Test to see if a problem goes away when you perform the action
as root.)

And here is a FAQ on asking questions of technical communities, on which
I collaborated with Eric S. Raymond:
http://www.tuxedo.org/~esr/faqs/smart-questions.html  (Absolutely no
offence intended:  The fact that you're asking about general diagnosis
techniques means you _are_ attempting to ask questions the smart way!)

-- 
Cheers,
Rick Moen                      "vi is my shepherd; I shall not font."
rick at linuxmafia.com                               -- Psalm 0.1 beta