644610 - re-image w32-ix-slave34

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P3)

Description

[Dustin J. Mitchell [:dustin] (he/him)]

This system has an old cltbld password, and doesn't get a new one at boot.

Comment 1

[Dustin J. Mitchell [:dustin] (he/him)]

I haven't verified whether this is talking to the right master, has matching keys, etc., yet, so that's the first step.

Comment 2

[Dustin J. Mitchell [:dustin] (he/him)]

Talking to the right master, but not since September 2010.  I removed the client on the master, and rebooted the slave, as directed in https://wiki.mozilla.org/ReleaseEngineering/How_To/Set_Up_a_Freshly_Imaged_Slave#Windows_.28OPSI.29

Comment 3

[Dustin J. Mitchell [:dustin] (he/him)]

That didn't change anything.  Also, I misread the date and it's February 9, 2011.  How can I check that the client is contacting the OPSI server?  I don't see anything interesting in the opsi event log.

Comment 4

[Dustin J. Mitchell [:dustin] (he/him)]

Given that I can't get any help with OPSI for this machine, let's try a re-image.

Comment 5

[Amy Rich [:arr] [:arich]]

Server has been reimaged, passing back to release for additional configuration if required.

Comment 6

[Dustin J. Mitchell [:dustin] (he/him)]

Well, this just failed a preprod build with

e:\builds\moz2_slave\plc-w32\build\gfx\angle\src\libGLESv2/Program.h(13) : fatal error C1083: Cannot open include file: 'd3dx9.h': No such file or directory

which suggests it's still not healthy.  The dx10sdk OPSI package was listed as "installed", but I set it to "setup" and rebooted, so let's see if that helps.

Comment 7

[Chris AtLee [:catlee]]

(In reply to comment #6)
> Well, this just failed a preprod build with
> 
> e:\builds\moz2_slave\plc-w32\build\gfx\angle\src\libGLESv2/Program.h(13) :
> fatal error C1083: Cannot open include file: 'd3dx9.h': No such file or
> directory
> 
> which suggests it's still not healthy.  The dx10sdk OPSI package was listed
> as "installed", but I set it to "setup" and rebooted, so let's see if that
> helps.

The fix for this is to re-install the buildbot-startup package, which installs a new start-buildbot.bat that sets some environment variables necessary to pick up the SDK headers.  I've set this package for re-install on OPSI. Just needs a reboot to pick it up.

Comment 8

[Dustin J. Mitchell [:dustin] (he/him)]

I'll keep an eye on it.

Comment 9

[Dustin J. Mitchell [:dustin] (he/him)]

Seems fine.  I'll point it into production with slavealloc when that's working (bug 616351).

Comment 10

[Aki Sasaki (not active)]

Hm, I grabbed this slave in slavealloc for testing, and found that it had production keys on it.

Should we mark slaves that aren't good for testing as such in slavealloc?

Comment 11

[Aki Sasaki (not active)]

I've placed staging keys on w32-ix-slave34. Not sure if those will stick or be overwritten.

Comment 12

[Dustin J. Mitchell [:dustin] (he/him)]

Huh, this bug should have been closed a while ago.  I reimaged it yesterday, but didn't realize it was a dev/pp slave.  Thanks for fixing that up.