Patrick L. McGillan writes:
quoted text
> Hi all,
>   Well, I was able to run make and build a new boot Image file. Unfortunately
>   I am unable to copy it to a disk. Tried cp, dd and cat. The error message
>   from cat looks like this.
>   --error on--
>   bash# cat Image > /dev/at0
>   floppy I/O error
>   dev 0208, block 0
>   cat: write error: EIO
>   bash#
>   --error off--
>   Any thoughts anyone? Incidentally, I have a 1.2 meg as drive A: and a 
>   1.44 meg as drive B:. Even tried writing to drive b with the same apprx.
>   error.

Urgh.  This is definitely the kind of error I wanted least to show up. 
The floppy driver is the least mature part of the system, and any errors
are likely to show up there.  I'm unable to reproduce this error: the
only way this kind of write error could occur is if the floppy driver is
totally unable to read the first block.  Normally write errors won't be
noticed by the writing process: it just writes to the cache. 

This definitely looks like a driver bug: UNLESS you are using floppies
that aren't formatted? You have to format the floppies (currently
possible only under DOS) before trying to write to them.  Please, please
tell me that was the reason :-)

Is somebody else getting this same kind of error? Could you please
report the hardware you are getting it on (5.25"? 3.5"?)? Are you able
to read the disk (as a root-image for example), and does the error
happen all the time?

quoted text
>   I suppose I could be wrong, but it would seem to me that it would be in
>   the best interest of the group if replies were also sent back to the
>   group, instead of to the person with the problem. I.E. Others may have
>   the same question, but are waiting for someone else to ask it.

Yeah, I'm lazy. It's much easier to do a simple "reply", so that the
person with the problem gets it solved, but nobody else. I'll try to
reply to the mailing list in the future (unless it's something very
machine-specific.)

darken.@cs.yale.edu:
quoted text
> 1)  mv doesn't seem to move directories properly.  It looks for
> something called mvdir and dies.  I want to fix this right away,
> so I'm goin to start working on it unless one of you drops me a
> line and explains what stupid thing I've done.

This is a possibly deficiency in the linux kernel.  I don't allow
links/unlinks to directories, as keeping track of the parent is too much
work.  I /think/ it's impossible to allow a hard link to a directory,
but I'm not sure.  Anybody with ideas is free to mail me. 

I think the best solution is to write a "mvdir", which simply copies the
directory and removes the old one. Obviously I haven't done it. (Does
minix allow hard links to directories? How does it handle the '..' file
in such a directory?)

quoted text
> 2)  When recompiling the kernel, the makefile looks for chmem and
> gar.  Since the resulting image seems to work, I suppose these
> things aren't necessary.  But what are they?  I'm curious.

Most programs starting with a "g" are GNU software.  This is also the
case with "gar".  Gar is just a shorthand fro "GNU ar", ie "ar" ie
"/usr/local/lib/gcc-ar".  Likewise "gstrip" is the same as strip, "gas"
is the same as "as" etc. I have most of the gcc binaries linked to three
different names: /usr/local/lib/gcc-xxxx, /usr/local/bin/xxxx and
/usr/local/bin/gxxxx. 

chmem is a Minix brain-damage.  Ignore it.  It isn't needed under linux. 
(it tells the kernel how much memory to allocate to the program, as
minix doesn't allow a process to grow).  Remove the line from the
Makefile if you are running totally under linux (and it's probably not
needed under minix either, if you have the right patches). 

quoted text
> 3)  Lately when I boot linux (with the hard drive as the root
> device) I get the message "child 2 died with code 0000"
> (or something of the sort).  What process was child 2?  Should
> I be worried?  Everything seems to work fine.

Linux has two special processes: The swapper (#0) and init. The swapper
is used as a "null"-process: When no other process wants to run the
swapper just sits and idles. It may not sleep.

Init (#1) is the real father of all processes. It should really do a lot
more than it does currently: execute the /etc/rc file and start logins.
Currently It just starts 2 processes: /bin/update (#2) and /bin/sh (#3).
It then just waits for any of these to exit, and syncs the filesystems
(Normally this happens only when /bin/sh exits, as /bin/update shouldn't
exit for any reason.)

What has probably happened is that you have deleted (or changed)
/bin/update so that it won't work any more (possibly due to a corrupted
filesystem).  It isn't deadly, but it's a bit uncertain: The filesystem
is never synced automatically any more.  Not even a "logout" syncs it,
as init synced it once when /bin/update exited, and thinks that is
enough.  The possibilities for a upset filesystem are much greater... 
Check for file system errors with the newly posted fsck (although you
are still unable to correct anything with it: backup and reinstall.)

		Linus