In an early 1.3.x kernel the default console terminal type has 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.
This is usually due to a bad interaction between a brokenness in SLS and the C library release notes. Your libc.a has been replaced by the profiling library. You should remove libc.a, libg.a and libc_p.a and once again install the new libraries (following the release notes, of course).
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?).
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.
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.
If the fault is repeatable (ie, 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 Q9.7 `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 Q6.8 `My machine runs very slowly when I run GCC / X / ...' for more info.
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 maths emulation [Q7.6 `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 it, or it may be able to work and still use the 387, with the maths emulation compiled in but mainly unused.
Much more information about this problem is available on the WWW at http://einstein.et.tudelft.nl/~wolff/sig11
Your root directory and all the directories up to your home directory must be readable and executable by everybody. See the manpage for chmod or a book on Unix for how to fix the problem.
Your /var/run/utmp is screwed up. You should have
> /var/run/utmpin your /etc/rc.local or /etc/rc.d/*. See Q6.11 `I have screwed up my system and can't log in to fix it.' for how to be able to do this. Note that utmp may also be found in /var/adm/utmp or /etc/utmp on some older systems.
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 filesystem checks. It will work fine with older kernels as well, so there's no need to keep the old update around.
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 ?').
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 filesystem that's mounted read-write -- this includes the root partition if you don't see
VFS: mounted root ... read-onlyat boot time. You must arrange to mount the root filesystem readonly 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 filesystem is still read-only and this will otherwise cause it to fail!
This message is issued by the kernel when it mounts a filesystem 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.
Kernels from 1.0 onwards support checking a filesystem 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').
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 /.
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 beyond 1024 this is because standard DOS disk geometry information format in the partition table can't cope with cylinder numbers with more than 10 bits. You should see Q4.1 `How can I get Linux to work with my large disk ?'.
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 good 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.
1. Create partition 1 in the normal way. A p listing will produce the mismatch complaint.
2. Type u to set sector mode and do p again. Copy down the number from the "End" column.
3. Delete partition 1.
4. While still in sector mode recreate 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 noted in 2. above.
5. 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, which are not used if you start the first partition in track 2.
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.
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 manpage 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 discover 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 Q3.2 `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 !
This means that you have an extra large kernel that 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 (Q7.6 `How do I upgrade/recompile my kernel ?').
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).