Re: [9fans] KFS Crash

Re: [9fans] KFS Crash

[Russ Cox]

	1. If rio crashes is there a way to kill
	   rio and get back to the shell?

Not really.

	2. Given that I could, what diagnostics
	   could I run to identify the problem?
	3. Is there a way to repair the disk at this point?

I rarely see kfs get that hosed.  Are you sure
the root is from: got the right file system?

I'd try booting an install floppy and using it
as a rescue disk: ignore the install process,
draw yourself a new window, and try to start kfs
manually:

	disk/kfs -f /dev/sdC0/fs
	mount /srv/kfs /n/kfs

and maybe you'll get a bit farther.

There's almost always a way to repair the disk, depending
on how much energy you're willing to devote to it.
I have a clumsy C program that tries to pull
out textual data from broken kfs file systems
if you need something that wasn't backed up.

	4. Given that you don't have much faith
	   in kfs and some of us are using it
	   exclusively on our standalone terminals,
	   what sort of maintainance, such as
	   disk/kfscmd check, should we be doing?

One method is to set up two file systems and run
check say once a month.  When you start getting
things like bad tags, ream the other file system
and copy your data over; repeat.

For the most part, kfs is stable.  It gets unstable
fairly fast if you frequently don't "disk/kfscmd halt"
before shutting down, or if you crash your kernels a lot
(implies the first, but usually a bigger problem
since you can die during heavy disk i/o).

Nothing's set in stone but I think one hope for the
fabled file server rewrite is to have kfs build
from the same sources, which may at least exercise it
more.

Russ

Re: [9fans] KFS Crash

[Mark C. Otto]

Booting up with the install disk, I was able to get a window under rio.  I could
not start kfs though:

% disk/kfs -f /dev/sdC0/fs
File system main inconsistent
Would you like to ream it (y/n)?  hell no. tag = <badtag>; expected Tdir
kfs init 496: FID1 attach to root

# The root of the problem is at the root.  Russ is right:  at least it asks
before
# wiping out your file system.

mount /srv/kfs /n/kfs
mount: sys: write on closed pop pc=0x00003abe

I can get to the 9fat file system.  I can probably reconstruct most of what I
lost expect for a few mail messages and my plan9 wish list.  I'm sure all the
important things will come back to me. :)

For the autopsy, I have always run disk/kfscmd halt to shut the system down
except for the few times the system locked up.  I have never run disk/kfscmd
check.  I have 500mb disk and had just installed wiki and pq.  (I didn't install
TeX for space reasons.)  That may have nearly filled the disk.  I haven't run
Russ's df in a while, so I won't be able to confirm that.  It did get some 9p
and bad address errors before it locked up.  I should have had a plan before I
rebooted the final time.  Next time I might use Rob's rio crash fall back
procedure.


To debug rio after it's crashed:
1. If you have a shell prompt, hit carriage return until every one gets you a
shell prompt; that means the rio process holding the keyboard open has filled
its
buffer.  Then, although echo will still be off, the shell is all yours.
2. Type
     kill rio|rc
and you'll get echo back and you can restart rio or whatever else
you want to do.

3. After that run the disk diagnostics and rebuild the disk

 disk/kfscmd -r check
 disk/kfscmd -fdtw check  # I'm guessing at the options from kfscmd(8)


Guess this is the kick to usurp another old pc for a cpu/auth server, set up
dhcpd(8), and u9fs on my linux box.  Unfortunately, I have JMK's disliked
Adaptec SCSI controllers (AHA-2940U2/AHA-2940U2W PCI and AIC-7880 PCI), so I
can't set up a real file server yet.

Russ, Rob, and Scott thanks for helping me at least find out what state my
system is in.

Mark

[9fans] Rio on Install but Not on Boot

[Mark C. Otto]

I can not bring up rio when booting from my newly created boot (not install)
floppy:

rio: can't open display:initdisplay: /dev/draw/new: no frame buffer

I know you have seen these problems before.  Unless I missed something, I need
suggestions beyond what are in the install notes.

I installed plan9 on a Micron that I hope will become my cpu/auth server.  I
added a line in vgadb to get my Micron 700FGx 17" monitor (no graphics card) to
work:

        0xC0047="Stealth 3D 2000 Pro Vers. 1.01"

before the version 3.04.  The install went well with the screen at a nice
resolution.  My plan9.ini had the following:

monitor=multisync75
vgasize=1024x768x8

As Russ said face the VGA problems early.

I made a boot floppy and copied over my added vgadb to /lib/vgadb, and I am not
using a special version of aux/vga.  I even did a grep to make sure the new
entry was in /lib/vgadb.  I still get the same error when booting up rio.  Does
anyone have ideas of what else to check.  I can go back to the install and still
get rio.

Mark