= Attendees =
* Lars Kurth
* Don Koch
* Ian Jackson
* Paul George
= Agenda =
== Unexpected powerloss event ==
Ian: was asking about unexpected power supply issue yesterday night
Paul: saw a flash inside one of the rimava's after plugging in the serial cables - both Rimava's went down. Pulled the power cord for gateshead by mistake when investigating.
Ian: did you pull the plug for newcastle
Ian: when you power cycled newcastle - did you unplug the cable?
Ian: our theory is that something within one of the rimava servers that caused newcastle's and the other rimava machines to power cycle.
Paul: could have hit a cable by mistake and this may be responsible for newcastle and gateshead going down
Ian: in future please email what has happened, and in what order
Ian: is not going to take any action now - will monitor going forward.
Paul: suggest to create an error log with time-stamp and event description
Ian: agrees
== huxelrebe[01] ==
Don: have not heard back from Lenovo
Paul: is going to follow up with lenovo
Ian: is confused - was assuming that we need to enable serial with crazy runes
Don: tried doing this - however did not get anywhere. Get's "error 0" errors
Ian: May need to do this with the server booted into the BIOS (not when running)
Ian: suggests to give the web UI a separate IP address
Don: says machine has two separate NICs - could use a separate NIC for AMT use
Ian: suggests to split the two ports up
ACTION Don: to put instructions into an email
Don: huxelrebe1 has no AMT access at all - despite being configured in the same way as huxelerebe0
Ian: huxelerebe0 - have not been able to performed remote BIOS setup
Ian: suggests a screen by screen setting comparison, maybe with two monitors attached
Ian: after some discussion it sounds possible that there is a MAC/DHCP address issue?
Don: can look into DHCP logs and verify to see whether the AMT is requesting an IP address
Paul: this machine does have a maintenance port which could be used for AMT
Don: right now it using Eth2 on both machines - MAC addresses 0 and 1 have consecutive MAC addresses, which is odd and maybe indicates that this has come up one a virtual rather than real interface
*Agreement* Once Don resolved, hand over to Ian whose scripts will handle DHCP automatically
== oseleta [01] ==
Paul: flagged the files to download
Paul: Will apply the BIOS update on both machines - then we can do boot stress testing on the bench to see if the issue has gone
Ian: suggests whether the issue can be reproduced on the bench, before updating the BIOS. Could probably do this doing Ctrl+Alt+Delete. OSSTEST waits 4-5 minutes before the test takes the machine
out of the pool, takes it back in and restarts it. Normally boots in <2 minutes.
Ian: suggests that when the issue shows, Paul should check whether it is stuck forever and if not how long it takes
== rimava[01] ==
Paul: has taken Rimava[01] back to the lab to investigate
Paul: tested the machines for a week and put them into the COLO
Paul: put them in yesterday and they failed, after running for several minutes (see above)
ACTION Paul: investigate
== AOB ==
=== Serial VM ===
Don: serial VMs do not automatically come up in some scenarios
Ian: was not aware of that
Don: suspect this may be an issue with serial passthrough - can't find any error messages in any logs. Will add an explicit script after start to see whether this works
Ian: have no production tests running on gateshead - so can use gateshead to test and use serial console from newcastle to see error message
Ian: when this happens - please email us\
=== Comtrol 1===
Paul: Note that all ports in Comtrol 1 panel are used (including Rimava)
Paul: still have plenty of space in the second Comtrol panel
