715605 - (talos-r4-lion-036) talos-r4-lion-036 problem tracking

Status: RESOLVED FIXED

(Infrastructure & Operations Graveyard :: CIDuty, task, P3)

Comment 1

[Jake Watkins [:dividehex]]

This has been re-imaged. Kicking back to releng for post re-image work.

Comment 2

[Aki Sasaki (not active)]

[14:34]	<philor>	looks like talos-r4-lion-036 got resuscitated yesterday, but it isn't actually well
[14:35]	<philor>	hard though it is to tell with lion, since so many suites are permafail, but https://tbpl.mozilla.org/php/getParsedLog.php?id=8646474&tree=Firefox ain't normal

Comment 3

[Phil Ringnalda (:philor)]

If you want to indulge my wild guesses, running a memory checker on it could possibly prove interesting.

Comment 4

[[e-mail] (:bhearsum)]

Since this is part of buildduty and I'm probably not going to be that guy when the dep bug is closed, throwing back.

Comment 5

[Jake Watkins [:dividehex]]

This slave is back from repair and has been re-imaged.

Comment 6

[Armen [:armenzg]]

TODO: setup machine

Comment 7

[[e-mail] (:bhearsum)]

Back in production.

Comment 8

[Phil Ringnalda (:philor)]

Maybe it just doesn't like January: https://tbpl.mozilla.org/php/getParsedLog.php?id=18520642&tree=Mozilla-Inbound is another suspicious crash in the weeds, characteristic of bad RAM.

Comment 9

[Justin Wood (:Callek)]

Awaiting a proper bringup procedure for this slave class

Comment 10

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

Testing with PuppetAgain in bug 891880.

Comment 11

[Phil Ringnalda (:philor)]

fullscreen crash -> hdiutil: attach failed - Device not configured, needs a reboot (and needed to have been closed after the very odd diagnostics, since it was back in production).