Test-Kitchen MD5 checksum failures during chef client install on Windows


Some users have been reporting issues similar to this when they use Test-Kitchen on Windows. It is failing to locate the MD5 checksum from the Omnitruck metadata and thus failing to install the chef client and bombing the kitchen run. We have identified that this is a problem only on Test-Kitchen version 1.4.2 and earlier.

We have made some recent changes to where and how we host the chef client packages and we now use SHA1 and SHA256 checksums only. We no longer provide MD5 checksums in the metadata for chef client downloads.

If you find yourself receiving errors such as:

$$$$$$ MD5 for C:\Users\vagrant\AppData\Local\Temp\chef-true.msi
$$$$$$ 458177d3b21888c17fd79660781d06eb does not match
$$$$$$ At line:46 char:10
$$$$$$ +   else { throw "MD5 for $dst $dmd5 does not match $md5" }
$$$$$$ +          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$$$$$$     + CategoryInfo          : OperationStopped: (MD5 for C:\User...does not ma
$$$$$$    tch :String) [], RuntimeException
$$$$$$     + FullyQualifiedErrorId : MD5 for C:\Users\vagrant\AppData\Local\Temp\chef
$$$$$$    -true.msi 458177d3b21888c17fd79660781d06eb does not match

Your best route for a fix is to update your Test-Kitchen install to 1.6. The most straightforward path to do that is to update to the newest ChefDk version 0.12.0. However, if you JUST want to update Test-Kitchen inside of an older chef-dk, you can use appbundle-updater to do that. Please reference this previous discource for instructions on how to update Test-Kitchen using appbundler-updater.



Is there a setting I can use in my kitchen.yml to turn off validating the checksum until I can update my ChefDK? I have broken build environments upon which my ability to make changes depends, and updating my test kitchen and ChefDK was not work I had planned for.


This is causing us some pain as well. The latest versions of things seems to not work for us anymore on windows (https://github.com/WinRb/winrm-fs/issues/41), and we can no longer get builds to pass on 1.4.2 either. Sort of between a rock and hard place on our Windows testing now.

I’d also be interested in there is a setting or knob I can turn to get back into a working state.


I’m very sorry for the inconvenience you are experiencing. I am anticipating a winrm-fs release today to fix the issue that you referenced above. This bug affects all test-kitchen runs on Windows 2008R2 due to a regression in winrm-fs 0.4.0 that clashes with the fact that Windows 2008R2 injects line feeds into stdout every 80 characters.

In the meantime, You may find that Test-Kitchen 1.6.0 shipped with ChefDK 0.12.0 to be a more stable experience. Just make sure to remove winrm-fs 0.4.0 and use 0.3.2 instead. As long as your cookbooks do not test encrypted data bags, you should be fine.

There is no “knob” to make 1.4.2 work with the existing chef packaging channels because the chef provisioners shipped in that version of Test-Kitchen used a different install API that required MD5 checksums which are no longer available via bintray.

It may be possible to use 1.4.2 as long as you specify your own custom install script. I’ll be experimenting with that later before posting details.


I had mentioned previously that 0.3.2 threw a different error, which I know probably wasn’t helpful so I re-ran the test with 0.3.2 to capture the actual error:

>>>>>> Message: Failed to complete #converge action: [[WinRM::FS::Core::FileTransporter] Upload failed (exitcode: 1)
Set-Content : Access to the path 'C:\Users\User\AppData\Local\Temp\kitche
n' is denied.
At line:2 char:68
+ function Decode-Base64File($src, $dst) {folder (split-path $dst);sc <<<<  -fo
rce -Encoding Byte -Path $dst -Value ([Convert]::FromBase64String([IO.File]::Re
    + CategoryInfo          : NotSpecified: (:) [Set-Content], UnauthorizedAcc 
    + FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.Pow 

So in my specific case, I’m unable to get it working with winrm-fs.

I’ll try exploring the custom install script route in the meantime.


The above error is likely the encrypted databag copy bug. I just released a winrm-fs 0.4.1 and also a mixlib-install 1.0.4 which you will want to cure another Windows 2008 R2 bug. After installing both of those gems tk 1.7.1 should work on Windows 2008 R2 test instances. If it gives you any more problems please file an issue against Test-Kitchen and I’ll jump right on it.

The next chef-dk will have these correct gems prebundled and the next test-kitchen will have constraints requiring those versions.

Again I apologize for the trouble you have had here and please do not hesitate to file an issue if these gem updates do not fix you.


Thanks Matt, I can confirm winrm-fs 0.4.1 is working for me now. We are back on track.
Thanks for getting a fix out so quickly.