Upgrade From POSH Version of Chocolatey Fails from Puppet #60
Comments
@trekytech7 I specifically meant can you do a puppet module list and print what version of the chocolatey module you have installed? |
Not necessarily, this appears to be happening with 0.9.8.25. You are not running the latest version until your upgrade is successful. |
|
|
puppet module list --environment "windows" --modulepath "/etc/puppet/environments/windows/modules" As my upgrade was failing I tried the re-install option from cmd or pwrshl with puppet. The intent being to completely re-install (clobber) the previous version. However, this is where I get the error like #18 in puppet reports. Plus the log at "C:\Windows\Temp\chocolatey\chocInstall\tools\chocolateyInstall\chocolateyInstall.log" has the [variableName:'ChocolateyInstall' and variableValue:''] line. This indicates to me that the ChocolateyInstall variable may be null, causing it to fail. However, I'm running into the limits of my knowledge concerning how chocolatey and puppet works. :( I'd be happy with a successful re-install or upgrade at this point. However it has to work from puppet over the previous years deployment. The upgrade option puppet report output looks like this: message: "C:\x5cwindows\x5csystem32>choco update -source 'http://REPO/' "
message: "Updating chocolatey from 0.9.8.25 to 0.9.9.5"
...
message: "Chocolatey is unpacking required files for use. Overwriting? True"
message: "The pipeline has been stopped."
message: "out-lineoutput : The OS handle's position is not what FileStream expected. Do n"
message: "ot use a handle simultaneously in one FileStream and in Win32 code or another F"
message: "ileStream. This may cause data loss."
message: " + CategoryInfo : NotSpecified: (:) [out-lineoutput], IOException"
message: " + FullyQualifiedErrorId : System.IO.IOException,Microsoft.PowerShell.Comma "
message: " nds.OutLineOutputCommand"
message: "Failed to call refresh: cmd.exe /c C:\x5cAdmin\x5cECEchocoUpgrade.bat returned 1 instead of one of [0]" |
|
The error you are getting is because there is an error in the upgrade. But you have to go to the actual log file to investigate. I'm thinking it's possible you need to not do the upgrade with chocolatey. The problems I see now are that you are using your own internal stuff to do the upgrade and it is hard to know what might be wrong based on that. |
message: "C:\x5cwindows\x5csystem32>choco update -source 'http://REPO/' "I agree, the output after executing the command above, causes me to conclude that upgrading will be too troublesome. Instead I will only be pursuing a re-intall method. I think using pwrshl from puppet to do it, makes the most sense. If I really have to, I could do a remote pwrshl, but I've found puppet to be more reliable (sometimes remote pwrshl connections fail, but puppet always runs). Hopefully the 'upgrade' method with the new chocolatey will work well next year.
I've simply pulled 'https://chocolatey.org/install.ps1' and changed line 20 & 47 to use our local/private source (conserves bandwidth). The chocolatey nuget will pull .NET installers locally, but otherwise there's NO change. We deploy Windows with MDT and install .NETv4.5.2 up front, so the .NET sources in the 'Install-DotNet4IfMissing' function, are unlikely to be used anyways. This simply keeps everything in-house and locks our versions for the school term. Here's the puppet manifest exec to install/update chocolatey: exec {'chocoInstall':
subscribe => File['C:/Admin/chocoInstall.ps1'],
refreshonly => true,
path => $::path,
command => 'C:\Admin\chocoInstall.ps1',
# unless => 'if (test for choco version 0.9.9.5) { exit 1}',
provider => powershell,
logoutput => true,
}PS. On a side note: Is there a quick pwrshl one-liner method to check the chocolatey version? ;) Here's the puppet message output after running the script: message: "Downloading http://REPO/Installer/chocolatey.0.9.9.5.nupkg to C:\x5cwindows\x5cTEMP\x5cchocolatey\x5cchocInstall\x5cchocolatey.zip"
message: "Download 7Zip commandline tool"
message: "Downloading http://REPO/Installer/7za.exe to C:\x5cwindows\x5cTEMP\x5cchocolatey\x5cchocInstall\x5c7za.exe"
message: "Extracting C:\x5cwindows\x5cTEMP\x5cchocolatey\x5cchocInstall\x5cchocolatey.zip to C:\x5cwindows\x5cTEMP\x5cchocolatey\x5cchocInstall..."
message: ""
message: "7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18"
message: ""
message: "Processing archive: C:\x5cwindows\x5cTEMP\x5cchocolatey\x5cchocInstall\x5cchocolatey.zip"
message: ""
message: "Extracting _rels\x5c.rels"
message: "Extracting chocolatey.nuspec"
message: "Extracting tools\x5cchocolateyInstall\x5cchoco.exe"
message: "Extracting tools\x5cchocolateyInstall\x5cchoco.exe.ignore"
message: "Extracting Readme.txt"
message: "Extracting tools\x5cchocolateyInstall.ps1"
message: "Extracting tools\x5cchocolateysetup.psm1"
message: "Extracting tools\x5cinit.ps1"
message: "Extracting package\x5cservices\x5cmetadata\x5ccore-properties\x5cf14020bf99604cd9adc4e9f3ed31a355.psmdcp"
message: "Extracting [Content_Types].xml"
message: ""
message: "Everything is Ok"
message: ""
message: "Files: 10"
message: "Size: 3722464"
message: "Compressed: 1255790"
message: "Write-Host : The OS handle's position is not what FileStream expected. Do not u"
message: "se a handle simultaneously in one FileStream and in Win32 code or another FileS"
message: "tream. This may cause data loss."
message: "At C:\x5cAdmin\x5cchocoInstall.ps1:76 char:11"
message: "+ Write-Host <<<< \x22Installing chocolatey on this machine\x22"
message: " + CategoryInfo : NotSpecified: (:) [Write-Host], IOException"
message: " + FullyQualifiedErrorId : System.IO.IOException,Microsoft.PowerShell.Comma "
message: " nds.WriteHostCommand"
message: " "
message: "Chocolatey v0.9.9.5"
message: "Chocolatey is unpacking required files for use. Overwriting? True"
message: "The OS handle's position is not what FileStream expected. Do not use a handle simultaneously in one FileStream and in Win32 code or another FileStream. This may cause data loss."
message: "C:\x5cAdmin\x5cchocoInstall.ps1 returned 1 instead of one of [0]"
message: "change from notrun to 0 failed: C:\x5cAdmin\x5cchocoInstall.ps1 returned 1 instead of one of [0]"
message: "Dependency Exec[ECEchocoUpgrade] has failures: true"And a couple logs: 2015-05-12 10:26:42,420 [INFO ] - ============================================================
2015-05-12 10:26:42,467 [INFO ] - Chocolatey v0.9.9.5
2015-05-12 10:26:42,560 [INFO ] - Chocolatey is unpacking required files for use. Overwriting? TrueC:\Windows\Temp\chocolatey\chocInstall\tools\chocolateyInstall\chocolateyInstall.log does not exist. C:\ProgramData\chocolatey\chocolateyinstall\chocolateyInstall.log 20150512-10:26:36 [DEBUG] Running 'Append-InstallLog' with chocoInstallLog:''
20150512-10:26:36 [CHOCO] ################################################################################
20150512-10:26:36 [CHOCO] # Going Chocolatey on 2015-05-12 10:26:36Z #
20150512-10:26:36 [CHOCO] ################################################################################
20150512-10:26:36 [DEBUG] Arguments: $command = ''|$packageNames=''|$source=''|$version=''|$allVersions=False|$InstallArguments=''|$overrideArguments=False|$force=False|$prerelease=False|$localonly=False|$verbosity=True|$debug=False|$quiet=False|$name=''|$ignoreDependencies=False|$forceX86=False|$packageParameters=''|PowerShellVersion=2.0
20150512-10:26:36 [CHOCO] Please run chocolatey /? or chocolatey help - chocolatey v0.9.8.25
20150512-10:26:37 [DEBUG] Running 'Append-InstallLog' with chocoInstallLog:''
20150512-10:26:37 [CHOCO] ################################################################################
20150512-10:26:37 [CHOCO] # Going Chocolatey on 2015-05-12 10:26:37Z #
20150512-10:26:37 [CHOCO] ################################################################################
20150512-10:26:37 [DEBUG] Arguments: $command = 'list'|$packageNames=''|$source=''|$version=''|$allVersions=False|$InstallArguments=''|$overrideArguments=False|$force=False|$prerelease=False|$localonly=True|$verbosity=False|$debug=False|$quiet=False|$name=''|$ignoreDependencies=False|$forceX86=False|$packageParameters=''|PowerShellVersion=2.0
20150512-10:26:37 [DEBUG] Running 'Chocolatey-List' with selector: '', source:''
20150512-10:26:37 [DEBUG] Showing prerelease versions of packages
20150512-10:26:37 [DEBUG] Executing command ["C:\ProgramData\chocolatey\chocolateyinstall\nuget.exe" list -Prerelease -NonInteractive -Source "C:\ProgramData\chocolatey\lib"]
20150512-10:26:38 [DEBUG] Command ["C:\ProgramData\chocolatey\chocolateyinstall\nuget.exe" list -Prerelease -NonInteractive -Source "C:\ProgramData\chocolatey\lib"] exited with '0'.Now running the script directly as admin with powershell (it works as expected): PS C:\Admin> .\ECEchocoUpgrade.ps1
Downloading http://REPO/Installer/chocolatey.0.9.9.5.nupkg to C:\Users\admin\AppData\Local\Temp\choc
olatey\chocInstall\chocolatey.zip
Download 7Zip commandline tool
Downloading http://REPO/Installer/7za.exe to C:\Users\admin\AppData\Local\Temp\chocolatey\chocInstal
l\7za.exe
Extracting C:\Users\admin\AppData\Local\Temp\chocolatey\chocInstall\chocolatey.zip to C:\Users\admin\AppData\Local
\Temp\chocolatey\chocInstall...
7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
Processing archive: C:\Users\admin\AppData\Local\Temp\chocolatey\chocInstall\chocolatey.zip
Extracting _rels\.rels
Extracting chocolatey.nuspec
Extracting tools\chocolateyInstall\choco.exe
Extracting tools\chocolateyInstall\choco.exe.ignore
Extracting Readme.txt
Extracting tools\chocolateyInstall.ps1
Extracting tools\chocolateysetup.psm1
Extracting tools\init.ps1
Extracting package\services\metadata\core-properties\f14020bf99604cd9adc4e9f3ed31a355.psmdcp
Extracting [Content_Types].xml
Everything is Ok
Files: 10
Size: 3722464
Compressed: 1255790
Installing chocolatey on this machine
Chocolatey v0.9.9.5
Chocolatey is unpacking required files for use. Overwriting? True
Creating ChocolateyInstall as an environment variable (targeting 'Machine')
Setting ChocolateyInstall to 'C:\ProgramData\chocolatey'
WARNING: It's very likely you will need to close and reopen your shell
before you can use choco.
Adding Modify permission for current user to 'C:\ProgramData\chocolatey'
We are setting up the Chocolatey package repository.
The packages themselves go to 'C:\ProgramData\chocolatey\lib'
(i.e. C:\ProgramData\chocolatey\lib\yourPackageName).
A shim file for the command line goes to 'C:\ProgramData\chocolatey\bin'
and points to an executable in 'C:\ProgramData\chocolatey\lib\yourPackageName'.
Creating Chocolatey folders if they do not already exist.
WARNING: You can safely ignore errors related to missing log files when
upgrading from a version of Chocolatey less than 0.9.9.
'Batch file could not be found' is also safe to ignore.
'The system cannot find the file specified' - also safe.
Chocolatey v0.9.9.5
Chocolatey is unpacking required files for use. Overwriting? True
Ensuring 'C:\ProgramData\chocolatey\lib\chocolatey' exists.
Chocolatey (choco.exe) is now ready.
You can call choco from anywhere, command line or powershell by typing choco.
Run choco /? for a list of functions.
You may need to shut down and restart powershell and/or consoles
first prior to using choco.
Ensuring chocolatey commands are on the pathC:\Users\admin\AppData\Local\Temp\chocolatey\chocInstall\tools\chocolateyInstall\chocolateyInstall.log 20150511-10:53:48 [DEBUG] Test-ProcessAdminRights: returning True
20150511-10:53:48 [DEBUG] Administrator installing so using Machine environment variable target instead of User.
20150511-10:53:48 [CHOCO] Creating ChocolateyInstall as an Environment variable (targeting 'Machine') and setting it to 'C:\ProgramData\chocolatey'
20150511-10:53:48 [DEBUG] Running 'Install-ChocolateyEnvironmentVariable' with variableName:'ChocolateyInstall' and variableValue:'C:\ProgramData\chocolatey'
20150511-10:53:48 [DEBUG] Test-ProcessAdminRights: returning True
20150511-10:53:48 [CHOCO] We are setting up the Chocolatey repository for NuGet packages that should be at the machine level. Think executables/application packages, not library packages.
That is what Chocolatey NuGet goodness is for. The repository is set up at 'C:\ProgramData\chocolatey'.
The packages themselves go to 'C:\ProgramData\chocolatey\lib' (i.e. C:\ProgramData\chocolatey\lib\yourPackageName).
A shim file for the command line goes to 'C:\ProgramData\chocolatey\bin' and points to an executable in 'C:\ProgramData\chocolatey\lib\yourPackageName'.
... and so on (standard install log)
Env variable is set globally... I ran "Get-ChildItem Env:ChocolateyInstall" from puppet just to confirm if it is there when running from system user, and it's set correctly to "C:\ProgramData\chocolatey". There is one other difference I see: it looks like chocolatey may be partially installed. Some, but not all, of the folders and so forth are present in the ChocolateyInstall location after Chocolatey Install script has run. |
You may be running into many things when you are attempting an upgrade from the older POSH (powershell) client (anything below 0.9.9) to the new compiled client (0.9.9+), most likely is the move from |
Makes sense. Keeping it all in house that is. |
We do it in the provider - see https://github.com/chocolatey/puppet-chocolatey/blob/master/lib/puppet/provider/package/chocolatey.rb#L43-L45 |
👍 Is it there when it is done? |
Is this when Puppet runs it versus when you run it? I'm guessing so. |
So here's the problem and why you are seeing this message. Puppet redirects stdout / stderr while running processes and because of a bug in PowerShell, you can't write out to anything more than one stream (Write-Host vs Write-Warning vs Write-Error). I would tend to state you should capture the exit code, but send everything as Write-Host instead of Write-Warning / Write-Error. I built a package that tests this brokenness. Take a look at #18 (comment) (linked to comment 35432020). The good news is that choco 0.9.9+ does not suffer from this problem, the bad news is that old choco (anything under 0.9.8.25) and anything PowerShell itself still suffers from this problem.
|
I anticipated this and made sure ChocolateyInstall was set to "C:\ProgramData\chocolatey". As I recall, I tried Boxstarter and had it set in during its install. |
Yes. Puppet runs fail, but manually running chocolatey installation works. |
ugh. rismoney is right that's ugly. Executing this via Puppet powershell succeeds. From tkelman #18 (comment) (iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))) >$null 2>&1OR in my case with a private repo: (iex ((new-object net.webclient).DownloadString('http://REPO/install.ps1'))) >$null 2>&1 |
Good. I don't actually know ruby though. I'm relatively familiar with puppet... more to learn in my copious time. Is there something, like a variable, that puppet agent can check against? What I'm seeing is that "choco_exe?" is true or false, determining if it's C# chocolatey. So that would determine, at least for this year, whether choco has updated on the client. Of course, it shouldn't miss upgrading because puppet subscribes to the pwrshl script, but we know this doesn't always happen in practice. I don't, currently, know how to get this info in the chocolatey puppet manifest (or use it as the case may be). |
|
Basically you need to call What the PowerShell script should look like, I will leave that as an exercise for the reader. ;) |
|
Also, you could look for the existence of a file that would only be in the PowerShell version of chocolatey. Like https://github.com/chocolatey/chocolatey/blob/master/src/chocolatey.ps1, that file no longer exists and would be a big determination. |
I like that: quick and easy one-liner... And the EXEC becomes :) exec {'chocoInstall':
subscribe => File['C:/Admin/chocoInstall.ps1'],
# refreshonly => true,
path => $::path,
command => 'C:\Admin\chocoInstall.ps1',
unless => 'if (Test-Path "C:\ProgramData\chocolatey\chocolateyinstall\chocolatey.ps1") { exit 1}',
provider => powershell,
logoutput => true,
before => {the rest of your packages/modules},
} |
|
If you can make it, I'd go for 0.9.9.6. |
|
@ferventcoder - FWIW, I ran into this issue and, after reading all of this, crafted a fix that you may want to share. This is used to get Chocolatey on my hosts so that this module can then maintain it: # lint:ignore:80chars
exec { 'remove-old-chocolatey':
provider => powershell,
onlyif => 'if (Test-Path -Path "C:/ProgramData/chocolatey/chocolateyinstall/chocolatey.ps1") { exit 0 } else { exit 1 }',
command => 'Remove-Item -Recurse -Force C:/ProgramData/chocolatey',
before => Class['chocolatey_sw'],
}
# lint:endignore
# module: ceritsc/chocolatey_sw
class { 'chocolatey_sw':
creates => ['C:/ProgramData/chocolatey'], # check for install dir
}This ensures that versions with the old |
|
@genebean Not bad, except I don't want the deployment to attempt to install programs again. command => 'Remove-Item -Recurse -Force C:/ProgramData/chocolatey',This would need to do every folder underneath, except for 'lib'. ;) |
|
@trekytech7 - I can do that (and am glad you pointed it out). I'll post back soon with a revised version. |
|
@ferventcoder Encountered another hitch while testing prior to turning puppet management back on in 8 undergrad labs. This issue may occur from time to time; if the Chocolatey install fails, for some reason or other :(. The unless statement below will not determine that the choco installation is incomplete (or whatever -I've NO time to look into it). unless => 'if (Test-Path "C:\ProgramData\chocolatey\chocolateyinstall\chocolatey.ps1") { exit 1}',My other mistake here was to order a puppet agent upgrade before chocolatey upgrade, so it didn't even try to re-install chocolatey (& wouldn't) if the puppet upgrade failed... Ahh! I'm now changing the chocolatey to be before the puppet upgrade, including reboots. I may change the 'unless' to use a script instead, so I can validate the choco install too. Or perhaps, have the script check the install right after and then re-try if there was an issue. I'm currently undecided which method to use, but it should definitely be more robust (& automated, so every client fixes itself). |
|
@trekytech7 I haven't posted back for this very reason. I like your idea of having the exec also do the new chocolatey install since it is what kills the old one. |
|
@trekytech7 What about this? The # lint:ignore:80chars
exec { 'remove-old-chocolatey':
provider => powershell,
onlyif => 'if (Test-Path -Path "C:/ProgramData/chocolatey/chocolateyinstall/chocolatey.ps1") { exit 0 } else { exit 1 }',
command => 'Get-ChildItem -Path C:/ProgramData/chocolatey | Where-Object {$_.Name -NotMatch "^lib$" } | Remove-Item -Recurse -Force',
before => Class['chocolatey_sw'],
}
# lint:endignore
# module: ceritsc/chocolatey_sw
class { 'chocolatey_sw':
creates => 'C:/ProgramData/chocolatey/choco.exe',
} |
|
Slight revision # lint:ignore:80chars
exec { 'remove-old-chocolatey':
provider => powershell,
onlyif => 'if (Test-Path -Path "C:/ProgramData/chocolatey/chocolateyinstall/chocolatey.ps1") { exit 0 } else { exit 1 }',
command => 'Get-ChildItem -Path C:/ProgramData/chocolatey | Where-Object {$_.Name -NotMatch "^lib$" } | Remove-Item -Recurse -Force',
before => Class['chocolatey_sw'],
}
# lint:endignore
# module: ceritsc/chocolatey_sw
class { 'chocolatey_sw':
creates => 'C:/ProgramData/chocolatey/choco.exe',
before => Package['chocolatey'],
} |
|
@genebean I like your revised 'remove-old-chocolatey' oneliner. command => 'Get-ChildItem -Path C:/ProgramData/chocolatey | Where-Object {$_.Name -NotMatch "^lib$" } | Remove-Item -Recurse -Force',Removing the old version would fix the failure I more recently experienced, where the chocolatey installation is incomplete & fails, even manually, to be re-installed (mentioned above). The issue probably desires a new issue #. I manually deleted the install folders, except 'lib', and was able to manually re-install. The item at C:\ProgramData\chocolatey\bin\ has children and the Recurse parameter was not specified. If you continue,
all children will be removed with the item. Are you sure you want to continue?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):
WARNING: Was not able to replace 'C:\ProgramData\chocolatey\bin\' with ''.@ferventcoder If you would like the install files for the above 'NEW' issue, then I did keep a copy. However, I'm running out of time and must move onto other things, such as fixing our MDT deployment server ;). |
|
Adding this as a documentation issue. |
ferventcoder
changed the title
|
#65 is related |
|
in 0.9.9.8 i believe there is are some minor bugs in the installer. I figured out a way to instrument it, but all i got in the log- |
|
I think the errors in stderr are benign indicating a I have a solution to these upgrading/installing FileStream errors and I plan to confine the solution to PSv2. CAUTION: The drawback of my solution is that is that if a nested function fails within install_chocolatey_official (if ($error -ne $null)), we will not fail the resource (which is what is causing the filestream error, but instead just report on it. I believe this solution is be better, because at least you can see the error and troubleshoot, instead of the error on stderr handling. I would expect a true failed install (as I have seen in several scenarios), the provider/packages will have issues anyway and force subsequent resources skipping anyway. If there is truly a problem, one will have to investigate the debug log. Alternatives-
|
…on PSv2 Powershell version 2, has several issues in handling output redirection This is best documented here: https://connect.microsoft.com/PowerShell/feedback/details/587165/ powershell-double-redirection-problem Another obscure bug that occurs in powershell is here. https://connect.microsoft.com/PowerShell/feedback/details/371321/ benign-errors-for-missing-closing-are-left-in-the-error-variable These 2 issues are compounded in the provider, because the benign error sent to $error, then triggers the double redirection issue within puppet. This will automatically fail the resource. This patch is confined to Powershell v2 (Win2008r2/Win7) and essentially captures the output from running chocolateyInstall.ps1 via a variable. We can now see the errors that are thrown instead of the FileStream errors in a log stored here: $env:TEMP\chocoError.log While this may cause a false positive success to be returned to puppet, IMHO this is better than a false failure, based on upstream legacy bugs to be returned, particularly because of the transparency around the $error content. This fix leaves the existing logic intact for Powershell versions >2 as I have not observed. The recommendation to avoid this scenario altogether on Win2008r2 is to install .NET 4.5 and then WMF 4.0, or use Win2012+
…on PSv2 Powershell version 2, has several issues in handling output redirection This is best documented here: https://connect.microsoft.com/PowerShell/feedback/details/587165/ powershell-double-redirection-problem Another obscure bug that occurs in powershell is here. https://connect.microsoft.com/PowerShell/feedback/details/371321/ benign-errors-for-missing-closing-are-left-in-the-error-variable These 2 issues are compounded in the provider, because the benign error sent to $error, then triggers the double redirection issue within puppet. This will automatically fail the resource. This patch is confined to Powershell v2 (Win2008r2/Win7) and essentially captures the output from running chocolateyInstall.ps1 via a variable. We can now see the errors that are thrown instead of the FileStream errors in a log stored here: $env:TEMP\chocoError.log While this may cause a false positive success to be returned to puppet, IMHO this is better than a false failure, based on upstream legacy bugs to be returned, particularly because of the transparency around the $error content. This fix leaves the existing logic intact for Powershell versions >2 as I have not observed. Additionally write-host calls were switched to write-output as a best practice to avoid observed Filestream errors within this edge case. The recommendation to avoid this scenario altogether on Win2008r2 is to install .NET 4.5 and then WMF 4.0, or use Win2012+
…on PSv2 Powershell version 2, has several issues in handling output redirection This is best documented here: https://connect.microsoft.com/PowerShell/feedback/details/587165/ powershell-double-redirection-problem Another obscure bug that occurs in powershell is here. https://connect.microsoft.com/PowerShell/feedback/details/371321/ benign-errors-for-missing-closing-are-left-in-the-error-variable These 2 issues are compounded in the provider, because the benign error sent to $error, then triggers the double redirection issue within puppet. This will automatically fail the resource. This patch is confined to Powershell v2 (Win2008r2/Win7) and essentially captures the output from running chocolateyInstall.ps1 via a variable. We can now see the errors that are thrown instead of the FileStream errors in a log stored here: $env:TEMP\chocoError.log While this may cause a false positive success to be returned to puppet, IMHO this is better than a false failure, based on upstream legacy bugs to be returned, particularly because of the transparency around the $error content. This fix leaves the existing logic intact for Powershell versions greater than as I have not observed this behavior on them. Additionally write-host calls were switched to write-output as a best practice to avoid observed Filestream errors within this edge case. The recommendation to avoid this scenario altogether on Win2008r2 is to install .NET 4.5 and then WMF 4.0, or use Win2012+
…on PSv2 Powershell version 2, has several issues in handling output redirection This is best documented here: https://connect.microsoft.com/PowerShell/feedback/details/587165/ powershell-double-redirection-problem Another obscure bug that occurs in powershell is here. https://connect.microsoft.com/PowerShell/feedback/details/371321/ benign-errors-for-missing-closing-are-left-in-the-error-variable These 2 issues are compounded in the provider, because the benign error sent to $error, then triggers the double redirection issue within puppet. This will automatically fail the resource. This patch is confined to Powershell v2 (Win2008r2/Win7) and essentially captures the output from running chocolateyInstall.ps1 via a variable. We can now see the errors that are thrown instead of the FileStream errors in a log stored here: $env:TEMP\chocoError.log While this may cause a false positive success to be returned to puppet, IMHO this is better than a false failure, based on upstream legacy bugs to be returned, particularly because of the transparency around the $error content. This fix leaves the existing logic intact for Powershell versions greater than 2 as I have not observed this behavior on them. Additionally write-host calls were switched to write-output as a best practice to avoid observed Filestream errors within this edge case. The recommendation to avoid this scenario altogether on Win2008r2 is to install .NET 4.5 and then WMF 4.0, or use Win2012+
…on PSv2 Powershell version 2, has several issues in handling output redirection This is best documented here: https://connect.microsoft.com/PowerShell/feedback/details/587165/ powershell-double-redirection-problem Another obscure bug that occurs in powershell is here. https://connect.microsoft.com/PowerShell/feedback/details/371321/ benign-errors-for-missing-closing-are-left-in-the-error-variable These 2 issues are compounded in the provider, because the benign error sent to $error, then triggers the double redirection issue within puppet. This will automatically fail the resource. This patch is confined to Powershell v2 (Win2008r2/Win7) and essentially captures the output from running chocolateyInstall.ps1 via a variable. We can now see the errors that are thrown instead of the FileStream errors in a log stored here: $env:TEMP\chocoError.log While this may cause a false positive success to be returned to puppet, IMHO this is better than a false failure, based on upstream legacy bugs to be returned, particularly because of the transparency around the $error content. This fix leaves the existing logic intact for Powershell versions greater than 2 as I have not observed this behavior on them. Additionally write-host calls were switched to write-output as a best practice to avoid observed Filestream errors within this edge case. The recommendation to avoid this scenario altogether on Win2008r2 is to install .NET 4.5 and then WMF 4.0, or use Win2012+
(GH-60) fix upgrade/installation Filestream errors on PSv2
I'm new here so sorry ahead of time if my posting is not conforming to customs... I am replying inline to Rob :)
Chocolatey update: from v0.9.8.25 (ChocolateyInstall=C:/ProgramData/chocolatey) to v0.9.9.5
My 1st try was to upgrade from old version to new using puppet-chocolatey provider, then from command line using "choco -f update chocolatey -version '0.9.9.5' -source '
<our private repo>' " and both methods failed. Of course the command line will be different now with the 'upgrade' command instead. (note: the command works if done manually, but not from puppet)2nd I tried to just re-install over previous chocolatey installation by executing a batch file from puppet with the standard install command from command line...
@PowerShell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('
<our private repo>\chocoInstall.ps1'))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin3rd try executes the chocolatey Install.ps1 directly with the puppet powershell provider...
Makes sense. Does running as SYSTEM vs. an Administrator (which is technically a user running as admin -like sudo) get similar environment variables or different... I suspect a different environment, but I haven't looked into this yet.
The error in Puppets run messages:
Yes. I was looking at this one... possibly related, but effects more recent version of chocolatey.
v0.9.8.25 to v0.9.9.5
puppet agent v3.7.2
The text was updated successfully, but these errors were encountered: