Closed Bug 637842 Opened 15 years ago Closed 15 years ago

Please poke win64-ix-ref

Categories

(Infrastructure & Operations :: RelOps: General, task)

x86
All
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: armenzg, Assigned: shui)

References

Details

I can't ping it right now. armenzg-laptop $ ping win64-ix-ref.build PING win64-ix-ref.build.mtv1.mozilla.com (10.250.49.173): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 Request timeout for icmp_seq 3
Assignee: nobody → server-ops-releng
Component: Release Engineering → Server Operations: RelEng
QA Contact: release → zandr
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
I want to treat this separately, since it's actually a DHCP conflict. DHCP is fixed, but I probably have to do something aggravating to the box itself to get that back.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I need this to be fixed so I can finish up the work on the win64-ix-ref machine. I added it to the IT priorities page.
Severity: normal → major
per mrz, raising to blocker as this regression blocks armen getting anything done here.
Severity: major → blocker
OS: Mac OS X → All
Assignee: server-ops-releng → jlazaro
Lowering the priority to major since I was able to provide armenzg the current IP that this machine is using: 10.250.49.229 The IPMI address for this is now set to 10.250.51.50 (which was 10.250.49.51 before) but I am still unable to reach the interface. It looks like we'll need to double check the DHCP entry for this ref machine since this is not working: host win64-ix-ref { hardware ethernet 00:30:48:9f:81:c1; fixed-address 10.250.49.173; }
Severity: blocker → major
(In reply to comment #5) > Lowering the priority to major since I was able to provide armenzg the current > IP that this machine is using: 10.250.49.229 Cool, thanks jlazaro. Armen's able to work using the IP address, so thats great help! > The IPMI address for this is now set to 10.250.51.50 (which was 10.250.49.51 > before) but I am still unable to reach the interface. > > It looks like we'll need to double check the DHCP entry for this ref machine > since this is not working: > > host win64-ix-ref { hardware ethernet 00:30:48:9f:81:c1; fixed-address > 10.250.49.173; } In comment#2, looks like zandr had checked DHCP already, so not sure whats going on, but thats something he can investigate when he gets back.
Severity: major → blocker
(In reply to comment #5) > Lowering the priority to major since I was able to provide armenzg the current > IP that this machine is using: 10.250.49.229 > > The IPMI address for this is now set to 10.250.51.50 (which was 10.250.49.51 > before) but I am still unable to reach the interface. 51.50 appears to be some other host, not IPMI. It's answer to vnc, ssh, http & https but not IPMI. Can that host go offline to statically assign it's IPMI interface?
Assignee: jlazaro → shui
(In reply to comment #7) > 51.50 appears to be some other host, not IPMI. It's answer to vnc, ssh, http & > https but not IPMI. Are you basing that on nmap, or actually trying an http connection? Because if you bounce http through mvadm01, you definitely get to a SuperMicro IPMI card. (on the old IP, you got an nginx default page, which lead me to the IP conflict with an n900) *However*, it still shows as having 1.28 firmware, so it likely has trouble talking off-subnet. I'll take care of that now.
Upgraded, but it's still not talking off-network reliably. There may be more to the networking problems with these IPMI cards than is fixed by 2.01.
I tested with nmap, saw more ports open than I thought I should. Couldn't connect to it though (I tried from my desktop at work, tunneled through mvadm01 too).
(In reply to comment #7) > > Can that host go offline to statically assign it's IPMI interface? Yes, just ping me whenever you are about to do it as I am working on it right now.
Please don't statically assign the IPMI interface! Then I have to remember to chase that when the host moves. It's correctly getting an IP. It is NOT correctly communicating off subnet, I doubt static assignment will help that. If you do *test* with a static assignment, please switch back to DHCP when you're done!
(In reply to comment #6) > (In reply to comment #5) > > Lowering the priority to major since I was able to provide armenzg the current > > IP that this machine is using: 10.250.49.229 > > Cool, thanks jlazaro. Armen's able to work using the IP address, so thats great > help! (Aki just pointed out that I accidentally raised this back to blocker when saying thanks to spencer!? Not intentional - saying thank you is important, but not *that* important! I'm blaming cache). As Armen can use IP address, he's unblocked, so this should be back at normal.
Severity: blocker → normal
We are going to re-install the machine on bug 641940. If the issue is still valid after re-installing I will reopen or file a new bug. Thanks bunches!
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
Blocks: 642893
Component: Server Operations: RelEng → RelOps
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.