Closed Bug 808468 Opened 12 years ago Closed 12 years ago

tegra recovery

Categories

(Infrastructure & Operations :: DCOps, task)

x86_64
Linux
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Callek, Unassigned)

References

Details

+++ This bug was initially created as a clone of Bug #807965 +++ We have another batch of tegras to recover. Unfortunately we should figure out a theory/solution to Bug 808437 before we do this again though.
Alias: tegra-recovery
Depends on: tegra-194
Depends on: tegra-247
Depends on: tegra-174
Depends on: tegra-182
Depends on: tegra-083
Depends on: tegra-187
Depends on: tegra-252
Depends on: tegra-273
Depends on: tegra-104
Depends on: tegra-113
Depends on: tegra-133
Depends on: tegra-179
Depends on: tegra-216
Depends on: tegra-349
Depends on: tegra-093
Depends on: tegra-218
Depends on: tegra-084
Depends on: tegra-064
Depends on: tegra-234
Depends on: tegra-100
Depends on: tegra-159
Depends on: tegra-118
Depends on: tegra-048
Depends on: tegra-046
colo-trip: --- → mtv1
:Callek, do you think we should move on with reimaging/recovering these tegras? Were you able to check the image?
(In reply to Van Le [:van] from comment #1) > :Callek, do you think we should move on with reimaging/recovering these > tegras? Were you able to check the image? Ok, from my understanding the image is fine. I would for this batch request we do a 1-pass "full" sdcard check for bad sectors. (I am told this is doable, just time consuming) The check should be done on (a) a full batch of sdcards to swap, for each tegra here [all get a new card] (b) all sdcards we remove from these tegras [so we can try and identify if there was an sdcard issue] if possible, but not a hard req, I would love a "this sdcard was bad" mapping to what tegra it was in, after the fact. We won't immediately bring up all these devices into production, but aprox 1/3'rd to try and see if they come back fine. And in the near-future I may have a new image/script for you guys to use, which updates apk's we install as well as [slightly] the method we use to install them. It won't however update the base image.
callek: so this would take a dedicated day of one of the dcops folks time, and they doesn't have the man power for this right now because they are split between locations. Is there a step that can be cut out, or would you like us to defer getting all of these done until more people are around?
We tested and confirmed the media of the brand new SD cards with "THE DUPLICATOR!!!" before we began the flash/reimage process for the tegras in this bug. The tegras should all be online now after a new SD card swap, flash, and reimage. Prior to removing the SD card from the tegra, we wrote down the name of it in permanent marker so we can test it as requested. 2 of the tegras came back with bad media when we tested their original cards: tegra[194, 218].
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Blocks: 813012
I'll note that none of these turned back on are succeeding to take jobs at the moment. We are failing to update the watcher.ini, with an issue that is fixed in current (non-deployed) code, I'm going to get a bug on file to track enabling/verifying these before we put new ones through the DC Reimage process.
Alias: tegra-recovery
Blocks: 813015
No longer blocks: 813012
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.