Ok, I have uploaded the rest of the linux distribution to nic.funet.fi.
They aren't visible yet, but I guess they'll show up tomorrow or so.

The new files are:

 - fileutil.tar.Z, which contains most of the GNU fileutils. It's not
   the latest release, so if you want that, you'll have to compile it
   for linux.  No source changes, but a lot of -DSTPCPY_MISSING etc in
   the makefiles. 

 - hd.c. I have gotten one problem report already about hd-handling in
   0.12.  This is a correction to kernel/blk_drv/hd.c, and should
   hopefully correct the problem.  There was also a problem with a
   second harddisk not working although the first one did: I think I
   found the problem, and fixed it.  If you cannot get linux operating
   at all (but the bug wasn't that severe, I think), and are thus unable
   to recompile it, mail me. 

 - include.tar.Z. Yes. Yet another include.tar.Z. I don't save old
   versions, so I don't do cdiffs :(.  I still expect patches to be
   cdiffs.  Bastard, ain't I?

 - lib.tar.Z.  The library sources. 

 - libc.a.Z.  Compiled libc.a

 - mkswap.  This should have been on the root-diskette, but was
   forgotten. See description in RELNOTES.

 - system.tar.Z.  The latest sources to the system files: mkswap, mkfs,
   fsck and fdisk.

 - utils.tar.Z.  Contains a new tar (you can use the old one to untar
   this, but this should understand about symbolic links etc), make,
   uemacs and some minor programs (sed and basename I think).

The old utilbin.tar.Z file should be replaced by 'fileutil' and 'utils'. 
The old include.tar.Z, libc.a library.tar.Z should be replaces by their
newer versions. The old uemacs.Z, bash.Z can also be removed from the
archives.

There is some overlapping between these files and the root-diskette (and
older versions of linux).

	And over to other things:

Someone asked on comp.os.minix how to move non-tar files to a linux
partition: the INSTALL-0.11 told about tar-files, but not about things
like libc.a. The easiest answer is to tar the single file into a
tar-file, and then the problem is reduced to something we can handle.

Another possibility is to use the mtools package, but there were so many
questions about it the last time that I'm not even going to mention it
this time around. 

A third possibility is to just write the file to a floppy using
rawrite.exe or NU or something, and then reading the floppy and
truncating at the filelength. This means you have to remember how long
the file was. Truncation can be done by 'dd' or by 'head -c'.

	And one warning...

There are easy ways to make fsck report errors on your harddisk that
were introduced with the demand-loading in 0.11. It's not a bug, but I
thought I'd warn everyone:

While a program is running, it's inode is marked in use.  Thus if you
delete a running command, it seems to be gone, but the file is still
there (standard unix practice).  Sync a thousand times, and the file
will still not be really deleted until the inode no longer is in use:
This may not happen if the file was /bin/update or /bin/sh.

The result is that if you reboot with a deleted file in use, fsck will
wanr about a lot of unused blocks that are marked in use. No problem,
'fsck -a' repairs it, and it /really/ isn't a bug, it's just that we
haven't got something like shutdown yet that sees to these kinds of
problems.

		Linus