Right ho, the subject says it all ... Linux could definitely do with a
FAQ (Frequently Asked Questions for all you who haven't been on the net
all your life :-). And as I'm sure anybody who has read my "help-files"
would agree, I'm not the best possible person to write it. Thus a new
project: getting a FAQ done with help from the linux-activists.

I've talked (yes, you can try to talk with me if I'm logged in) with
Robert Blum, and he's promised to help. Our idea was to get as many of
the linux users/would be users to ask questions they think ought to be
in the FAQ, and hopefully you could try to answer them too (and don't be
shy just because you aren't certain you get it right - I'll go through
the FAQ for techical soundness anyway, but your answers will make
editing much easier).

I'm especially interested in some tutorials/"true stories" from people
who installed linux without the help of minix. Not only will they help
make the FAQ, but I could try to make things easier for the next
version. The FAQ should also contain some pointer to what people are
doing, and what has been done (like init/login, the bison port, g++,
etc).

I guess the easiest way to organize this thing is to mail me with a
subject containing "FAQ". I'll then compile it to one big thing and
send it out to whoever wants to edit on it. If you want to be one of
the people working on it, please mail and say so. I'll be happier the
less I have to do with this thing :-), and even if you just think you
could try to check for things you find incomprehensible, mail me and
tell me you'd like to help with it. Alternatively, you can mail Robert
Blum (whom I happily let take over the main responsibility for this
thing if he wants it) at "blum@messua.informatik.rwth-aachen.de".

If you can get your grubby little hands on the minix FAQ, you could try
to make a skeleton one for linux, trying to answer the questions
yourself first, and adding/removing questions of your own. Also, please
resend the questions you've already asked (and hopefully got answered),
as I really cannot sift through all my mail looking for questions, and
rewriting the answers (my mailbox is about 400kB - most of it on linux).
Editing the whole thing would probably be easier if you did some
pre-editing yourself: trying to get the thing to look like part of a
FAQ.

After we have gotten something that looks like a real FAQ (possibly
divided it into several parts: one general FAQ, one on installation
etc), I (or Blum) will post it to the mailing-list and set it up for
ftp. It will take some time: waiting for questions, then editing them,
mailing the new versions to the persons interested in this project,
revising them again after comments ... But hopefully we'll have a
better FAQ after that. I hope enough people mail questions/interest,
that I personally can get on to write the system programs.

I'd suggest a simple form for all the questions/answers: Something that
can easily be (semi-)automatically edited into something more
appropriate:

If you honestly haven't got a clue about the answer, please still ask
the question - nobody will flame you (sure, sure).

Linus (torvalds@kruuna.helsinki.fi)

PS. It seems most people who had problems have got it working now. To
summarize: It works on SX's and with only 2M of memory. It also "works"
with a monochrome card, but you won't be able to see anything. Mtools
doesn't understand DOS 5.0 (big partitions at least), but Linux seems to
boot ok anyway. Anybody who simply cannot get it to boot out there?

PPS. I wrote over my minix-partition yesterday (don't even ask why -
some things are better forgotten :-), and although I got minix-386 up
and running again, it's kind of limping now (no bash, no make). It seems
I'll have to write fdisk/mkfs/fsck for linux just so that I wouldn't
need minix any more. Something good came out of it.

PPPS. As there still isn't a fsck-program for linux, be very careful
about rebooting the computer without syncing. The buffer cache is /at
least/ 500kB, and 1.5M buffer-cache is normal for machines with more
memory, so if you don't sync, there could be A LOT of buffers that
aren't written out to disk.

I, too, I have managed to bring up Linux without the need of Minux. I
have a 40 MhZ AMD 386 with a 200 Meg clone. A couple of notes:

N1) The Minix demo disk which you can get from plains.novak.edu only
works for 5.25" disks --- this isn't documented anywhere, but I spent a
lot of time trying to get it to boot on my 3.5" A drive. It would print
the first message about "loading Minix system", but it would hang before
printing the menu. I finally had to give up, recable my drives so that
my 5" drive was my A drive to get Minix to come up.

N2) The numbering convestion for partition in Minix and Linux are
different!!! The way I dealt with it is to use a disk editor to write a
message "This is the Linux parittion" in the first sector of the
partition, and then use "head -3 /dev/hd[014]" to find the right
partition number on both Minix and Linux.

N3) I have MS-DOS 5.0, and the mtools worked just fine on my hard disk.
All of my partitions are less than 32 MEG, so I'm still using the FAT-16
filesystem. It would be nice if Linux understood the DOS extended
partitions, though. This would allow mtools could read my other DOS
partitions. In addition, it would mean that I could use one of the DOS
extended partitions as Linux partitions, so I could avoid chewing up
the 4 primary partitions available on my 200 meg drive.

[ Note: whoever decided that IBM hard disks only needed 4 partitions
should be condemned to recabling machine room floors; CP/M on
Heath/Zenith machines had 8 partitions available, and much more friendly
tools to modify said table! ]

N4) I have also experienced the panic which Patrick L. McGillan has
described. I suspect DOS setting some cruft which isn't getting cleaned
up. The panic happens happens right after the "Loading system" and
before the system has a chance to print the "Partition tables ok" message.

N5) I have managed to build the Linux kernel under Linux, using the 16
bit binaries which Linus provided. One little gotcha is that it is
necessary to rename the binaries provided in gccbin.tar.Z to the names
which the Makefile is expecting. Other than that, though, things went
very smoothly.

N6) It wasn't obvious that the "em" program in utilbin.tar.Z was
actually MicroEmacs. I was really happy once I found it, though!
Perhaps there should be a quick note mentioning this fact somewhere. At
the moment, the programs which I seem to be missing the most are 1)
more, 2) gdb, and 3) fsck. The first should be a lot easier to get
working than the last. :-)

And now, for some questions:

Q1) On nic.funet.fi, I found sources to shoelace, which seems to be a
way to boot Minix without needing a floppy boot disk. Is anyone working
on something similar for Linux? The other interesting thing about
shoelace is that it came with a file "shoefsck.c" which seems to contain
the necessary code filesystem checking for Minix. However, there's no
copyright notice on that file, and no email address for the author,
either. Does anyone know what the status of that code is? I was
considering trying to use that code to make a fsck for Minix.

Q2) Similarily, there are sources on nic.funet.fi for a fsck program for
Minix. It looks like it was derived from the Minix fsck, but since it
is available for anonymous FTP with no notices saying "don't touch
this", I wonder if would be consider fair play to base a fsck for Linux
on the code, and either distribute the code or patches to the code with
a note that you can get the rest of the program from nic.funet.fi.

Q3) Linus, can you provide the configuration files for gcc and friends?
It would be interesting to see what's necessary to actually compile
one's own version of gcc/gas/etc.

Thanks to everyone on the list! I don't think I would have managed to
get Linux up and running with out a lot of helpful hints which were
posted on the list --- and I've only been on the list for a couple of
days!

Ok, This is version 0.10 of the fsck program for linux. Everyone is
encouraged to use the (old) minix fsck program available on nic if they
want to, but as it isn't clear what the status of it is, I would rather
have one especially made for linux. This is it.

It's a fast hack (2 days), but it seems to work relatively well. It
doesn't repair a destroyed file-system, but it should tell you about
problems. Repair is on the way...

The reason I'm posting this is that I would like to get all the bugs
ironed out before it starts writing to a disk. Now it just reads, so
this version will not f**k anything up, even if it has bugs (and
hopefully there aren't any). Although it isn't commented, it might give
you an idea of what the file-system looks like.

This is NOT a standalone version to be used at bootup. It is meant to be
compiled and used under linux, on filesystems that aren't mounted. You
can use it on root, assuming there is nothing writing to the disk (and
this includes fsck itself: don't use "fsck -l rootdev > tmp" or
similar). This isn't recommended though (you might have two boot-disks,
one which boots from floppy just to use fsck on the normal
boot-partition).

Ok, here's the new buffer.c-file, hopefully correcting the bug which
caused file system inconsistencies.

NOTE! This file is NOT official, and won't be used as a starting point
for future kernel cdiffs. Thus save the old buffer.c before using this.
It's just a temporary bug fix before a real release (which should come
out in December). Hopefully these kind of rather urgent bug-fixes won't
be too usual.

The changes are mostly to "getblk()", and are not final: it's a bug-fix,
and I'll have to tweak it a bit more for the real version. The current
version works fine, but it's a bit overzealous in trying to avoid
reclaiming dirty blocks: with this kernel patch the buffer-cache VERY
easily fills up with dirty blocks, at the expense of ordinary ones.
Thus "sync"ing is even more important with this fix: the dirty blocks
are kept around longer (too long in my opinion) with this routine.

Linus (torvalds@kruuna.helsinki.fi)

PS: Re: Math libraries. There aren't any. When I talk about gcc
soft-float, I'm just talking about the general idea - I haven't
implemented (or ported) any real math functions. The only floating
point math that gcc currently knows about is add/sub/neg/mul/div (and
only for doubles, not floats). Gcc in the original 1.40-version cannot
handle soft-floats correctly: linux gcc has this corrected (thanks
mainly to bruce evans), but not used very much.

Hi again. Several people have inquired about mtools. The sources I
used are available on nic.funet.fi: pub/unix/386ix/isc/source/mtools*.
I don't know if this is the most recent version. And no - linux
probably cannot read partitions >64MB. The reason is (partly) the minix
file system. See later.

Paging to disk has also come up: It will certainly be implemented (in
fact one of the bigger changes in the 0.10 fs was due to making ready
for this). There are no obvious problems with this, but unless somebody
else wants to try to implement it, it will take some time (I'm talking
March-92 at the earliest, probably not until summer). One of my problems
is (will be) lack of disk-space to try it out on.

As for demand-loaded executables... hmm. There are a couple of problems
with this: the minix filesystem wasn't meant for it, and it would be
MUCH easier to implement if BLOCK_SIZE was 4096 (= one page) instead of
the current 1024. This of course means waste of disk-space. The problem
with the minix filesystem isn't that serious: I'll have to move on to
something else anyway - 64M partitions can be limiting for those who have
disks big enough to hold them (and the afore-mentioned 64Mb limit even
for direct read/writes.. This I can try to do something about).

The more serious problem about demand-loading is that the fs isn't
really designed for it - I doubt the locking mechanism used currently
will suffice. If people would accept a non-locking demand-loading (ie
you could write to the file while it's in use etc...) I could possibly
try to implement it. Again - not until well into -92.

And a little small sad note: I know I said symlinks would probably be in
the next version, but unless I can get the higher priorities completed,
this will be left for later. The things now relatively certain (barring
acts of God etc) are: fsck, mkfs, badblocks, fdisk, non-VGA video and
finally the correction to the serial drivers to change speed by the
ioctl call. I'll look into extended partitions (fdisk will probably
report them), but I doubt they will be accepted by the kernel proper
until later.

Linus

PS. I try to answer all mail as soon as I get it, but I get MUCH mail.
If you think the mailing-list has been active: think again :-). If you
don't hear from me, I've probably forgotten to answer at once, and once
your mail is in my mailbox, it's likely to be lost among the multitude.
Re-mail your question, and make me feel guilty about not replying the
first time: that's the ticket.

Ok, here's a mkfs for those that want to try it out. It works on my
system (limited testing), and hopefully we can get possible bugs ironed
out in time for 0.11 (and currently I'm hoping to release that December
8th or something).

This mkfs has two modes: checking and reckless. On a disk that you know
has no problems, you just write "mkfs /dev/hdx size", and you should
have a new system (DON'T do this on a mounted drive: unlike fsck there
is NO way that will work, and you'll probably mess it up completely.)

On a disk with possible read-errors, use "mkfs -c /dev/hdx size", which
will read all the blocks and mark those unreable into a special file
"/.badblocks". I'm not making any guarantees. This is a fast hack
(mainly yesterday and today), and I have tested only on small
filesystems, faking errors by telling mkfs that the filesystem is bigger
than it actually is. If you think the algorithm for marking bad blocks
is weird: you're right.

Linus

PS. Using -c on a big harddisk or on floppies is slow, even though I try
to speed it up by reading 32kB at a time. Also, the current linux kernel
will print out error messages for all the IO errors - that's normal, and
that's what this mkfs should map out.
---------------- snip snip ----------
/*
* mkfs.c - make a linux (minix) file-system.
*
* (C) 1991 Linus Torvalds. This file may be redistributed as per
* the Linux copyright.
*/

/*
* 24.11.91 - time began. Used the fsck sources to get started.
*
* 25.11.91 - corrected some bugs. Added support for ".badblocks"
* The algorithm for ".badblocks" is a bit weird, but
* it should work. Oh, well.
*
* Usuage: mkfs [-c] device size-in-blocks
*
* -c for readablility checking (SLOW!)
*
* The device may be a block device or a image of one, but this isn't
* enforced (but it's not much fun on a character device :-).
*/

nicholas@cs.uwa.oz.au (Nicholas Yue):
> G'day,
> How do I mount the 2nd hard-disk (automagically ;-). The boot floppy can
> be configured to mount the root file system form /dev/hdX

Minix does this in /etc/rc, but as linux currently ignores that, the
best way is to do it in your .profile (or /etc/.profile). You migh want
to use 'mount /dev/hdX /home &> /dev/null' so that eventual multiple
mounts won't print error messages. Likewise you can unmount in .logout,
but unmounting isn't really necessary (but do remeber to sync).

many:
>
> kermit works, but dies due to ^C. What's wrong? It also complains
> about not being able to lock the line.

This /seems/ to be standard behaviour of unix-kermit, and it is
certainly not of my doing. It's a nuisance. Line-locking is done by
creating a file in the directory /usr/spool/uucp/LCK, and unless that
directory exists, kermit isn't able to lock it.

Then to bug-reports and updates:

hd.c is buggy, and I'm investigating it. When read-errors occur, weird
things can happen, including writing to the disk. This might be the
cause of some peoples problems: there is no problem if you have a
sector-translating controller (eg IDE etc) that never returns errors. I
think I've gotten it working, and hopefully the 0.11 version (due out in
about a week) will be correct.

0.11 will also finally be totally self-sustaining: I have gotten the
source to bruce evans' assembler and linker, and at least I haven't
heard of many problems with mkfs and fsck. I didn't have time to
implement symlinks, so there are no real new features: just bug-fixes
and enhancements. Thanks to everybody who sent diffs etc. You know who
you are, and I've tried to accnowledge everyone in the source. Wolfgang
XXXX, who made the German keyboard patch, please mail me your last name.

Known bugs still unresolved: at least one machine has trouble reading
the floppy, and one 486 seems to have problems with the harddisk even
with my new patches. Another machine seems to get divide by zero
errors, and I have absolutely no idea why this happens. As it looks
now, these won't be corrected in 0.11 unless I can find the reason for
them within the week :-(

Yow,
as the subject says, this is the last call for diffs for the 0.11
kernel. If you have bug-fixes or enhancements, I'll have to get them
before friday (6.12.91) in order for them to find their way into the new
kernel. I'll do the "last rites" for the new kernel during the weekend,
and put it out for ftp after that.

Changes between 0.10 and 0.11:

- fixed bugs in block-device drivers: floppies still have problems when
accessing 2 floppies at the same time, but otherwise everything seems to
work.

- german keyboard (thiel)

- console beeping (jtkohl).

- corrected owner checks, #!-recognition in execve (tytso)

- sticky directories (both me and tytso)

- demand-loading

- page-sharing between all processes.

I doubt demand-loading makes anything any faster, but it made
page-sharing possible, so it was "a good thing". Page sharing means that
when executing a new image, the pages aren't loaded from disk if some
other process has them. Especially on a multi-user setup (when we get
the init/login), this will speed things up and save memory.

I'll also release the bruce evans 86-assembler binaries at about the
same time as 0.11, as well as a new root-disk with the new system
binaries (mkfs, fsck and fdisk). Fdisk doesn't do anything, it just
checks the partition table and prints out the partitions.

The subject says it all: I have uploaded linux version 0.11 to
nic.funet.fi and tupac-amaru. They won't show up for a while on nic,
but are already visible in pub/msdos/replace/incoming at amaru. rtx-11
is so slow to use from here that I didn't upload them there: I guess
they'll show up within a couple of days (tytso?).

This version has a lot of corrections, and is stable at least on my
machine. I /hope/ every known bug is fixed, but no promises (and all
unknown bugs are still there, probably with reinforcements ;-). Those
who like to use caps lock as a ctrl-key, you'll have to re-patch the
kernel. It's not implemented in the standard version.

Linus

PS. I'll be a bit busy with the #"$/% physics-course I'm taking, so I
might not be as active on the net this coming week as I would like to.

PPS. corsini: the problem you have with the recompiled uemacs sounds
like it isn't resetting the ISIG bit in c_lflags when moving to raw
mode. Search for c_lflags in the source: it should effectively be set to
zero (I think) - no signals, no canonical mode etc.

Ho, ho ho, and a happy X-mas/chanukah/whatever to you all. I'm probably
mailing to a lot of non-listening mail-boxes, but who cares.

This is a warning for all you out there making changes to the linux
kernel: if you want your changes to be in 0.12, I want them by early
January (5th-10th ta the latest). As it looks now, 0.12 will be out
about 15th of January, and will contain at least these new things:

I got VM working today (not bad in two days if I may say so :-), but
haven't really tested extensively. I tried some compilations (I remade
uemacs) on a 2M machine (or rather a 8M machine, of which Linux sees
only 2M), and it worked (gcc, make, bash etc in memory ar the same
time), albeit slowly. There are probably still problems, but it seems
VM will definitely be in 0.12.

Note that the earlier I get your fixes, the easier it will be to
implement them all: if I get many fixes 0.12 may be a little late, so
the January 15th date isn't really fixed. Also, after releasing 0.12
I'll probably have to study a bit harder than I did this autumn (which
isn't hard per se :-), which may mean that the new releases won't be
coming once per month or so any more. Hopefully 0.12 will be good
enough to use.

This note is coming to you from the virtual console of Linux.
Yep. I have virtual consoles working under linux.

Although this is based upon Gordon Irlams minix patches, virtually
no code from there was actually used. This is more a product of
minix's message passing kernel being so different from Linux's
unified approach than by design. But I am trying to adapt
as much of his setterm program as possible, so that a user interface
for setting colors and the like is available. To get around the
problem of no init/login I am using the "doshell" program
posted here earlier. Actually, for standalone machines I
think I prefer it over getty/login.

I will post the patches to 0.11 as soon as I have tested a little
more, and had a chance to bundle it up.

I also have done all of the design and coding, but none of the
testing on a select call, adapted from Mathius Lauttiners design.
But as Proven has requested, I will probably wait until after 0.12
is out before going any further with that. Getting a peek at your
VFS patches early, thought might help.

It's funny how things work out. I was working on select, started
eyeing how they might interact with pty's, and realized that
virtual consoles would probably still be desirable after ptys,
as well as being easier to do.

Anyways, have a good christmas all. I am heading to the ski slopes
so I know I'll have fun. Hope you do to.