[5307] in Release_7.7_team
Ultra-5's that didn't take 9.4
daemon@ATHENA.MIT.EDU (Camilla R Fox)
Thu Aug 25 20:17:23 2005
Message-Id: <200508260017.j7Q0HCaT005563@myxomycete.mit.edu>
To: release-team@MIT.EDU
Date: Thu, 25 Aug 2005 20:17:12 -0400
From: Camilla R Fox <cfox@MIT.EDU>
X-Spam-Score: 1.054
X-Spam-Level: * (1.054)
X-Spam-Flag: NO
33 ultra-5/ultra-10 hosts took the update successfully (athinfo scanning
confirms that all of these have >128M of memory). 46 ultras are at 9.2
or earlier, and three are in random stuck states unrelated to 9.4.
Of the remaining 52, 8 are off the network; it's a good guess that they
lost to the update:
AENEID.MIT.EDU
BANNING.MIT.EDU
CAES-SUN-6.MIT.EDU
CAES-SUN-7.MIT.EDU
DEMOCRATIC.MIT.EDU
QS-CHULOUNGE.MIT.EDU
RUTH.MIT.EDU
SYOU.MIT.EDU
A further 14 refuse athinfo connections, and probably failed the update,
also:
BELAVIVA.MIT.EDU
GOLD.MIT.EDU
HODGE-PODGE.MIT.EDU
JUPITER.MIT.EDU
KIERKEGAARD.MIT.EDU
KUMALA.MIT.EDU
M1-150-1.MIT.EDU
MALLARD.MIT.EDU
NW12-326-SUN1.MIT.EDU
NW12-326-SUN2.MIT.EDU
ROCINANTE.MIT.EDU
ROYLANCE.MIT.EDU
SATURN.MIT.EDU
SPUR.MIT.EDU
NEPTUNE.MIT.EDU is special in being up version "update" after failing to
take 9.4.
I have put all of these 23 "presumed failed update" machines in the
noupdate cluster.
12 of the remaining 9.3 machines claim to have AUTOUPDATE=false, so
no mystery why they didn't update; another seven are in the noupdate
cluster that Garry set up recently, and eight have plenty of memory and
should update fine when they get around to it.
Which leaves:
CAT2.MIT.EDU
MOHR-SUN.MIT.EDU
SCHOONER.MIT.EDU
VICE-GRIPS.MIT.EDU
Which I put in the noupdate cluster. I would guess that they didn't try
an update because people have been logged in, etc.
-Camilla
