Closed Bug 778900 (tegra-088) Opened 12 years ago Closed 10 years ago

tegra-088 problem tracking

Categories

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

ARM
Android

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: coop, Unassigned)

References

()

Details

(Whiteboard: [buildduty][buildslaves][capacity])

      No description provided.
Depends on: 778812
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Needs recovery.
Status: RESOLVED → REOPENED
Depends on: 786315
Resolution: FIXED → ---
Didn't get fixed after recovery. What's the next step here Callek?
Assignee: nobody → bugspam.Callek
Dear DCOps, never came up after last recovery. Can you please verify that its NIC is not dead, and give it a fresh reimage if its ok.
Assignee: bugspam.Callek → nobody
Depends on: 787407
Up and running.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
No jobs taken on this device for > 3 week (< 6 weeks)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(mass change: filter on tegraCallek02reboot2013)

I just rebooted this device, hoping that many of the ones I'm doing tonight come back automatically. I'll check back in tomorrow to see if it did, if it does not I'll triage next step manually on a per-device basis.

---
Command I used (with a manual patch to the fabric script to allow this command)

(fabric)[jwood@dev-master01 fabric]$  python manage_foopies.py -j15 -f devices.json `for i in 021 032 036 039 046  048 061 064 066 067 071 074 079 081 082 083 084 088 093 104 106 108 115 116 118 129 152 154 164 168 169 174 179 182 184 187 189 200 207 217 223 228 234 248 255 264 270 277 285 290 294 295 297 298 300 302 304 305 306 307 308 309 310 311 312 314 315 316 319 320 321 322 323 324 325 326 328 329 330 331 332 333 335 336 337 338 339 340 341 342 343 345 346 347 348 349 350 354 355 356 358 359 360 361 362 363 364 365 367 368 369; do echo '-D' tegra-$i; done` reboot_tegra

The command does the reboot, one-at-a-time from the foopy the device is connected from. with one ssh connection per foopy
Depends on: 838687
Status: REOPENED → RESOLVED
Closed: 12 years ago11 years ago
Resolution: --- → FIXED
[foopy115.build.mozilla.org] run: echo "disable please" > ./disabled.flg
[OK]   Stopped tegra-088
Sending this slave to recovery
-->Automated message.
Depends on: 889567
Successfully recovered.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
Thursday, September 19, 2013 8:53:13 PM
Status: RESOLVED → REOPENED
Depends on: 944498
Resolution: FIXED → ---
SD card has been replaced and reimaged/flashed.
Needs recovery again
Depends on: 949447
sdcard replaced and reimaged/flashed.
handled in last recovery on Dec 16.
Status: REOPENED → RESOLVED
Closed: 11 years ago10 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Depends on: 959689
No longer depends on: 949447
Resolution: FIXED → ---
SD card flashed/reimaged.
Took one job, died again. Callek, what do we do with these?
Flags: needinfo?(bugspam.Callek)
According to escalation here: https://wiki.mozilla.org/ReleaseEngineering/How_To/Android_Tegras#Tegra_Problem_Tracking

We should be going from 'reimage/flash' -> 'new sdcard' -> 'possible decommision'

Staying in line with that, I'm opening up the latest tegra recovery bug I can find to request new sdcard.
Depends on: 968568
I actually filed a new dep bug to minimize confusion since 'tegra recovery' bugs seem to be about batch flash/re-imaging and not about sdcard replacement
sd card replaced, tegra flashed and reimaged.

fping tegra-088.tegra.releng.scl3.mozilla.com
tegra-088.tegra.releng.scl3.mozilla.com is alive
Back in production.
Flags: needinfo?(bugspam.Callek)
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Product: Release Engineering → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.