Tech Insider					     Technology and Trends

		   Linux Activists Mailing List Archives

Subject: A FAQ is coming...
Date: Thu, 19 Dec 91 07:29:21 +0100
From: (Robert Blum)

Hi Linuxers!

Following is a FAQ-compilation (most credits to Linus) for Linux.
Mail me, if you like it, and mail me, if you dislike it or have
any ideas on changing this.

Thanks in advance,
  Robert Blum

QUESTION: What is linux?

ANSWER: Linux is a small unix for 386-AT computers, that has the added
advantage of being free. It is still in beta-testing, but is slowly
getting useful even for somewhat real developement.

QUESTION: Does it run on my computer?

ANSWER: Linux has been written on a clone-386, with IDE drives and a VGA
screen. It should work on most similar setups. The harddisk should be
AT-standard (ie not SCSI, ESDI), and the system must be ISA. Otherwise
the requirements seem relatively small: a 386 (SX, DX or any 486). The
current version (0.10) needs a colour screen adapter, but this is not
the case with the next version.

It needs at least 2M to run, and 4M is definitely a plus. It can happily
use up to 16M (and more if you change some things).

QUESTION: Will linux run on a PC or 286-AT? If not, why?

ANSWER: Linux uses the 386 chip protected mode functions extensively,
and is a true 32-bit operating system. Thus x86 chips, x<3, will simply
not run it.

QUESTION: Does linux do paging? Can I have virtual memory on my small

ANSWER: Linux does use the 386 paging unit, but currently only for
memory management. No use of disks as expansion RAM. This is one of the
things that will be implemented sometime in the (far?) future. Linux
also uses the paging unit to share pages between several processes after
a fork: thus it needs less memory. However, almost all the user programs
available for linux are GNU software, which want gobs and gobs of
memory. This is the reason at least 4M is recommended: GNU cc (gcc)
simply won't run in less.

QUESTION: Can I have tasks spanning the full 4GB of addressable 386
memory? No more 64kB limits like in coherent or standard minix?

ANSWER: Linux does limit the task-size, but at a much more reasonable
64MB (MEGA-byte, not kilos), so bigger programs are no problem.

QUESTION: Does the bigger program sizes mean I can run X?

ANSWER: X is not ported to linux, and though I hope it will be some day,
I cannot guarantee it. It's big, and wants a lot from the system.

QUESTION: Where can I get linux? Is there a mailserver?

ANSWER: Linux can be gotten by anonymous ftp from (
		directory /pub/OS/Linux
	Tupac-Amaru.Informatik.RWTH-Aachen.DE (
		directory /pub/msdos/replace (
		directory /pub/linux (
		directory linux
You might want to check out which of these is the most up-to-date.

If you don't have ftp-capability, you are in trouble. You might try
mailing "" with "help" in the body of the mail.

QUESTION: Is there a newsgroup or mailing-list about linux? Where can I
get my questions answered? How about bug-reports?

ANSWER:  There is a mailing list set up at the address
''.  To join, mail a request to
''. DO NOT mail "I want to
[un]subscribe" to the mailing-list, use the request-address.

Questions and bug-reports can be sent either to the mailing-list or to
"", depending on which you find more

QUESTION: I got the minix-demo, but it won't boot. Linux boots from
floppy. What's wrong?

ANSWER: You probably wrote the minix demo to a 1.44M disk, which (for
some unfathomable reason) doesn't work. The minix demo wants a 720kB or
1.2M disk.

QUESTION:  The minix-demo boots all right, but doesn't seem to recognize
my second harddisk. What's up?

ANSWER: The minix-demo does support a second harddisk, but there are no
special files made for it, and the minix demo doesn't include the
"mknod" command. Mount the linux root-floppy, and use the devices on

QUESTION: How can I be sure I won't be writing over anything important?
I have to use DOS in on my machine, and I don't want to lose any files.

ANSWER: Back up everything. Just in case. Then, write some easily
recognizable pattern to the partition you have reserved for linux, using
some DOS tool. You can then use "cat /dev/hdX" under minix to examine
which of the partitions you used.

QUESTION: Minix mkfs doesn't accept the size I give the device, although
I double-checked with fdisk, and it's correct.

ANSWER: Be sure you give the size in BLOCKS, ie 1024 bytes, not sectors.
Also, make doubly certain that you have the correct partition.

QUESTION: I used the minix mkfs to make a filesystem on /dev/hd3 after
having checked that this was indeed the partition I had reserved. Minix
mounts the new partition ok, but linux doesn't. What gives?

ANSWER: In some cases partitions are numbered differently under minix
and linux. This seems to correlate to the FDISK version you have used.
/dev/hd3 under minix may be /dev/hd2 under linux etc.

There are a few rules about this: /dev/hd0 and /dev/hd5 are always the
same under linux and minix.  DO NOT USE THEM, they are the whole raw
disk, not partitions. Also if a partition is on drive 1 under minix (ie
/dev/hd1-4), it is drive 1 under linux as well.

QUESTION: I mounted the linux filesystem, and copied the files from the
root-disk to the harddisk. Now I cannot find them any more, and
somethimes linux dies with a "panic: trying to free unused inode".

ANSWER: You have probably forgot to sync before rebooting. Linux, like
all unices, use a "buffer cache" to speed up reads and writes to disk.
On a machine that has enough memory, this buffer-cache is 1.5MB, and if
you forget to sync before exiting, it may not be fully written out to
disk. Re-mkfs and re-install (or try to use the preliminary fsck, but
remeber that although fsck tries to correct the faults it finds, it may

QUESTION: the mtools package on the root-disk won't work. I get an
ENOENT error message for all devices.

ANSWER: mtools needs to be told which device to look for. Use 'ln' or
'mknod' to create a sepcial file called "/dev/dosX", where X is A, B or
C. This file should point to the device you want to read.

QUESTION:  Turbo (Microsoft) Assembler won't compile the Linux boot code.
In fact, some of the opcodes in these files look completely unfamiliar.  Why?

ANSWER:  The Linux boot codes are written in Bruce Evans' minix assembler,
which has the same opcodes as the original minix assembler.  There are a few
differences between these and normal DOS assemblers:

 - No segments - everything is in the same segment (at least in the
   bootsectors and setup, as they don't use the .data segments)

 - mov[b|w|l] are shorter versions of mov ax,[byte|word|long] ptr [XXX].
   This is how unix assemblers normally give the size (byte, word or long).
   Gas has similar constructs.

 - There is no "jmp short", the opcodes are "j" for a short jump and
   "jmp" for a long one.

 - "jmpi" is a jump with a segment:offset pair. I don't know how this is
   written in DOS assembly.

QUESTION:  While running du I get "Kernel panic: free_inode: bit already 
cleared".  Also, du produces a ENOENT error for all the files in certain
of my directories.  What's going on?

ANSWER:  These are both consistent with a bad file-system. That's relatively 
easy to produce by not syncing before rebooting, as linux usually has 1.5MB
of buffer space held in memory (unless you have <=4M RAM, in which case
the buffers are only about 0.5MB). Also linux doesn't do anything
special about the bit-map blocks, and as they are used often, those are
the thing most likely to be in memory. If you reboot, and they haven't
been written to disk ...

I'm afraid that as long as there is no fsck for linux there is no way to
correct the matter (unless you have minix and can run minix fsck), and
the only thing to do is to reinstall the filesystem from scratch (ie do
a mkfs from the minix demodisk and reboot from the original

A sync is done only every 30 seconds normally (standard unix practice),
so do one by hand (some people think you should do 3 syncs after each
other, but that's superstition), or by logging out from the
startup-shell, which automatically syncs the system. Unmounting a
filesystem also syncs it (but of course you can never unmount root).

Another (sad) possibility is that you have bad blocks on your disk. Not
very probable, as they would have to be in the inode-tables, just a
couple of blocks in size. Again there aren't programs available to read
a disk for bad sectors and put them in some kind of "bad-sector-file".
On IDE drives this is no problem (bad sectors are automatically mapped

QUESTION:  What is the "em" binary?

ANSWER:  Em is micro-EMacs (probably version 3.10).

QUESTION: I seem to be unable to compile anythong with gcc. Why?

ANSWER: If you have only 2 MB RAM, gcc will die silently without compiling
	anything. You must have at least 4 MB to do compilations  

QUESTION:  I'm using a program that uses signal handlers which are installed
using sigaction() with the SA_NOMASK, and they get a general protection
error right after the signal handler tries to return.  What's going

ANSWER:  You are using a libc.a that has an out-of-date signal.o and
sig_restore.o file, and they don't know how to deal with SA_NOMASK.
(The one in gccbin.tar.Z is out-of-date.)  You can obtain the newer
signal.c from the unistd.tar.Z file, but don't use the associated
sig_restore.c from there; the FTP sites should have a separate
sig_restore.c which is up to date.  While you're at it, you should also
get an updated crt0.c file as well, and install your new crt0.o and
libc.a in /usr/lib.

(This answer will likely change in the near future, since there are
plans to change the format of the signal trampoline code yet again....
but for now, this should be an accurate description of how things stand

QUESTION: gcc complains about not finding crt0.o and the system include files
What am i doing wrong ?

ANSWER: The include files normal place is in /usr/include. libc.a and *.a 
should be in /usr/lib

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO v IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or

Electronic mail:			       WorldWideWeb: