[916] in SIPB-AFS-requests
[Mail Delivery Subsystem: Returned mail: User unknown]
daemon@ATHENA.MIT.EDU (Matt Braun)
Sat Jun 5 18:14:36 1993
To: sipb-afsreq@athena.mit.edu
Date: Sat, 05 Jun 93 18:14:22 EDT
From: Matt Braun <mhbraun@athena.mit.edu>
------- Forwarded Message
Received: from ATHENA-AS-WELL.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA14598; Sat, 5 Jun 93 18:11:36 EDT
Received: from BINKLEY.MIT.EDU by Athena.MIT.EDU with SMTP
id AA25321; Sat, 5 Jun 93 18:11:35 EDT
Received: by binkley.MIT.EDU (5.61/4.7) id AA22612; Sat, 5 Jun 93 18:11:30 -0400
Date: Sat, 5 Jun 93 18:11:30 -0400
From: Mail Delivery Subsystem <MAILER-DAEMON@Athena.MIT.EDU>
Subject: Returned mail: User unknown
Message-Id: <9306052211.AA22612@binkley.MIT.EDU>
To: mhbraun@Athena.MIT.EDU
----- Transcript of session follows -----
>>> RCPT To:<sipbafs-req>
<<< 550 <sipbafs-req>... User unknown: No such file or directory
550 sipbafs-req... User unknown
----- Unsent message follows -----
Received: by binkley.MIT.EDU (5.61/4.7) id AA22602; Sat, 5 Jun 93 18:11:30 -0400
Message-Id: <9306052211.AA22602@binkley.MIT.EDU>
To: sipbafs-req
Cc: jweiss, jtkohl, marc, probe
Subject: Opus / Ronald-ann
Date: Sat, 05 Jun 93 18:11:18 EDT
From: Matt Braun <mhbraun>
OK, here is the deal. Last night jweiss & installed opus, our new maxine
server as a sipb cell AFS server. There were several problems . Our
intention was to bring it up as opus as a temp name and then once the volumes
were moved cahnge it to ronald-ann.
1) 1 of the 3 r^2 disks we had does not work. currently the dead drive is not
attached to anything along with the dead terminator that we have.
2) the wrong version of fsck was on the server so the first time that jtkohl
crashed the server we had a lot of difficulty bringing it back up. (we got
over this though with marc's help)
3) We did a backup of ronald-ann before we started. The tape is in the normal
place, we used the next available tape (rann_1)
4) Ronald-ann a and b are on opus a currently c was being moved when the
most recent crash occured
5) The machine is running the 'new' ops kernel in
/mit/opssrc/sys.mips/MIPS/ATHMAX.5000/vmunix with a modification suggested by
jfc which was
"kvar -s bufcache -wl -v 25 /vmunix"
verify with
"kvar -s bufcache -rl /vmunix"
We might want to consider reverting this but I don't understand the
implications enough to do it.
6) jweiss & I have been working on this since ~10 pm last night....we are no
longer in any reasonable shape to deal.
What we were planning on doing was
(Sorry if this doesn't make sense)
vos move stuff to opus
swap machines (names & IP addresses)
bring the RT down (as far as AFS)
(Kill db process on all except rosebud)
set up another machine as an AFS server (vl server only)
(bos server -noauth )
vos syncvldb ronald-anne -no on the new server
" " rosebud " "
shutdown vl server on rosebud
mv rosebude:vldb.DB0 & vldb.DBSYS1 to someplace else
cp the extra servers vldb.DB0 to r-a & rosebud
bos restart vl on r-a & rosebud
The command that John kept typing to crash the maxine was :
% cd /afs/sipb/project/beacon-src
% mkdir pmax_ul4
Touching anything will also cause the same effect.
7) Right now there are several RO volumes still on the old R-A partions a & b.
8) I need to go to sleep
10) the scsi terminator on opus is from the mac since the one we got from e40
did not work (we will replace this )
If you have questions, marc probably has the best understanding of what his
going on, and he has been to sleep recently
Sorry if this messes people up,
Matt
PS I strongly considered just restoring from this mornings tape but I don't
know how!
------- End of Forwarded Message
