Working on the same idea that we did for machine moves, we're going to retask the foopies and mobile imaging servers from bug 1056139 by using a google spreadsheet (see the URL field). Please fill in the information for the location and switch ports and I'll work with uberj to get inventory updated. Note that we need to stand up these and the machines coming in from iX so that they're performing tests before the november 9th anniversary date. This means that this is a reasonably high priority (e.g. please do it this by EOB Thursday so we can work on installing these on Friday). I presume that the switches we were waiting on are already in? Please link that bug to this one.

Specifically, the following columns need to be filled out by dcops: switch_ports, system_rack, rack_order, oob_switch_port

:arr, it looks like the missing fields have been filled out by vinh. can you update inventory and we can start kicking your servers.

uberj: I've updated the spreadsheet to reflect the new named per bug 1056139. Can we try modifying inventory today to get these updates in?

I have imported the retask spreadsheet

:arr, the hosts are automatically installing a 64bit version of xp. i dont get the option to choose w8-64. is there a way to manually intervene as the process (https://mana.mozilla.org/wiki/display/DC/How+To+Reimage+Releng+iX+Windows+Machines) appears to have changed. the only x64 options are: MDT Prodcution x64 [EMS Enabled] <-- this is the one i pick MDT Development x64 MDT Provision x64

If the host-names have been corrected in dns and the machines are in the correct vlan it will auto install the proper OS. Do you have an example of a machine that isn't working?

ahh nm i figured out what was wrong. i thought every single one of these hosts are w864 hosts as per title of bug. ill try to reimage these again with the correct architecture.

van: did you get them all to image? Sorry for the confusion, The parent bug has the hostnames in them as well as the spreadsheet, and we just decided to split them out again (not all w8) yesterday.

Q: It looks like, at minimum, the following hosts failed to install the OS. They got part of the way through then errored out: t-w732-ix-156 t-w732-ix-161 Could you do a verification of all the hosts and please investigate those two in particular today?

Taking a look through wds logs nothing seems a miss. I will dive into the hosts themselves today.

Looks like the new machines did not have the sreg dhcp option of filename set to "boot\\x86\\pxeboot.n12". Corrected this in inventory and awaiting propagation.

Not having the option set per comment 11 means that the 32 bit OSs were trying to install in a 64 bit environment due to the fact that the machine processors are detected as 64 bit the install defaults to that. Any 32 bit OS currently needs to have the dhcp filename options set.

My mistake for missing that in the spreadsheet. I've added it to the new hardware tab so that uberj can add them for the new hosts we're getting in.

Things are looking good so far. It is a good thing to note that these re-images can now be triggered on a linux command line from an admin host with the following 2 commands: ipmitool -U <ipmi admin user> -P <ipmi admin password> -H <IPMI DNS or ip address> chassis bootdev pxe ipmitool -U <ipmi admin user> -P <ipmi admin password> -H <IPMI DNS or ip address> chassis power reset Note: win 7 boxes still need bios changes for their video cards to make things work correctly which can be done ONCE remotely via the ipmi KVM interface

we reimaged all these hosts but didn't get a chance to go back and check them to make sure they reimaged successfully. can you let me know if there are any issues with any of them (screen resolution/IPMI/pingable but hung)?

van: did you guys disable the onboard graphics for the w7 machines? q: do we have a way to verify machines, or does it have to be a visual spot check by dcops?

>van: did you guys disable the onboard graphics for the w7 machines? yup, graphics set to "other" for w7 graphics set to "onboard" for all other windows installs

hosts are all online. spot checked w7 hosts, please let me know if there are any issues. t-w864-ix-163.wintest.releng.scl3.mozilla.com is alive t-w864-ix-164.wintest.releng.scl3.mozilla.com is alive t-w864-ix-165.wintest.releng.scl3.mozilla.com is alive t-w864-ix-166.wintest.releng.scl3.mozilla.com is alive t-w864-ix-167.wintest.releng.scl3.mozilla.com is alive t-w864-ix-168.wintest.releng.scl3.mozilla.com is alive t-w864-ix-169.wintest.releng.scl3.mozilla.com is alive t-w864-ix-170.wintest.releng.scl3.mozilla.com is alive t-xp32-ix-155.wintest.releng.scl3.mozilla.com is alive t-xp32-ix-156.wintest.releng.scl3.mozilla.com is alive t-xp32-ix-157.wintest.releng.scl3.mozilla.com is alive t-xp32-ix-158.wintest.releng.scl3.mozilla.com is alive t-xp32-ix-159.wintest.releng.scl3.mozilla.com is alive t-xp32-ix-160.wintest.releng.scl3.mozilla.com is alive t-xp32-ix-161.wintest.releng.scl3.mozilla.com is alive t-xp32-ix-162.wintest.releng.scl3.mozilla.com is alive t-w732-ix-155.wintest.releng.scl3.mozilla.com is alive t-w732-ix-156.wintest.releng.scl3.mozilla.com is alive t-w732-ix-157.wintest.releng.scl3.mozilla.com is alive t-w732-ix-158.wintest.releng.scl3.mozilla.com is alive t-w732-ix-159.wintest.releng.scl3.mozilla.com is alive t-w732-ix-160.wintest.releng.scl3.mozilla.com is alive t-w732-ix-161.wintest.releng.scl3.mozilla.com is alive t-w732-ix-162.wintest.releng.scl3.mozilla.com is alive