Subject: time stamp of most recent 60MB systm file - msg#00470

Previous Message by Date: click to view message preview

Re: IDE FS failure

The fs kernel's messages don't always identify the file system in question. As I touch parts of the fs kernel, I've been adding %Zs to the prints. It sounds like the cache of your "main" file system is corrupt. You might try a recover of main's cache: reboot the file server and go into config mode, then type: recover main end This should restore your "main" to the way it was at the last dump (typically 5:00 AM), so you'd lose any changes made since then, but if "main"'s cache is corrupt, you've effectively lost them already.

Next Message by Date: click to view message preview

Re: time stamp of most recent 60MB systm file

> I downloaded a 60MB system file in one ~4hr > session ending at about 0700GMT on 9/22. > Did I get the latest version? The 60MB CD image currently on the web page is from June. (It gets updated much less frequently than the sources file server.) There will be a new version tomorrow or Thursday. Russ

Previous Message by Thread: click to view message preview

fs error msg: didn't like (1460 274) byte message

Just had a problem copying/saving a file from acme at home (over a right now not excitingly fast connection) to the fake worm server at work. When it happened, acme hang (until I fysically disrupted the connection -- could not think of something else) and cp also hang. (after disrupting the connection, acme returned to a usable state, so I could save the file to local disk -- many thanks to the person bringing up this kind of things (hanging fs connection) some days ago!) When it happened, I had a 'C fs' window open, in which appeared: didn't like 1460 byte message didn't like 274 byte message Scenario: working at home on a laptop that has had the 60Mb update; the kernel is a few days older, of september 18. Because I have this funny router at the home end of the cable modem connection, and it does not let il through, I have cpu% cat /rc/bin/service/tcp564 #!/bin/rc exec aux/trampoline il!super!9fs cpu% on the cpu server and run '9fs cpu' to connect to the file server. (the cpu server is diskless and gets root from fs; also its kernel is from september 18, I think). The problem seems reproducible: when saving the remote file from acme failed, I saved it locally and tried then copying it to fs, with the same result. However, doing a 'cat > target' in the cpu window, and pasting the text from the (short) file there, followed by ^D was succesful (remember, cpu server gets root from fs). The fs kernel is a bit old, from May 28. Can that explain this? Is there anything easy I could try to get more insight? I tried 'flag chat' on the fs, but that did not seem to give info on the 'not-liked' packages -- but maybe I overlooked. I'll keep the latop running and connected, in case there are some things I could try. Just tried to open a new window, run 9fs cpu, and tried again to copy the same file from local disk to remote fs. Same result. Axel (concerned, but still hoping for a simple explanation...)

Next Message by Thread: click to view message preview

Re: time stamp of most recent 60MB systm file

> I downloaded a 60MB system file in one ~4hr > session ending at about 0700GMT on 9/22. > Did I get the latest version? The 60MB CD image currently on the web page is from June. (It gets updated much less frequently than the sources file server.) There will be a new version tomorrow or Thursday. Russ