Are there any man pages for any of the system error messages?
in [General Linux]
|
Prev: Live CD to scan windows pc for a virus
Next: where is CentOS storing my hostname that it resets it on each reboot?
From: Harald Meyer on 13 Apr 2010 11:23 unruh wrote: >> Okay, what's the explanation *and circumvention* for >> "Enter the new package tree limit:" from aptitude? >> The only hits I get from Giggle are posts I've made >> asking for help. > > Who knows. It is an error message written by a programmer who is > completely incompetent at writing error messages. It is not an error message, it is an incomprehensively named feature he activated by accident. > If you thing such a > programmer will write to you asking for an error message number and then > write an explanation for the message for your man page, The programmer would tell him to RTFM: | aptitude user's manual (...) | +--------------------------------------------------------------------------+ | |Enter the new package tree limit: | | |apti | | | [ Ok ] [ Cancel ]| |Th+--------------------------------------------------------------------------+ | | | |This dialog works exactly like the search dialog, except that instead of |highlighting the next package that matches what you typed into the dialog box, |it hides all packages which don't match. For instance, typing apti into this |dialog box and pressing Enter will hide all packages except those whose names |contain ``apti'': Harald (hates to post RTFMs)
From: Mark Hobley on 13 Apr 2010 17:11 In comp.os.linux.misc Robert Bonomi <bonomi(a)host122.r-bonomi.com> wrote: > against _what_ documentation?? Against any documentation. Technical reference manuals will be able to index the troubleshooter pages according to the error number. From the error number, you will be able to locate the technical documents, etc. > Looking for an error message produced by 'tar' in the 5 volumes of 'X' error > messages will be equally futile. Indeed. Referencing against a number is just a good idea. > > The Unix world assumes that users can (a) read, and (b) THINK. when a message > says 'no such file or directory', and gives the name of the file that the > user requested access to, just what _MORE_ do you think it should provide? Take these error messages: Error 127 A problem was encountered processing your request. The tracker maintainers have been notified of the problem. BUG Int 6: CR2 00000000 Bus error codec_read: codec 0 is not valid 0xfe0000 Compatibility levels before 4 are deprecated dzhandle make-instance: ambiguous zope version to make instance for E: Error occurred while processing xfmedia-dev (NewVersion1) Error delivering message nnnnn to the MDA (gecko:nnnn): Pango-WARNING **: Error loading GPOS table 5503 giving up. (gnome-obex-server:6848): WARNING : Unable to register SDP record for OPUSH GRUB GRUB GRUB GRUB make[1]: * [all-recursive] Error 1 make: * [all] Error 2 No CIDSupplement specified for foobar, defaulting to n. NO Expected SPACE Please specify your keyboard map explicitly via the $_layout option Reading package lists... Error! Segmentation fault UDF-fs: No VRS found Unsupported format "application/postscript" Zope3: no instances found > "Check your spelling, Check your capitalization, check your directory, check > the machine you're logged into, check if it's been renamed, check if it's > been moved to off-line storage, check if it's already been deleted" have > I missed any? I have checked those things, but errors still occur. What should the directories contain, which directory should we be checking? It is often the case that technical reference documentation is required for this. > Any message that is 'incomprehensible' to the _user_ has a very specific > meaning and a SINGLE RESOLUTION -- "refer the problem to someone who does > understand it". I often post requests for resolution on here, and do not get a response. Sometimes I am on a customer site, and need to fix something. Who understands all of the above error messages and know how to eliminate them? Supposing that person that does not all of the above is not available at the time the error message occurs? What are we supposed to do then? Leave the system down? Some organizations do not like thier computers being down. I really need technical reference documentation for all error messages. > An error message like the one you cite is *NOT* something > that a user can do anything about. It is a symptom of a _system_ issue, > and should be referred to a system administrator for resolution. I am the system administrator, and I also provide "help desk" services. > Either way, 'problem solved'. <grin> How is this so. > A compilation of all the basic error messages from any _single_ given > application would be a good thing. Comingling the messages from multiple > applications *IS* a BAD THING(TM). Co-mingling the messages from say > 500 (and there are a *LOT* more than that for UNIX systems) unique a > pplications would be an unmitigated disaster. Why so? Often there is a common problem that applies to more than one system. If the problem is not common, it will have a different reference number. > I have a _basic_ server > set-up, without any graphical desktop support. Over 2100 programs in > the several 'bin' and 'sbin' directories. probably around 100,000 different > errors, 5-10 mb of 'terse' error message text, 25mb of 'explanation' and > a easily a couple of _hundred_ megabytes of 'resolutions'. Now, lets > give those numbers a bit of perspective, A full-size book (say one volume > of an encyclopedia) is around 50-80,000 words. Average 6 characters/word. > roughly half-a-megabyte per volume. It'd take somewhere around 100 volumes > for the master error-message compolation you propose. Does that matter? There are organizations that can host such information. The more documentation that we have available, the better. I would certainly like to see a full technical reference manual that covers all of the software that I use. Using collaborative technology, it should be possible to produce this. Mark. -- Mark Hobley Linux User: #370818 http://markhobley.yi.org/
From: Andrew Reilly on 13 Apr 2010 20:26 On Tue, 13 Apr 2010 22:11:32 +0100, Mark Hobley wrote: > I have checked those things, but errors still occur. What should the > directories contain, which directory should we be checking? It is often > the case that technical reference documentation is required for this. That sort of question is usually answered in the how-to guides and system setup documentation. >> Any message that is 'incomprehensible' to the _user_ has a very >> specific meaning and a SINGLE RESOLUTION -- "refer the problem to >> someone who does understand it". > > I often post requests for resolution on here, and do not get a response. "here" (i.e., usenet) is *not* typically where the "someone who does understand it" folks are paying attention. The *right* place to ask those sorts of questions is to the contact e-mail addresses of the authors or maintainers (or the user-group forums) of the software in question. This is often the appropriate response for commercial software too, by the way. > Sometimes I am on a customer site, and need to fix something. Who > understands all of the above error messages and know how to eliminate > them? Supposing that person that does not all of the above is not > available at the time the error message occurs? What are we supposed to > do then? Leave the system down? When I've been in those situations, (no help in the "documentation" and googling for the exact text of the error message and the name of the application having failed) I've found that grepping for the exact text of the error message (or a kernel that doesn't include any obviously variable parts) in the source code is usually a big help in figuring out what is really going wrong. Most high quality, well-used software (in my experience) *does* have useful documentation and helpful on-line communities. I've only had to poke at source code for odd-ball or pre- release code or little-used device drivers. Needing to "fix" something on a customer site, where the customer is running code that you aren't absolutely intimate with, does sound like a recipe for uncomfortableness, no doubt about it. Cheers, -- Andrew
From: Andrew Reilly on 13 Apr 2010 21:24 Hi again, On Tue, 13 Apr 2010 22:11:32 +0100, Mark Hobley wrote: > Take these error messages: On the off-chance that my guesses might actually be of assistance to you, (unlikley: you appear to be trying to do some multi-media stuff under Zope, which I've never been in contact with), here's a few: > Error 127 The return code from Unix processes is defined to be eight bits, with 0 meaning success and anything else meaning failure. Simple failure is supposed to be 1. Man sysexits lists a few "recommended" non-zero values, but 127 isn't one of them. So: whoever wrote that error was trying to be unhelpful. > A problem was encountered processing your request. The tracker > maintainers > have been notified of the problem. Presumably you tried to submit a bug report (or crash dump), but that didn't work either. Try e-mailing it to someone. > BUG Int 6: CR2 00000000 Sorry, no idea about that. Maybe "interrupt 6" happened unexpectedly, and Condition Register 2 was zero (which suggests that interrupt 6 didn't happen at all, but the handler was entered in error.) Could be a hardware problem. > Bus error That is the common sign of a pointer-dereference bug: memory was accessed that wasn't mapped, and the memory protection hardware told the OS to shut the faulty application down. > codec_read: codec 0 is not valid 0xfe0000 You need to configure some valid codecs, presumably. > Compatibility levels before 4 are deprecated Avoid doing things "the old way". Perhaps you are operating from documentation or user-guides that are no longer valid for the version of whatever it is you're running. Find and use the appropriate documentation. > dzhandle make-instance: ambiguous zope version to make instance for Whatever environmental or in-scope information that is supposed to convey the zope version is wrong or missing. I think that zope is a python thing, which means that the information needed could be anywhere. Start by finding documentation for "make-instance" within the Zope doco, and figure out how you're calling it incorrectly. (This might not be obvious: make-instance is the sort of thing that often lives at the bottom of some factory process, so it could be a question of configuration files not matching installed software modules, or the like.) > E: Error occurred while processing xfmedia-dev (NewVersion1) Anything with the suffix "-dev" attached, or a version like "NewVersion1" is unlikely to be stable. Contact the developers to see if they have a less-broken one. > Error delivering message nnnnn to the MDA "MDA" in this context almost certainly stands for "Mail Delivery Agent": could be that the system that you're trying to get running does not have a working e-mail configuration (does /usr/sbin/sendmail exist and work?) > (gecko:nnnn): Pango-WARNING **: Error loading GPOS table 5503 That *is* just a warning, so you can probably ignore it. gecko is the name of the rendering engine used by Firefox. Pango is the name of the bit of the GTK libraries that look after fonts. You're probably trying to display a web page that has requested a font not installed on your system, or a glyph that isn't part of whatever font is being used in fall- back mode. > giving up. Well, often that's the only course of action available. > (gnome-obex-server:6848): WARNING : Unable to register SDP record for > OPUSH gnome-obex-server has something to do with bluetooth. Presumably OPUSH is part of the/a bluetooth protocol, and it needs an SDP record. Sounds as though you've got an incompatability between the gnome bluetooth stack and the device you're trying to use with it. Try poking around the gnome bluetooth web site. > GRUB GRUB GRUB GRUB GRUB is a boot-loader. If that's unhappy, then presumably your boot disk has died or your installation is mucked up in some fairly fundamental way. Start over. > make[1]: * [all-recursive] Error 1 Make was trying to build the target "all-recursive" and some command exited with return code 1, which just means "EXIT_FAIL": i.e., something broke. The details of what broke are almost certainly contained in the lines of make output preceeding this one. > make: * [all] Error 2 Yeah. Make is definitely unhappy. Look at the lines above to see which command is actually failing, and why. > No CIDSupplement specified for foobar, defaulting to n. No idea. I've written foobar functions myself, but they don't need CIDSupplement arguments, and don't default. Consult the author of the foobar in question. > NO Expected SPACE Some parser, somewhere, wants a space. Give it one. > Please specify your keyboard map explicitly via the $_layout option First page of hits in google is references to dosemu and the dosemu configuration options. I'd say that's the place to look. Dosemu is very, very old. Unless it's being maintained (no idea: I've not had a need for it for many years) it could be that modern, bluetooth keyboards have features that it just can't figure out. > Reading package lists... Error! Some package manager is unhappy with what it found in your installation database. Maybe it has debugging or clean-up options that will help. Or maybe you have to start again. > Segmentation fault This is the coding-bug brother to "Bus error" (look them up on Wikipedia: it's good stuff). Where bus error typically means that the code tried to access memory that wasn't mapped, segmentation fault means that it tried to use memory that was mapped in a way that it wasn't allowed to: like writing to a read-only section of memory. It's just a bug. Contact the code's author. (Or point gdb at the core-dump that should have been created by the OS, and see if you can figure out what the code was trying to do and why.) > UDF-fs: No VRS found UDF is the name of one of the file systems used on CD-ROMs and DVD-ROMs. Presumably yours is broken. You'll need a non-broken copy. > Unsupported format "application/postscript" That's a MIME-type tag, and it means that your system tried to display a postscript file but didn't know how to. Maybe you need to install ghostscript (which is an application that knows how to display application/postscript documents). You'll probably need to tell whichever application that is producing this message about it, though. In the old days the mailcap file did this, but these days it's probably a gnome thing (which means that it'll work automatically if the correct installation incantations are followed.) > Zope3: no instances found Something isn't running that Zope3 thought should be. You'll need to ask someone with more Zope clue than me for that one. Choices are: it didn't start in the first place or it started but stopped before this thing went looking for it. > I really need technical reference documentation for all error messages. That might be what you think you need, but as has been explained, it simply isn't going to happen. So what you really need is a different strategy that doesn't rely on complete knowledge of error messages. > I am the system administrator, and I also provide "help desk" services. Then you need to learn the ins and outs of the products that you administrate better, so that you can provide these services. > I would certainly like to see a full technical reference manual that > covers all of the software that I use. What software are you using that *doesn't* have a full technical reference manual? I'd like to know what to avoid... [That's a rhetorical question. Quite a lot of the software that I use *does* have full technical references available [one of BSD's historical strengths]. Some of it doesn't, and I cross my fingers or use the source. If wishes were horses we'd all be eating steak, as they say.] > Using collaborative technology, > it should be possible to produce this. Google as an index to the entire web is a pretty good first-approximation. Cheers, -- Andrew
From: Marten Kemp on 14 Apr 2010 16:59
Harald Meyer wrote: > unruh wrote: > >>> Okay, what's the explanation *and circumvention* for >>> "Enter the new package tree limit:" from aptitude? >>> The only hits I get from Giggle are posts I've made >>> asking for help. >> Who knows. It is an error message written by a programmer who is >> completely incompetent at writing error messages. > > It is not an error message, it is an incomprehensively named feature he > activated by accident. > >> If you thing such a >> programmer will write to you asking for an error message number and then >> write an explanation for the message for your man page, > > The programmer would tell him to RTFM: > > | aptitude user's manual > (...) > | +--------------------------------------------------------------------------+ > | |Enter the new package tree limit: | > | |apti | > | | [ Ok ] [ Cancel ]| > |Th+--------------------------------------------------------------------------+ > | > | > | > |This dialog works exactly like the search dialog, except that instead of > |highlighting the next package that matches what you typed into the dialog box, > |it hides all packages which don't match. For instance, typing apti into this > |dialog box and pressing Enter will hide all packages except those whose names > |contain ``apti'': > > Harald (hates to post RTFMs) And I got the same result no matter what I typed. As I recall it, I got the message when I entered a plus sign next to apache2-doc. I entered 'apache,' which reduced the number of packages displayed but the message reappeared when I tried to install apache2-doc. Same result with 'apache2' and 'apache2-doc.' I still can't figure out exactly _why_ that message appeared in the first place. I really think that it's the result of a fall-through in the program logic. The message doesn't make any sense, either. If there's some kind of internal limitation then why doesn't the message say so? -- -- Marten Kemp (Fix ISP to reply) You can't help being ignorant 'cause there's always something you don't know; what you can't be is stupid. |