> Hi, I'm trying to copy a large directory /sub to a partition mounted > on /local. /sub contains a functioning Hurd filesystem produced > from the initial tarball. I used this command > > # cd /sub > # cp -a * /local/
Use -v to see each action cp is doing. > First, it's very slow, but that's a known problem. After a while it > spurts out these messages and finishes: > > cp: cannot create regular file `/local/servers/exec': Computer bought the farm Try to reproduce this with actions just on this single file. Most likely the filesystem for /local crashed. I'm presuming it's ext2fs, but this is something you should spell out in a problem report (i.e. include "showtrans /local"). The following "Read-only filesystem" errors are probably just what they say: the /local filesystem has been mounted read-only. This is the normal case if the filesystem crashed and then a new one was started (automatically by the passive translator setting on /local) without running fsck in between (which of course you hadn't). There should be some messages sent to the filesystem's stderr about this, or to /dev/console if the filesystem is root and was started without a stderr (the normal case for passive translators). > The strange thing happens when this is done, if I look in my > / I have a ton of pty* and tty* device files created there, even though > I copied no files to or from /. This I cannot explain. I tend to be a little skeptical that this really happened the way it appeared to you, since it's the only part of the scenario that is not readily explained by known behavior and understandable bugs. Please try to reproduce the failure under controlled conditions. > Why does this happen? Also if I can run a debug version of the ext2fs > server on /local, where should I set a breakpoint to catch this? EIEIO usually indicates that the server crashed. So if you were running it under gdb, you would probably catch the fatal exception without setting any breakpoints. (It never hurts to set a breakpoint on _exit or __task_terminate just in case, so you can always do a backtrace and see what code path led to the process killing itself.)