chocolatey / boxstarter

Repeatable, reboot resilient windows environment installations made easy using Chocolatey packages
https://boxstarter.org/
Apache License 2.0
1.29k stars 163 forks source link

Boxstarter window closes before I can read the error message #2

Open mwrock opened 9 years ago

mwrock commented 9 years ago

migrated from https://boxstarter.codeplex.com/workitem/86

I tried using the Boxstarter web launcher today to set up a new machine. However, chocolatey.org is currently "offline for maintenance" and requests to http://chocolatey.org/install.ps1 fail with a 503 error. This causes the script to fail, but the reason is not obvious just from observing the console window.

The console displays the following: Boxstarter may need to reboot your system. Please provide your password so that Boxstarter may automatically log you on. Your password will be security stored and encrypted. Autologon Password: ****** Boxstarter: Successfully authenticated password. Boxstarter: Disabling Automatic Updates from Windows Update Boxstarter: Chocolatey not installed. Downloading and installing... Boxstarter: Enabling Automatic Updates from Windows Update Type ENTER to exit: At this point, I can press Enter and a red error will be briefly displayed in the console, but the window closes before I can read the message.

I would expect this error would be displayed immediately when it occurs, rather than waiting for me to press Enter. Even better, Boxstarter should handle this and display its own error, perhaps something like "Boxstarter: Failed to install Chocolatey, see boxstarter.log for details."

CollinChaffin commented 6 years ago

Well I guess after three years this open issue is still an issue because no matter what, when it hits the azure module install (the previous are successful) on multiple Win7x64 PS 5.1 systems using Chocolatey, it flashes a red error, closes ALL my PS windows and despite trying to tee it into a transcript, I have no idea why it's failing. Given that this issue hasn't been fixed in years, and this whole package's purpose is to perform trustworthy automation of my builds, it does not exact give one a warm and fuzzy when you cannot get the error to present itself long enough to read when installing itself, and it's approaching a half-decade in age as being a known issue (this issue # is older than my youngest child). :ake )

Perhaps I'll capture a video screencap to demonstrate just how bad this issue is when it happens (not to mention the damage it does by killing all other PS console windows that are active).

CollinChaffin commented 6 years ago

Here is more data, which is even more mind boggling as I am new to Boxstarter and hope to god all of it's automated functions don't behave this way. Not much data other than "something went wrong":

Chocolatey.log:

2017-08-27 23:31:52,338 17444 [DEBUG] - Checking that 'C:\Temp\chocolatey\WindowsAzurePowershell\1.6.0\azure-powershell.1.6.0.msi' is the size we expect it to be.
2017-08-27 23:31:52,341 17444 [DEBUG] - Verifying package provided checksum of '' for 'C:\Temp\chocolatey\WindowsAzurePowershell\1.6.0\azure-powershell.1.6.0.msi'.
2017-08-27 23:31:52,355 17444 [DEBUG] - Running Get-ChecksumValid -file 'C:\Temp\chocolatey\WindowsAzurePowershell\1.6.0\azure-powershell.1.6.0.msi' -checksum '' -checksumType '' -originalUrl 'https://github.com/Azure/azure-powershell/releases/download/v1.6.0-July2016/azure-powershell.1.6.0.msi' 
2017-08-27 23:31:52,357 17444 [DEBUG] - Empty checksums are allowed due to allowEmptyChecksums feature or option.
2017-08-27 23:31:52,379 17444 [DEBUG] - Running Install-ChocolateyInstallPackage -packageName 'WindowsAzurePowershell' -fileType 'msi' -silentArgs '/quiet /norestart' -file 'C:\Temp\chocolatey\WindowsAzurePowershell\1.6.0\azure-powershell.1.6.0.msi' -validExitCodes '0 3010' -useOnlyPackageSilentArguments 'False' 
2017-08-27 23:31:52,381 17444 [DEBUG] - Running Get-ProcessorBits -compare '32' 
2017-08-27 23:31:52,386 17444 [INFO ] - Installing WindowsAzurePowershell...
2017-08-27 23:31:52,426 17444 [DEBUG] - Running Start-ChocolateyProcessAsAdmin -validExitCodes '0 3010' -workingDirectory 'C:\Temp\chocolatey\WindowsAzurePowershell\1.6.0' -statements '/i "C:\Temp\chocolatey\WindowsAzurePowershell\1.6.0\azure-powershell.1.6.0.msi" /quiet /norestart ' -exeToRun 'C:\Windows\System32\msiexec.exe' 
2017-08-27 23:31:52,447 17444 [DEBUG] - Test-ProcessAdminRights: returning True
2017-08-27 23:31:52,453 17444 [DEBUG] - Elevating permissions and running ["C:\Windows\System32\msiexec.exe" /i "C:\Temp\chocolatey\WindowsAzurePowershell\1.6.0\azure-powershell.1.6.0.msi" /quiet /norestart ]. This may take a while, depending on the statements.
2017-08-27 23:31:53,277 17444 [ERROR] - Exiting chocolatey abnormally. Please manually clean up anything that 
 was not finished.
2017-08-27 23:31:53,279 17444 [ERROR] - Please do not ever use Control+C or close the window to exit.

One guess.......what happens if azure 1.6 is already installed via the PS gallery (or just install the Azure 1.6.0 manually via MSI or via Chocolatey)?

EDIT: I'll answer my own question - it works - kind of. It now fully installs boxstarter.azure, and all other modules and does not crash at the same spot. However, it lastly installs the boxstarter.hyperv which must ultimately at the very end for some reason insist on RE-INSTALLING the azure msi......that now is already installed (by this very same boxstarter install), which is even shown in the log (pasted below). This is ludicrous I am simply attempting to install this via Choco the easiest install package mgr for windows there is, and I'm an hour into this and what I want boxstarter for is to make my install processes more efficient.......

Here is the log showing how only after I manually uninstall the Azure 1.6.0 msi, does boxstarter Azure module finally succeed but then for some reason repeats itself and again fail for already being installed, which crashes all open PS consoles and loses any associated processing data:

https://gist.github.com/CollinChaffin/d0bfdb099cb6f990050739be1c0422d1

Is there just so little (like zero) error checking other than looking for what appears to be a SINGLE SUCCESS return code from the MSI (which will never then help explain ANY failure) that I have to literally first run msiexec to uninstall every single other app install so that boxstarter can succeed?

CollinChaffin commented 6 years ago

FYI I have not only found the root cause of all of this crap, but a workaround and even though Boxstarter should absoltely be able to properly detect errors in whatever is necessary for it's own install.......the root cause of all of this is ultimatley the bad packaging of the primary Azure 1.6.0 choco package named "windowsazurepowershell" that is in turn called by multiple Boxstarter module installs.

I detailed my findings in the comments of that package at:

https://chocolatey.org/packages/WindowsAzurePowershell

But since others began reporting this exact failure to this guy over half a year ago without a single response (or fix), I simply came up with, tested, and documented there a workaround to allow folks to both successfully install Azure 1.6.0 but most importantly then show it in the Choco lib as successfully installed upon further detections (at every Boxstarter install apparently), and now no matter what I do, all Boxstarter installs are successful on all my boxes after performing the following:

if(${env:ProgramFiles(x86)} -ne $null){ $programFiles86 = ${env:ProgramFiles(x86)} } else { $programFiles86 = $env:ProgramFiles }
mkdir "$programFiles86\Microsoft SDKs\Windows Azure\PowerShell\Azure"
copy "$programFiles86\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Azure.psd1" "$programFiles86\Microsoft SDKs\Windows Azure\PowerShell\Azure"

Which now instead of crashing the entire Powershell subsystem and never retunring a successful package install, any time you perform a choco install on that package you get this:

D:\> choco install windowsazurepowershell
Chocolatey v0.10.7
[Pending] Removing incomplete install for 'WindowsAzurePowershell'
Installing the following packages:
windowsazurepowershell
By installing you accept licenses for the packages.

WindowsAzurePowershell v1.6.0 [Approved]
windowsazurepowershell package files install completed. Performing other installation
steps.

Windows Azure Powershell is already installed.
The install of windowsazurepowershell was successful.
Software install location not explicitly set, could be in package or
default install location if installer.

Chocolatey installed 1/1 packages.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

....and now I can't make any Boxstarter module install fail.....on any of my systems! : _bow:

Chocolatey installed 8/8 packages.
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

Installed:
 - boxstarter.bootstrapper v2.10.3
 - boxstarter.hyperv v2.10.3
 - boxstarter.winconfig v2.10.3
 - boxstarter v2.10.3
 - boxstarter.azure v2.10.3
 - boxstarter.testrunner v2.10.3
 - boxstarter.chocolatey v2.10.3
 - boxstarter.common v2.10.3

Note all of this stems from absolutely horrible single file check and a totally outdated/incorrect file path for previous installation. Because that fails, every time the choco install hits that package, it wants to reinstall and that MSI then totally BARFS out a bad return code which causes the cascade failures seen above. His code should be checking the registry properly for what would be present for 100% of all successful MSI package installations, and not the file system for a single file in the entire package especially when paths can change.

CollinChaffin commented 6 years ago

I went one step further for everyone else finding that the other root cause here is that even if run manually, the way Microsoft authored this MSI has custom actions that will FORCE CLOSE ALL POWERSHELL PROCESSES. Even manually, the only other option is to quit, which is friggin just stupid because it is absolutely acceptable to have the 3rd option to ignore leave open all PS windows, and rename in use files are next reboot as has been done for decades. Why they left out option 3 I have no idea, but I put it back it myself by creating a custom MST transform one can simply use and leave the original MSI in-tact so upgrades etc. will all remain unchanged and also keep everything in a fully MS-supported condition since MSTs are fully supported by MS and not a hack like editing the MSI file itself etc.

Here is the link for the custom transform. It contains both the attached binary MST transform file, and the correct command line to execute. The difference is that when applying the transform, you can now install the package in a Powershell window and the common sense 3rd option instead of killing all PS processes or cancelling I've added the option to simply rename files in use (if any) leave PS alone and install the darn package.

Please obviously test this in a non-production environment first, this transform only does 2 things and that is remove the two custom actions that specifically force close powershell - nothing else. I take no responsibility I am only providing these for educational purposes etc.

https://gist.github.com/CollinChaffin/46e00b6c930bcb824bea2a19a5e06874