Closed Bug 1200250 Opened 10 years ago Closed 9 years ago

t-w864-ix-024 is unreachable

Categories

(Infrastructure & Operations :: DCOps, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: slaveapi, Assigned: van)

References

Details

(Whiteboard: #FGK-444-18369)

No description provided.
bad drive, opened up #FGK-444-18369 for RMA
Assignee: server-ops-dcops → vle
QA Contact: jbarnell
Whiteboard: #FGK-444-18369
drive i picked up was DOA. will need to grab another one from iX.
colo-trip: --- → scl3
i haven't been able to swing by iX the last 2 weeks. ive asked them go to ahead and ship the bad drive to scl3.
i have reimaged this host twice and it boots up to o/s but not reachable. any ideas? are we still having imaging issues?
Flags: needinfo?(arich)
There shouldn't be issues with imaging, especially wrt to it being pingble. Can you ping OUT of the machine? Are you sure it reimaged at all (maybe the ethernet interface is broken)?
Flags: needinfo?(arich)
I noticed that all of the w8 machines I reimaged earlier this week were not pingable but had the screensaver running. I'm trying to reimage them now to see if Q's modifications to MDT and GPO in the past few days have changed things. If not, though, looks like w8 is broken. Q: I'm doing 181 - 194 now.
Flags: needinfo?(q)
Depends on: 1200180
hmm looks like q fixed the imaging issue or it just took a while for it to finish installing all the drivers. let me know if it still needs to be reimaged again if there was a fix of any sort but the host is back online. vans-MacBook-Pro:~ vle$ fping !$ fping t-w864-ix-024.wintest.releng.scl3.mozilla.com t-w864-ix-024.wintest.releng.scl3.mozilla.com is alive vans-MacBook-Pro:~ vle$ ssh !$ ssh t-w864-ix-024.wintest.releng.scl3.mozilla.com The authenticity of host 't-w864-ix-024.wintest.releng.scl3.mozilla.com (10.26.40.54)' can't be established. RSA key fingerprint is 86:8a:e9:78:35:49:79:7a:d6:3e:aa:86:e8:9e:b8:0c. Are you sure you want to continue connecting (yes/no)?
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Reenabled, ran a job at 1024x768 and failed tests as a result, redisabled.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
A second reboot of the machine fixed the resolution
Flags: needinfo?(q)
A good point of note if a machine is rebooted with a monitor attached or if fakemon interrupted the resolution will be incorrect. This can be cleared manually or the machine can be rebooted.
I did verify that after fakemon runs correctly once the resolution sticks for subsequent reboots
So, should I wait 8 hours after an unreachable is closed as reimaged, then reboot twice while the slave is disabled, then enable it? Not sure what else I can do to avoid this situation.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.