RE: [9fans] boot error walking

RE: [9fans] boot error walking

[Tiit Lankots]

>1. sdC0!9fat!/386/9pcauth

/386 isn't in 9fat, it's in fs (the kfs partition)
so, seems to me you want to say
sdC0!fs!/386/9pcauth

PS pcdisk still makes a kfs kernel, right?

Re: [9fans] boot error walking

[Herbert B. Hancock]

I've solved the problem and now have the machine running an up-to-date 4th edition (replica/pull two days ago) as a auth/cpu server.  Still using kfs though, it works for me.  I had this machine running the 3rd edition for 625 days until an extended power failure forced me to shut it down.  This is day 2 on the way to 626 days.  Thanks to everyone for their help,
Brian

Re: [9fans] boot error walking

[ron minnich]

On Sat, 14 Feb 2004, Christopher Nielsen wrote:

> same here. all of my troubles with fossil have been
> related to a snap -a to venti.

my misconfiguration issue still applies, and was caused by lack of snap.
Agreed I was dumb to not set the -t snaptime, but leaving a machine in an
unbootable state is just a bad deal.

ron

Re: [9fans] boot error walking

[boyd, rounin]

> same here. all of my troubles with fossil have been
> related to a snap -a to venti.

should be a snap to fix ;)

Re: [9fans] boot error walking

[Christopher Nielsen]

same here. all of my troubles with fossil have been
related to a snap -a to venti.

On Sun, Feb 15, 2004 at 03:18:30AM +1100, Bruce Ellis wrote:
> this is consistent with my experience.  it happened after a
> snap -a both times.
> ----- Original Message -----
> From: "David Presotto" <presotto@closedmind.org>
> To: <9fans@cse.psu.edu>
> Sent: Sunday, February 15, 2004 3:12 AM
> Subject: Re: [9fans] boot error walking
>
>
> > ... I should point out that although turning on snap -a's broke my
> > fossiil, restarting from one of the snaps seemed to fix the problem.
> > Clearly fossil is getting confused about what's still local and
> > what's on venti.
>
>

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] boot error walking

[Bruce Ellis]

this is consistent with my experience.  it happened after a
snap -a both times.
----- Original Message -----
From: "David Presotto" <presotto@closedmind.org>
To: <9fans@cse.psu.edu>
Sent: Sunday, February 15, 2004 3:12 AM
Subject: Re: [9fans] boot error walking


> ... I should point out that although turning on snap -a's broke my
> fossiil, restarting from one of the snaps seemed to fix the problem.
> Clearly fossil is getting confused about what's still local and
> what's on venti.

Re: [9fans] boot error walking

[David Presotto]

... I should point out that although turning on snap -a's broke my
fossiil, restarting from one of the snaps seemed to fix the problem.
Clearly fossil is getting confused about what's still local and
what's on venti.

Re: [9fans] boot error walking

[David Presotto]

I've found fossil very trustworthy till I turn on snaps to venti.  So
far I'm two for two fossil file servers that worked fine for a long time
till I did a snap -a.  I'll see what I can figure it out in my infinite
free time.  I pointed rsc to an instance of such a problem we have here
and hopefully will hear from him when he gets time.

I have no intention of discarding kfs.  It doesn't cost anything to
keep it.  Contrary to popular belief generated by a message recently
on this list, we haven't taken kfs reading support out of 9load
(I didn't even know it was there to tell the truth).  I'll find a
machine at work later today and test it out to make sure 9load hasn't
been accidentally broken.

Re: [9fans] boot error walking

[Charles Forsyth]

>>effects, recovery is comprehensible and complete, and finally improper
>>operation (e.g.  letting the disk fill up) should not result in an
>>unbootable machine.  ... it has a long way to go to equal
>>what I'm used to in the Unix/Linux world.

i must be imagining that my Linux partition is currently unbootable
because it filled up and resulted in an unbootable partition.
oh all right, i can boot it but it can't start up properly.
fortunately, i can still boot the machine with something else.
still, i remember that you were also lucky with IBM's AIX/JFS recovery,
which they appear to have debugged some time after i used it!
i'm generally fairly lucky myself, but not those times.

>>I keep wondering if the kinds of
>>guarantees on I/O ordering that a file system needs for its activities can
>>be met outside a kernel? ..

i'm not sure i see why not.
for instance it could write "keep off" into a ctl file to stop
re-ordering (not that i think the kernel does),
or to get the sd*.c to signal the drive to stop re-ordering.
fossil itself was supposed to fuss quite a bit in the soft update
style to get the resulting order right (if the drive doesn't muck it up).

i'm currently a bit less worried about crash on power failure/off than
i am about software bugs, and i had the impression we had some of
the latter in at least one of fossil or venti.
(i'd prefer it to be venti because it's logically simpler, but i did find
and fix something in fossil before.  admittedly it was along the lines
of a statement that could have had a comment ``yes, the bug is here''
because it stood out so much, so that was easy.)

Re: [9fans] boot error walking

[ron minnich]

On Sat, 14 Feb 2004, Bruce Ellis wrote:

> often kfs is enough.  and it co-exists with fossil/venti.  venti
> fkd over a few of my files last week.  some scrambled
> message about a mismatch obscured by other windows
> being updated.  fortunately i could recreate both of them
> easy.  a pity if had been /bin/rc.
>
> i think there are some concurrency issues (in f/v).

Was it venti that really did that? Or was it some f/v miscommunication?

I no longer trust fossil after my last experience, but I do trust venti.
Venti saved my neck. It seems from what I read here and have experienced
that venti is rock solid, fossil less so. If you're telling me venti is
also less solid, then I'm worried. Maybe it's time to just revive kfs with
long file names.

For me anyway, a file system is not a real file system until (at least)
you can cycle power in the middle of each and every operation without ill
effects, recovery is comprehensible and complete, and finally improper
operation (e.g.  letting the disk fill up) should not result in an
unbootable machine. By these standards fossil is a very interesting
experiment but not exactly a file system; it has a long way to go to equal
what I'm used to in the Unix/Linux world. It's quite nice, with the
snapshots etc., but not to be trusted. People tell me fossil is ok if you
treat it nice, but in the real world I want to be able to be mean to the
file system and have it survive anyway.

Venti on the other hand, based on everything I've seen, is to be trusted.
I hope that is true.

The concurrency point is interesting. Another thing I wonder about is
order of operations. Fossil is a set of processes. Most file systems I've
worked with depend on controlling the ordering of disk writes for data vs.
metadata I/O. "Smart" disk drives that reorder disk writes have been known
to play havoc with file systems. I keep wondering if the kinds of
guarantees on I/O ordering that a file system needs for its activities can
be met outside a kernel? It just seems easy for fossil to get confused
about what is where and when, and then all is lost. Just wondering.

ron

Re: [9fans] boot error walking

[andrey mirtchovski]

> Contrary to popular belief generated by a message recently
> on this list, we haven't taken kfs reading support out of 9load

9fans → it's our nature to speculate :)

Re: [9fans] boot error walking

[Bruce Ellis]

often kfs is enough.  and it co-exists with fossil/venti.  venti
fkd over a few of my files last week.  some scrambled
message about a mismatch obscured by other windows
being updated.  fortunately i could recreate both of them
easy.  a pity if had been /bin/rc.

i think there are some concurrency issues (in f/v).

brucee
----- Original Message -----
From: "boyd, rounin" <boyd@insultant.net>
To: <9fans@cse.psu.edu>
Sent: Saturday, February 14, 2004 2:32 PM
Subject: Re: [9fans] boot error walking


> > is there a point in fixing it? after all, kfs IS dead
>
> no, kfs has been seriously tested; it may not be perfect, but it does work.

Re: [9fans] boot error walking

[boyd, rounin]

> > is there a point in fixing it? after all, kfs IS dead
"Not only is UNIX dead, but  it's starting to smell really bad"  --  rob

Re: [9fans] boot error walking

[boyd, rounin]

> is there a point in fixing it? after all, kfs IS dead

no, kfs has been seriously tested; it may not be perfect, but it does work.

RE: [9fans] boot error walking

[Tiit Lankots]

> until presotto fixes 9load the following will do:

is there a point in fixing it? after all, kfs IS dead

RE: [9fans] boot error walking

[andrey mirtchovski]

>> until presotto fixes 9load the following will do:
>
> is there a point in fixing it? after all, kfs IS dead

i thought his message indicated that he wants to fix it.  "why?" is a
different matter altogether :) 9fat does work fine for me (but as you
said, there's no /386 there :)

Re: [9fans] boot error walking

[andrey mirtchovski]

until presotto fixes 9load the following will do:

	...<mk 'CONF=9pcauth'>...
	% 9fat:
	% cp 9pcauth /n/9fat
	% unmount /n/9fat

reboot and use sdC0!9fat!9pcauth at the boot prompt


> error walking to /386/9pcauth
> Boot devices: fd0 ether0 sdC0!9fat

[9fans] boot error walking

[Herbert B. Hancock]

I downloaded and installed the Plan 9 iso on Feb 10th compiled the pcauth and added pcdisk to the start up menu just in case.  I noticed mk 'CONF=pcauth' install put 9pcauth in /386.

When I boot:

Plan 9 Startup Menu
1. Plan 9 Fourth Edition
Selection 1

ether#0: elnk3: port 0xD000 irq 11: 000102EB8BE0

1. sdC0!9fat!/386/9pcauth
2. sdC0!9fat!/9pcdisk
3. none of the above

bootfile: 1

error walking to /386/9pcauth
Boot devices: fd0 ether0 sdC0!9fat

boot from: sdC0!9fat!9pcdisk
error walking to 9pcdisk

boot from:

I think there might be something wrong with plan9.ini but can't get it to boot to find out. I also tried booting from a floppy but that failed as well.  Any ideas?

Thanks,
Brian