From news.hwcn.org!informer1.cis.McMaster.CA!hone!torn!news.internetMCI.com!newsfeed.internetmci.com!207.114.4.11!nntp.abs.net!news1.ispnews.com!news11.ispnews.com!terracom.net!kiesling Tue Aug 18 12:50:23 1998 Path: news.hwcn.org!informer1.cis.McMaster.CA!hone!torn!news.internetMCI.com!newsfeed.internetmci.com!207.114.4.11!nntp.abs.net!news1.ispnews.com!news11.ispnews.com!terracom.net!kiesling From: kiesling@terracom.net Newsgroups: comp.os.linux.announce,comp.os.linux.misc,news.answers,comp.answers Subject: Linux Frequently Asked Questions with Answers (Part 3 of 3) Followup-To: poster Date: 17 Aug 1998 01:04:15 GMT Organization: ISPNews http://ispnews.com Lines: 748 Approved: news-answers-request@MIT.EDU Message-ID: <6r7vif$em7$1@news12.ispnews.com> NNTP-Posting-Host: long.distance.net X-Trace: news12.ispnews.com 903315855 15047 209.69.148.254 (17 Aug 1998 01:04:15 GMT) NNTP-Posting-Date: 17 Aug 1998 01:04:15 GMT Originator: kiesling@terracom.net Xref: news.hwcn.org comp.os.linux.announce:10570 comp.os.linux.misc:278176 news.answers:123051 comp.answers:26208 Archive-Name: linux/faq/part3 Posting-Frequency: weekly 8. Frequently encountered error messages. 8.1 Unknown terminal type linux and similar. In an early 1.3.x kernel the default console terminal type was changed from console to linux. You must edit /etc/termcap to change the line reading: console|con80x25:\ to linux|console|con80x25:\ (there may be an additional dumb in there--if so it should be removed.) In order to get the editor to work you may need say TERM=console (for bash and ksh) or setenv TERM console (csh, tcsh) first. Some programs use /usr/lib/terminfo instead of /etc/termcap. For these programs you should upgrade your terminfo, which is part of ncurses. 8.2 lp1 on fire This is a joke/traditional error message indicating that some sort of error is being reported by your printer, but that the error status isn't a valid one. It may be that you have some kind of I/O or IRQ conflict - check your cards' settings. Some people report that they get this message when their printer is switched off. Hopefully it isn't really on fire ... In newer kernels, this message reads, "lp1 reported invalid error status (on fire, eh?)" 8.3 INET: Warning: old style ioctl... called! You are trying to use the old network configuration utilities. The new ones can be found on ftp.linux.org.uk in /pub/linux/Networking/PROGRAMS/NetTools (source only, I'm afraid). Note that they cannot be used just like the old-style programs. See the NET-2 HOWTO for instructions on how to set up networking correctly. 8.4 ld: unrecognized option '-m486' You have an old version of ld. Install a newer binutils package--this will contain an updated ld. Look on tsx-11.mit.edu in /pub/linux/packages/GCC for binutils-2.6.0.2.bin.tar.gz. 8.5 GCC says Internal compiler error. If the fault is repeatable (i.e., it always happens at the same place in the same file--even after rebooting and trying again, using a stable kernel) you have discovered a bug in GCC. See the GCC Info documentation (type Control-h i in Emacs, and select GCC from the menu) for details on how to report this--make sure you have the latest version, though. Note that this is probably not a Linux-specific problem; unless you were compiling a program many other Linux users also compile, you should not post your bug report to any of the comp.os.linux groups. If the problem is not repeatable you are very probably experiencing memory corruption--see make says Error 139. 8.6 make says Error 139 Your compiler driver (gcc) dumped core. You probably have a corrupted, buggy or old version of GCC--get the latest release. Alternatively you may be running out of swap space--see My machine runs very slowly when I run GCC / X / .... If this doesn't fix the problem you are probably having problems with memory or disk corruption. Check that the clock rate, wait states and refresh timing for your SIMMs and cache are correct (hardware manuals are sometimes wrong, too). If so you may have some dodgy SIMMs or a faulty motherboard or hard disk or controller. Linux, like any Unix, is a very good memory tester--much better than DOS-based memory test programs. Reportedly some clone x87 maths coprocessors can cause problems; try compiling a kernel with math emulation ( How do I upgrade/recompile my kernel?.) You may need to use the no387 kernel command line flag on the LILO prompt to force the kernel to use math emulation, or it may be able to work and still use the '387, with the math emulation compiled in but mainly unused. Much more information about this problem is available on the Web at http://www.bitwizard.nl/sig11/. 8.7 shell-init: permission denied when I log in. Your root directory and all the directories up to your home directory must be readable and executable by everybody. See the manual page for chmod or a book on Unix for how to fix the problem. 8.8 No utmp entry. You must exec ... when I log in. Your /var/run/utmp is screwed up. You should have > /var/run/utmp in your /etc/rc.local or /etc/rc.d/*. See ("I have screwed up my system and can't log in to fix it.") Note that utmp may also be found in /var/adm/utmp or /etc/utmp on some older systems. 8.9 Warning--bdflush not running. Modern kernels use a better strategy for writing cached disk blocks. In addition to the kernel changes, this involves replacing the old update program which used to write everything every 30 seconds with a more subtle daemon (actually a pair), known as bdflush. Get bdflush-n.n.tar.gz from the same place as the kernel source code (Q7.6 `How do I upgrade/recompile my kernel ?') and compile and install it; it should be started before the usual boot-time file system checks. It will work fine with older kernels as well, so there's no need to keep the old update around. 8.10 Warning: obsolete routing request made. This is nothing to worry about; it just means that the version of route you have is a little out of date compared to the kernel. You can make the message go away by getting a new version of route from the same place as the kernel source code (Q7.6 `How do I upgrade/recompile my kernel ?'). 8.11 EXT2-fs: warning: mounting unchecked file system. You need to run e2fsck (or fsck -t ext2 if you have the fsck front-end program) with the -a option to get it to clear the `dirty' flag, and then cleanly unmount the partition during each shutdown. The easiest way to do this is to get the latest fsck, umount and shutdown commands, available in Rik Faith's util-linux package (Q2.5 `Where can I get Linux material by FTP?'). You have to make sure that your /etc/rc* scripts use them correctly. NB: don't try to check a file system that's mounted read-write--this includes the root partition if you don't see VFS: mounted root ... read-only at boot time. You must arrange to mount the root file system read-only to start with, check it if necessary, and then remount it read-write. Read the documentation that comes with util-linux to find out how to do this. Note that you need to specify the -n option to mount to get it not to try to update /etc/mtab, since the root file system is still read-only and this will otherwise cause it to fail! 8.12 EXT2-fs warning: maximal count reached. This message is issued by the kernel when it mounts a file system that's marked as clean, but whose `number of mounts since check' counter has reached the predefined value. The solution is to get the latest version of the ext2fs utilities (e2fsprogs-0.5b.tar.gz at the time of writing) from the usual sites (Q2.5 `Where can I get Linux material by FTP ?'). The maximal number of mounts value can be examined and changed using the tune2fs program from this package. 8.13 EXT2-fs warning: checktime reached. Kernels from 1.0 onwards support checking a file system based on the elapsed time since the last check as well as by the number of mounts. Get the latest version of the ext2fs utilities (see Q9.13 `EXT2-fs warning: maximal count reached'). 8.14 df says Cannot read table of mounted file systems. There is probably something wrong with your /etc/mtab or /etc/fstab files. If you have a reasonably new version of mount, /etc/mtab should be emptied or deleted at boot time (in /etc/rc.local or /etc/rc.d/*), using something like rm -f /etc/mtab* Some versions of SLS have an entry for the root partition in /etc/mtab made in /etc/rc* by using rdev. This is incorrect--the newer versions of mount do this automatically. Other versions of SLS have a line in /etc/fstab that looks like: /dev/sdb1 /root ext2 defaults This is wrong. /root should read simply /. 8.15 fdisk says Partition X has different physical/logical ... If the partition number (X, above) is 1 this is the same problem as Q9.17 `fdisk: Partition 1 does not start on cylinder boundary'. If the partition begins or ends on a cylinder numbered greater than 1024, this is because the standard DOS disk geometry information format in the partition table can't cope with cylinder numbers with more than 10 bits. You should see "How can I get Linux to work with my disk?" 8.16 fdisk: Partition 1 does not start on cylinder boundary The version of fdisk that comes with many Linux systems creates partitions that fail its own validity checking. Unfortunately, if you've already installed your system, there's not much you can do about this, apart from copying the data off the partition, deleting and remaking it, and copying the data back. You can avoid the problem by getting the latest version of fdisk, from Rik Faith's util-linux package (available on all the usual FTP sites). Alternatively, if you are creating a new partition 1 that starts in the first cylinder, you can do the following to get a partition that fdisk likes. * Create partition 1 in the normal way. A `p' listing will produce the mismatch complaint. * Type `u' to set sector mode and do `p' again. Copy down the number from the "End" column. * Delete partition 1. * While still in sector mode, re-create partition 1. Set the first sector to match the number of sectors per track. This is the sector number in the first line of the `p' output. Set the last sector to the value you wrote down in the step above. * Type `u' to reset cylinder mode and continue with other partitions. Ignore the message about unallocated sectors--they refer to the sectors on the first track apart from the Master Boot Record, and they are not used if you start the first partition in track 2. 8.17 fdisk says partition n has an odd number of sectors. The PC disk partitioning scheme works in 512-byte sectors, but Linux uses 1K blocks. If you have a partition with an odd number of sectors, the last sector is wasted. Ignore the message. 8.18 mtools says cannot initialize drive XYZ This means that mtools is having trouble accessing the drive. This can be due to several things. Often this is due to the permissions on floppy drive devices (/dev/fd0* and /dev/fd1*) being incorrect--the user running mtools must have the appropriate access. See the manual page for chmod for details. Most versions of mtools distributed with Linux systems (not the standard GNU version) use the contents of a file /etc/mtools to determine which devices and densities to use, in place of having this information compiled into the binary. Mistakes in this file often cause problems. There is often no documentation about this--distribution packagers, please note that this is evil. For the easiest way to access your DOS files (especially those on a hard disk partition) see How do I access files on my DOS partition or floppy? Note--you should never use mtools to access files on an msdosfs mounted partition or disk! 8.19 At the start of booting: Memory tight This means that you have an extra large kernel, which means that Linux has to do some special memory-management magic to be able to boot itself from the BIOS. It isn't related to the amount of physical memory in your machine. Ignore the message, or compile a kernel containing only the drivers and features you need . (See, "How do I upgrade/recompile my kernel?)" 8.20 My syslog says `end_request: I/O error, ...'. Peter Moulder, pjm@bofh.asn.au, noted that this should be a FAQ. This error message, and messages like it, almost always indicates a hardware error with a hard drive. Theodore T'so, tytso@mit.edu, noted that this commonly indicates of a hard drive defect. The only way to avoid further data loss is to completely shut own the system. You must also make sure that the whatever data is on the drive is backed up, and restore it to a non-defective hard drive. This error message may also indicate a bad connection to the drive, especially with homebrew systems. If you install an IDE drive yourself, ALWAYS use new cables. This probably isn't a bad idea with SCSI drives, too. This error also seemed to coincide with a grounding problem between the system board and the chassis on one machine. Be sure that all electrical connections are clean and tight before placing the blame on the hard drive itself. 8.21 You don't exist. Go away. This is not a viral infection :-). It comes from various programs such as write, talk, and wall, if your invoking uid doesn't correspond to a valid user (probably due to /etc/passwd being corrupted), or if the session (pseudoterminal, specifically) you're using isn't properly registered in the utmp file (probably because you invoked it in a funny way). 9. The X Window System. 9.1 Does Linux support X Windows? Yes. Linux uses XFree86 (the current version is 3.3.2, which is based on X11R6). You need to have a video card which is supported by XFree86. See the Linux XFree86 HOWTO for more details. Most Linux distributions nowadays come with an X installation. However, you can install or upgrade your own, from /pub/Linux/X11/Xfree86-* on sunsite.unc.edu and its mirror sites. Read the XFree86 HOWTO for installation instructions. 9.2 Where can I get an XF86Config for my system? See the Linux XFree86 HOWTO. You'll need to put together your own XF86Config file, because it depends on the exact combination of video card and monitor you have. It's not that hard--read the instructions that came with XFree86, in /usr/X11R6/lib/X11/etc. The file you probably need to look at most is README.Config. You should not use the sample XF86Config.eg file which is included with newer versions of XFree86 verbatim, because the wrong video clock settings can damage your monitor. For a quick start, you may run the program xf86config. Note that ConfigXF86 is obsolete, and you shouldn't use it. Please don't post to comp.os.linux.x asking for an XF86Config, and please don't answer such requests. 9.3 xterm logins show up strangely in who, finger. The xterm that comes with XFree86 2.1 and earlier doesn't correctly understand the format that Linux uses for the /var/adm/utmp file, where the system records who is logged in. It therefore doesn't set all the information correctly. The Xterms in XFree86 3.1 and later versions fix this problem. 9.4 I can't get X Windows to work right. Read the XFree86 HOWTO--note the question and answer section. Try reading comp.windows.x.i386unix--specifically read the the FAQ for that group. Please don't post X Windows or XFree86 related questions to comp.os.linux.x unless they are Linux-specific. 10. Questions applicable to very out-of-date software. The questions in this section are only relevant to users of software that is at least three months old. Please let me know if you find the answer to a problem you had here, as unused questions in this section will eventually disappear. (See " Feedback is invited.") 10.1 fdisk says cannot use nnn sectors of this partition. Originally Linux only supported the Minix file system, which cannot use more than 64Mb per parition. This limitation is not present in the more advanced file systems that are now available, such as ext2fs (the 2nd version of the Extended File System, the `standard' Linux file system). If you intend to use ext2fs you can ignore the message. 10.2 GCC sometimes uses huge amounts of virtual memory and thrashes. Older versions of GCC had a bug that made them use lots of memory if you tried to compile a program which had a large static data table in it. You can either upgrade your version of GCC to at least version 2.5, or add more swap if necessary and just grin and bear it; it'll work in the end. 11. How to get further assistance. 11.1 You still haven't answered my question! Please read all of this answer before posting. I know it's a bit long, but you may be about to make a fool of yourself in front of 50,000 people and waste hundreds of hours of their time. Don't you think it's worth it to spend some of your time reading and following these instructions? If you think an answer is incomplete or inaccurate, please e-mail Robert Kiesling at kiesling@terracom.net. Read the appropriate Linux Documentation Project books--see " Where can I get the HOWTOs and other documentation?" If you're a Unix newbie, read the FAQ for comp.unix.questions, and those for any of the other comp.unix.* groups that may be relevant. Linux is a Unix clone, so almost everything you read there will apply to Linux. Those FAQs can, like all FAQs, be found on rtfm.mit.edu in /pub/usenet/news.answers (the mail-server@rtfm.mit.edu can send you these files, if you don't have FTP access). There are mirrors of rtfm's FAQ archives on various sites - check the Introduction to *.answers posting, posted, or look in news-answers/introduction in the directory above. Check the relevant HOWTO for the subject in question, if there is one, or an appropriate old-style sub-FAQ document. Check the FTP sites. Try experimenting--that's the best way to get to know Unix and Linux. Read the documentation. Check the manual pages (type "man man" if you don't know about manual pages. Try "man -k subject"--it often lists useful and relevant manpages. Check the Info documentation (type C-h i, i.e. Control H followed by I in Emacs)--NB: this isn't just for Emacs; for example the GCC documentation lives here as well. There will also often be a README file with a package that gives installation and/or usage instructions. Make sure that you don't have a corrupted or out-of-date copy of the program in question. If possible, download it again and re-install it--perhaps you made a mistake the first time. Read comp.os.linux.announce--this often contains very important information for all Linux users. General X-Windows questions belong in comp.windows.x.i386unix, not in comp.os.linux.x. But read the group first (including the FAQ), before you post! Only if you have done all of these things and are still stuck should you post to the appropriate comp.os.linux.* newsgroup. Make sure you read the next question, Q12.2 `What to put in a request for help', first. 11.2 What to put in a request for help. Please read carefully the following advice about how to write your posting or email. Taking heed of it will greatly increase the chances that an expert or fellow user reading it will have enough information and motivation to reply. This advice applies both to postings asking for advice and to personal email sent to experts and fellow users. Make sure you give full details of the problem, including: * What program, exactly, you are having problems with. Include the version number if known and say where you got it. Many standard commands tell you their version number if you give them a --version option. * Which Linux release you're using (Red Hat, Slackware, Debian, or whatever) and what version of that release. * The exact and complete text of any error messages printed. * Exactly what behaviour you were expecting, and exactly what behaviour you observed. A transcript of an example session is a good way of showing this. * The contents of any configuration files used by the program in question and any related programs. * What version of the kernel and of the shared libraries you are using. The kernel version can be found by typing uname -a, and the shared library version by typing ls -l /lib/libc.so.4. * Details of what hardware you're running on, if it seems appropriate. You are in little danger of making your posting too long unless you include large chunks of source code or uuencoded files, so err on the side of giving too much information. Use a clear, detailed Subject line. Don't put things like `doesn't work', `Linux', `help' or `question' in it--we already know that! Save the space for the name of the program, a fragment of the error message, summary of the unusual behaviour, etc. If you are reporting an `unable to handle kernel paging request' message, follow the instructions in the Linux kernel sources README for turning the numbers into something more meaningful. If you don't do this, no one who reads your post will be able to do it for you, as the mapping from numbers to function names varies from one kernel to another. Put a summary paragraph at the top of your posting. At the bottom of your posting, ask for responses by email and say you'll post a summary. Back this up by using Followup-To: poster. Then, do actually post a summary in a few days or a week or so. Don't just concatenate the replies you got--summarise. Putting the word SUMMARY in your summary's Subject line is also a good idea. Consider submitting the summary to comp.os.linux.announce. Make sure your posting doesn't have an inappropriate References header line. This marks your article as part of the thread of the article referred to, which will often cause it to be junked by readers, along with the rest of a boring thread. You might like to say in your posting that you've read this FAQ and the appropriate HOWTOs--this may make people less likely to skip your posting. Remember that you should not post email sent to you personally without the sender's permission. 11.3 I want to mail someone about my problem. Try to find the author or developer of whatever program or component is causing you difficulty. If you have a contact point for your Linux distribution, you should use it. Please put everything in your email that you would put in a posting asking for help. Finally, remember that despite the fact that most of the Linux community are very helpful and responsive to emailed questions, you'll be asking for help from an unpaid volunteer, so you have no right to expect an answer. 12. Administrative information and acknowledgements. 12.1 Feedback is invited. Please send me your comments on this FAQ. I accept submissions for the FAQ in any format; All contributions, comments, and corrections are gratefully received. Please send them to kiesling@terracom.net. If you wish to refer to a question(s) in the FAQ, it's most useful for me if you do so by the question heading, rather than the number, as the question numbers are generated automatically and I don't see them in the source file I edit. I prefer comments in English to patch files--I context diff is not my first language. 12.2 Formats in which this FAQ is available. This document is available as an ASCII text file, an HTML World Wide Web page, PostScript, and as a USENET news posting. All of these formats are generated from SGML source using SGML Tools and the LinuxDoc DTD. The HTML version of this FAQ is available as http://sunsite.unc.edu/LDP/ at other sites. The Usenet version is posted regularly to comp.os.linux.announce, comp.answers, and news.answers. The most recent text, HTML, source, and PostScript versions are available from the Linux archives at sunsite.unc.edu, and from http://www.terracom.net/~kiesling 12.3 Authorship and acknowledgements. This FAQ is compiled and maintained by Robert Kiesling kiesling@terracom.net, with assistance and comments from Linux activists all over the world. Special thanks are due to Matt Welsh, who moderated comp.os.linux.announce and comp.os.linux.answers, coordinated the HOWTOs and wrote substantial portions of many of them, Greg Hankins and Timothy Bynum, the former and current HOWTO maintainers, Lars Wirzenius and Mikko Rauhala, the former and current moderators of comp.os.linux.announce, Marc-Michel Corsini, who wrote the original Linux FAQ, and Ian Jackson, the previous FAQ maintainer. Thanks also to Roman Maurer for his many updates and additions, especially with European Web sites, translations, and general miscellany. Last but not least, thanks to Linus Torvalds and the other contributors to Linux for giving us something to talk about! 12.4 Disclaimer and Copyright. Note that this document is provided `as is'. The information in it is not warranted to be correct. Use it at your own risk. Linux Frequently Asked Questions with Answers is Copyright (c) 1997, 1998 by Robert Kiesling kiesling@terracom.net, under the copyright of the Linux Documentation Project. The full text of the LDP copyright is available via anonymous FTP from sunsite.unc.edu, in the directory /pub/Linux/docs/LDP, and is included below. Portions are Copyright (c) 1994, 1995, 1996 by Ian Jackson, the previous Linux FAQ maintainer. Linux Frequently Asked Questions with Answers may be reproduced and distributed in its entirety (including this authorship, copyright, and permission notice), provided that no charge is made for the document itself, without the author's consent. Portions may be reproduced for such purposes as reviews, advertising, and derivative works like translations, with the author's consent. Note that this restriction is not intended to prohibit charging for the service of printing or copying a document supplied by your customer. Exceptions to these rules may be granted. I would be happy to answer any questions about this copyright. Email me at kiesling@terracom.net. As the license below says, these restrictions are here to protect the contributors, not to restrict you as educators and learners. LINUX DOCUMENTATION PROJECT COPYING LICENSE Last modified 6 January 1997 The following copyright license applies to all works by the Linux Documentation Project. Please read the license carefully---it is somewhat like the GNU General Public License, but there are several conditions in it that differ from what you may be used to. If you have any questions, please email the LDP coordinator, mdw@sunsite.unc.edu. The Linux Documentation Project manuals may be reproduced and distributed in whole or in part, subject to the following conditions: All Linux Documentation Project manuals are copyrighted by their respective authors. THEY ARE NOT IN THE PUBLIC DOMAIN. * The copyright notice above and this permission notice must be preserved complete on all complete or partial copies. * Any translation or derivative work of Linux Installation and Getting Started must be approved by the author in writing before distribution. * If you distribute Linux Installation and Getting Started in part, instructions for obtaining the complete version of this manual must be included, and a means for obtaining a complete version provided. * Small portions may be reproduced as illustrations for reviews or quotes in other works without this permission notice if proper citation is given. * The GNU General Public License referenced below may be reproduced under the conditions given within it. Exceptions to these rules may be granted for academic purposes: Write to the author and ask. These restrictions are here to protect us as authors, not to restrict you as educators and learners. All source code in Linux Installation and Getting Started is placed under the GNU General Public License, available via anonymous FTP from the GNU archive site. PUBLISHING LDP MANUALS If you're a publishing company interested in distributing any of the LDP manuals, read on. By the license given in the previous section, anyone is allowed to publish and distribute verbatim copies of the Linux Documentation Project manuals. You don't need our explicit permission for this. However, if you would like to distribute a translation or derivative work based on any of the LDP manuals, you must obtain permission from the author, in writing, before doing so. All translations and derivative works of LDP manuals must be placed under the Linux Documentation License given in the previous section. That is, if you plan to release a translation of one of the manuals, it must be freely distributable by the above terms. You may, of course, sell the LDP manuals for profit. We encourage you to do so. Keep in mind, however, that because the LDP manuals are freely distributable, anyone may photocopy or distribute printed copies free of charge, if they wish to do so. We do not require to be paid royalties for any profit earned from selling LDP manuals. However, we would like to suggest that if you do sell LDP manuals for profit, that you either offer the author royalties, or donate a portion of your earnings to the author, the LDP as a whole, or to the Linux development community. You may also wish to send one or more free copies of the LDP manual that you are distributing to the author. Your show of support for the LDP and the Linux community will be very appreciated. We would like to be informed of any plans to publish or distribute LDP manuals, just so we know how they're becoming available. If you are publishing or planning to publish any LDP manuals, please send email to Matt Welsh (email mdw@sunsite.unc.edu). We encourage Linux software distributors to distribute the LDP manuals (such as the Installation and Getting Started Guide) with their software. The LDP manuals are intended to be used as the "official" Linux documentation, and we'd like to see mail-order distributors bundling the LDP manuals with the software. As the LDP manuals mature, hopefully they will fulfill this goal more adequately. Matt Welsh, mdw@sunsite.unc.edu -- Robert Kiesling kiesling@terracom.net ..No writing gig too small...