Andrei Obreja [:aobreja NOT AVAILABLE][:buildduty] Reporter
	Description • 7 years ago

After re-image it seems that the passwords are not changed,tried couple of times today
Please ran diagnostics and re-image after.

	Mark Cornmesser [:markco] OOO 2024/04/15
	Comment 1 • 7 years ago

NI myself as reminder to myself to take a look.

	Van Le [:van]
	Comment 2 • 7 years ago

running diags.

	Van Le [:van]
	Comment 3 • 7 years ago

no issues found during disk diags, running memtest.

	Van Le [:van]
	Comment 4 • 7 years ago

memtest did 3 passes with no issues. i went ahead and reimaged the host again but it's not accepting ssh. is there anything you need to poke or change before i reimage?

	Mark Cornmesser [:markco] OOO 2024/04/15
	Comment 5 • 7 years ago

Something weird happened during the reinstall, and the machine is unable to pick up group policy. I am going to format and reinstall and see what happens.

	Mark Cornmesser [:markco] OOO 2024/04/15
	Comment 6 • 7 years ago

There is an issue in the MDT install.

	Mark Cornmesser [:markco] OOO 2024/04/15
	Comment 7 • 7 years ago

Q: DO you have any idea on why this happening? Could this be related to recent changes to WDS/MDT for Windows 10?

	Q Assignee
	Comment 8 • 7 years ago

!@#@$#@@! Yes this may be that the preinstall has to use SMBv1 which was turned off due to sec policy

	Q Assignee
	Comment 9 • 7 years ago

Verified that the security requirements  in Bug 1370238 require SMBv1 to be turned off. We may be able to force XP sp3 to use SMB v2. For now this is being back burnered per management request.

	Andrei Obreja [:aobreja NOT AVAILABLE][:buildduty] Reporter
	Comment 10 • 7 years ago

Do we have any update here?
If it take to much time debugging we should also consider decomm,anyway we have only 8 machines left in this pool.

	Phil Ringnalda (:philor)
	Comment 11 • 7 years ago

Right, 8 in the pool, one of them has drowned, and we're committed to running WinXP tests until, what, June 2018? Right now, our end-to-end time from push to WinXP tests finished is at best 7-8 hours, so if we paid attention to test results before deciding to ship, we couldn't ship an esr chemspill any faster than that. If we're willing to decomm this one, what's our actual minimum number of machines/maximum end-to-end, where we would say "no, 24/36/48 hours e2e is too much, we need more than 3/2/1 WinXP machines"?

	Kendall Libby [:fubar] (he/him)
	Comment 12 • 7 years ago

Q/Mark, can we get SMBv1 enabled briefly so that we can re-image t-xp32-ix-004 and the 15 machines in bug 1414210? I'm not privy to 1370238, so I'm not sure if we *have* to go to SMBv2 to wrap this up.

	Q Assignee
	Comment 13 • 7 years ago

Enabled smbv1 on both wds1 and the releng dcs and confirmed XP clients can now reach them. There was a small delay here due to firewall changes

	Alin Selagea [:aselagea]
	Comment 14 • 7 years ago

Attempted to re-image this machine again and hit the same error as the one described in the attachment above.
Any ideas?

Note: Windows XP will still be needed as long as esr52 is around, so I think we should find a way to be able to re-image these machines in the mean time.

	Q Assignee
	Comment 15 • 7 years ago

Now that the deploy is talking to the WDS server correctly I see logs. I am looking at the issue now.

	Q Assignee
	Comment 16 • 7 years ago

Rolled back some of the compatibility settings introduced for w732 testing on DELL and HP  hardware with the newer MDT work bench to an older version. This has exposed the version of bdrun in the new MDT workbench no longer supports XP. I am working on a work around now.

	Andrei Obreja [:aobreja NOT AVAILABLE][:buildduty] Reporter
	Comment 17 • 7 years ago

Tried a new re-image for t-xp32-ix-004 but I catched the same issue in xpfail.jpg.
Q do you know when we will have an update here? This bug is pretty old and is blocking us on other important bugs.

	Kendall Libby [:fubar] (he/him)
	Comment 18 • 7 years ago

When [we] decided earlier this year that we would no longer need to deploy new XP clients, we did a series of upgrades to the Windows infrastructure to help support the new moonshots. The downside is that all of that prevents us from deploying XP without recreating the old infrastructure (ie we cannot make the current versions work for XP). 

Given that there's a chance we'll have to support XP for slightly longer than expected (if we move ESR from 59 to 60), and possibly in MDC1, we'll keep looking at this but it's a lower priority than getting stuff migrated to the moonshots.

Is there anything that this is blocking other than moving 15 w8 machines to XP?

	Andrei Obreja [:aobreja NOT AVAILABLE][:buildduty] Reporter
	Comment 19 • 7 years ago

No, this is the only bug that is blocked,only that bug also block Bug 1393774 (which we want to solve it this month), also this cause possible backlog when there are many tests running on this pool(happened few times).
Also by not having the possibility of re-image the machines,other machines can become unreachable like t-xp32-ix-004 and this can become a real issue in the near future.

	Phil Ringnalda (:philor)
	Comment 20 • 7 years ago

Actually there's significant backlog on 100% of the esr52 pushes - e2e time on a push there is 7.5 hours, so in the unlikely event that we actually waited for WinXP tests on a chemspill, this bug would add 5 hours to our turnaround time.

	Q Assignee
	Comment 21 • 7 years ago

After a deep dive some decisions that were made to support windows 10 on the new hardware broke the XP install this originally was not an issue because security changes were blacking XP installs. I have given Fubar a few options to negotiate into the schedule. We can spin out an server to just serve XP installs, We can capture an install and revive XP in AWS ( we would have to stop all talos/GFX and clipboard tests on XP), or we could try to hack an install not using the MDT service 

Q

	Andrei Obreja [:aobreja NOT AVAILABLE][:buildduty] Reporter
	Comment 22 • 7 years ago

The idea of hacking an install by not using MDT service sounds promising,I'll vote for this option as long as the result will consist in having enough machines to run our tests without hit backlog and as long as the result of tests are not affected by these changes.
If I can help with anything please let me know.

	Kendall Libby [:fubar] (he/him)
	Comment 23 • 7 years ago

For the limited amount of machines we're looking at, we'll go with the hack. It's not a higher priority than getting the moonshots into production, but Q will look at getting some of this going.

	Radu Iman[:riman]
	Comment 24 • 6 years ago

On my buildduty shift I came across on this bug. I digged around and I noted that this bug blocks bug 1414210 which in turn blocks bug 1410024 which in turn blocks bugs 1413921, 1413924, 1413915, 1413918 which in turn blocks other four problem tracking bugs. So, if this bug would be fix we can try to resolve bug 1414210 and further. Could you tell me what's the current status of this bug?

	Jordan Lund (:jlund)
	Comment 25 • 6 years ago

I updated the bug dep tree in bug 1410024. In addition to this unblocking existing bugs, we'll want to figure out the status and work involved for xp's sake in general. Thanks for re-raising this Radu!