when the new msys2-installer release, I try to run the new installer, but it can't upgrade my old installation, and pacman -Syu do nothing, what should i do?

Hi,

I was quite confused when trying to configure my MSYS2 environment after i edited the relative ini files. Upon launching manually the msys2.exe files the ini file was inherited, then upon launching start menu shortcuts it wasn't.

To my surprise I noticed the created shortcuts were pointing to the cmd files which are not considering the ini file somehow. Can you please fix the shortcuts to just use the .exe launchers respectively?

This would solve ton of usability issues against MSYS2.

Thank you in advance,
Julian

Just tried downloading this on Win10 and Defender barfed saying it had the following trojan.

Detected: Trojan:Win32/Tnega.AMK!MSR

Affected items: file: C:\Users\xxxxx\Downloads\msys2-x86_64-20200719.exe

webfile: C:\Users\xxxxx\Downloads\msys2-x86_64-20200719.exe|https://github-production-release-asset-2e65be.s3.amazonaws.com/80988227/0260ba80-c9a2-11ea-8440-329bb71872e1?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20200719%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200719T225819Z&X-Amz-Expires=300&X-Amz-Signature=3914350bfc5ced016ee78cedaa8f5ae0b413db1544faf0fbae1f7b43a89bb4ae&X-Amz-SignedHeaders=host&actor_id=28606059&repo_id=80988227&response-content-disposition=attachment%3B%20filename%3Dmsys2-x86_64-20200719.exe&response-content-type=application%2Foctet-stream|pid:3088,ProcessStart:132396738872846081

NSIS would give us

• Greater flexibility during the installation process
• Smaller installer size (no Qt)
• Maybe silent CLI installation

See also: m-ab-s/media-autobuild_suite/issues/1802

Link to nightly build in readme is broken due to the readme just using "-latest", however in the releases page a date is there. I don't understand why the date there exists, because it also is somehow not the date of the commit it is released from, nor the date the releases page claims the release was made (which is Jan 13). Is this a mess-up (fine; it happens) or did someone compromise a Github account and post a malicious executable as a release?

Related (?) issue: #58

Thought I had the same issue but it turns out apparently not... Copying my message from there here below.

==========================

Same thing started happening to me yesterday with no changes on my end (been working for months up until now). Was definitely working two days ago since I have a script to force-rebuild my image daily. I see this on multiple machines and OS versions.

Tried both isolation modes (hyperv and process) and neither are currently working for me. One slight difference to the original reporter is that I'm using servercore:ltsc2022.

Still trying to diagnose further but unfortunately it's difficult to get diagnostic information from Windows containers for these sorts of issues. Trying to investigate using the information here: https://learn.microsoft.com/en-us/virtualization/windowscontainers/troubleshooting

EDIT:

Actually, I think I may have misunderstood the original issue in this thread and conflated it with mine. In my case the processes all appear to run successfully and terminate normally, but then the RUN step never finishes and just hangs indefinitely when finalizing the layer. I'm guessing this is probably a distinct issue and I misclassified it as the same as the one here due to the timing.

Strange though that it's happening on multiple machines and seems to coincide with the latest installer release. I tried rolling back to an earlier installer but that didn't help. Likely because whatever is causing the issue gets updated to the same version as in the latest installer anyway, but that's just a guess on my part so far - I need to do additional testing.

Hello,

I found the following warnings when I update the system by pacman -Syu --noconfirm

warning: could not get file information for clang32/
warning: could not get file information for clang32/bin/
warning: could not get file information for clang32/etc/
warning: could not get file information for clang32/etc/config.site
warning: could not get file information for clang32/include/
warning: could not get file information for clang32/lib/
warning: could not get file information for clang32/share/
warning: could not get file information for clang64/
warning: could not get file information for clang64/bin/
warning: could not get file information for clang64/etc/
warning: could not get file information for clang64/etc/config.site
warning: could not get file information for clang64/include/
warning: could not get file information for clang64/lib/
warning: could not get file information for clang64/share/
warning: could not get file information for opt/

The above warnings occur when the filesystem package is updating.
The pacman collects information of file and directory by lstat function when the filesystem package update.

However, the above directories(/clang32, /clang64, and /opt) don't exist in the state just after installing MSYS2.
So, the pacman can't collect information of them.

I should create these directories. Because the filesystem package has been installed from the beginning.

I think that these warnings are resolved below the patch. (Sorry, I can't confirm the patch operation.)

diff --git a/make-msys2-installer b/make-msys2-installer
old mode 100644
new mode 100755
index 4e7e9ae..ae9ee20
--- a/make-msys2-installer
+++ b/make-msys2-installer
@@ -60,7 +60,7 @@ create_archives() {
   [ -d "${_data}" ] && rm -rf "${_data}"
   mkdir -p "${_data}"
   local _dirs=
-  for curr_dir in /dev /etc /var /tmp /usr /mingw32 /mingw64 /msys2_shell.cmd /msys2.exe /mingw32.exe /mingw64.exe /msys2.ini /mingw32.ini /mingw64.ini /msys2.ico /autorebase.bat autorese
base1st.bat; do                                                                                                                                                                            
+  for curr_dir in /dev /etc /var /tmp /usr /opt /clang32 /clang64 /mingw32 /mingw64 /msys2_shell.cmd /msys2.exe /mingw32.exe /mingw64.exe /msys2.ini /mingw32.ini /mingw64.ini /msys2.icoau
torebase.bat autorebasebase1st.bat; do                                                                                                                                                     
     if [[ -d ${_newmsys}${curr_dir} || -f ${_newmsys}${curr_dir} ]]; then
       _dirs="${_dirs} ${_newmsys}$curr_dir"
     fi

I installed MSYS2 by msys2-x86_64-20200602.exe.

Thank you,

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-37172

So there is an issue to track this.

I couldn't find any other installer that handles this, so I'm not sure what the right thing to do is (except cygwin, which seems to set some hardcoded ACLs, but I couldn't find their code/logic)

The only thing I can think of is:

icacls.exe C:/msys64 //reset # just for debugging, this goes to the default we have now
icacls.exe C:/msys64 //grant "$USERDOMAIN\\$USERNAME:F" # full permissions for the installing user
icacls.exe C:/msys64 //inheritancelevel:r # disable inheritance, remove inherited permissions

Though not sure if we have the current user somehow in the installer, and if that breaks anything else. It might give more permissions as before when installing into a more strict directory (??)

On could argue that this is how Windows works.. you will get the permissions of the directory you install to, and if C is world writable, then MSYS2 is too. But I understand the the defaults of both Windows and our installer make this insecure.

Ideas / thoughts / and pointers to other projects welcome.

How to change the name of the home directory so that it doesn't change automatically

How to deal this? Thanks.

We currently use azure-pipelines to build the installer, then update assets for an existing tag on github. I haven't found a github action that allows updating an asset. The official one doesn't support it, see actions/upload-release-asset#13

If anyone has any ideas please tell me :)

Installing MSYS2 with

msys2-x86_64-2022XXXX.exe install --root C:\MSYS2 --confirm-command

Only installs Icons for the current user, not for all users. This is for the latest release 20230718 and, at least the two before.

Hi all-

at https://www.msys2.org/ download link

0xf7a49b0ec

I go to here: https://www.msys2.org/dev/keyring/#master-key-signatures

I don't see that key at the first link at ubuntu.keyserver.com. Just trying to track down if there is a bad key.
I didn't get a virus but am trying to find out where it is coming from so I don't
install with the software causing it.

I can't verify. Can someone help me?

THANKS,
roboloki

All the artifacts on https://github.com/msys2/msys2-installer/releases/tag/nightly-x86_64 are missing, e.g. https://github.com/msys2/msys2-installer/releases/download/nightly-x86_64/msys2-base-x86_64-latest.tar.xz

Which is causing appveyor CI to fail

What license is msys2-installer provided under? Is it BSD-3clause like the mingw-packages repo, or something else?

Hi,

I have that issue on one of my work laptop where the the first-time init doesn't complete because of one error.

The corporate laptop is running Windows 7. I can't be admin. I don't have that issue on another one, so I has hoping it could be some registry/environment problem.

Pacman can't finish configuration, and I can't install more packages. I can copy a complete MSys2 install, but pacman gets confused about what packages are installed.

Any advice on how to troubleshoot the problem would be welcome.

Regards.

/usr/share/makepkg/util/parseopts.sh: line 119: init: read error: 0: Permission denied

pacman-key: option '--' is ambiguous; possibilities: 'add' 'config' 'delete' 'edit-key' 'export' 'finger' 'gpgdir' 'help' 'import' 'import-trustdb' 'init' 'keyserver' 'list-keys' 'list-sigs' 'lsign-key' 'nocolor' 'populate' 'recv-keys' 'refresh-keys' 'updatedb' 'verify' 'version'

/usr/share/makepkg/util/parseopts.sh: line 119: populate: read error: 0: Permission denied

pacman-key: option '--' is ambiguous; possibilities: 'add' 'config' 'delete' 'edit-key' 'export' 'finger' 'gpgdir' 'help' 'import' 'import-trustdb' 'init' 'keyserver' 'list-keys' 'list-sigs' 'lsign-key' 'nocolor' 'populate' 'recv-keys' 'refresh-keys' 'updatedb' 'verify' 'version'

/usr/share/makepkg/util/parseopts.sh: line 119: refresh-keys: read error: 0: Permission denied

pacman-key: option '--' is ambiguous; possibilities: 'add' 'config' 'delete' 'edit-key' 'export' 'finger' 'gpgdir' 'help' 'import' 'import-trustdb' 'init' 'keyserver' 'list-keys' 'list-sigs' 'lsign-key' 'nocolor' 'populate' 'recv-keys' 'refresh-keys' 'updatedb' 'verify' 'version'

For reference, here is the snippet of parseopts.sh:

	while (( $# )); do
		case $1 in
(..)
			--?*=*|--?*) # long option
				IFS='=' read -r opt optarg <<< "${1#--}" # this is line 119
				longoptmatch "$opt"
				case $? in
					0)
						# parse failure
						if [[ $optarg ]]; then
							printf "${0##*/}: $(gettext "option '%s' does not allow an argument")\n" "--$opt" >&2
							OPTRET=(--)
							return 1
						# --longopt
						else
							OPTRET+=("--$opt")
						fi
						;;

We could leverage the clangarm64 repo, but that means most of the MinGW ecosystem around GCC won't be available sometime

Whenever I try to download the installer (any version), it gets to like 90% and just fails to finish downloading. I've downloaded plenty of other things with no issue.

lol.

Works when openvr_api.dll version 1.0.10.0 is placed next to the installer (600,864 bytes - MD5 e85622ffa2fc95b618f86a5b8e2d15b8) but uhh... I can't imagine that being an actual, needed library.

Preparing the installation...

Preparing to unpack components...

Unpacking components...
Extracting "20230526msys64.7z"
Done

Installing component MSYS2
Copying skeleton files.
These files are for the users to personalise their msys2 experience.

They will never be overwritten nor automatically updated.


'./.bashrc' -> '/home/Ferdinand/.bashrc'
'./.bash_logout' -> '/home/Ferdinand/.bash_logout'
'./.bash_profile' -> '/home/Ferdinand/.bash_profile'

'./.profile' -> '/home/Ferdinand/.profile'

'C:\Windows\system32\drivers\etc\hosts' -> '/etc/hosts'

'C:\Windows\system32\drivers\etc\protocol' -> '/etc/protocols'

'C:\Windows\system32\drivers\etc\services' -> '/etc/services'

'C:\Windows\system32\drivers\etc\networks' -> '/etc/networks'

Installation path is C:\msys64, installer msys2-x86_64-20230526, Windows 10 build 19045.3086

I was hoping to be able to do a winget install msys2, but winget search mysys2 came up empty.

https://docs.microsoft.com/en-us/windows/package-manager/
https://docs.microsoft.com/en-us/windows/package-manager/package/repository
https://github.com/microsoft/winget-pkgs

I performed a fresh install of msys2 to D:\msys64 and all three shell programs (ucrt64, mingw64, and mingw32) fail to launch properly with the same error message:

/cmd.exe: Exit 126.
Failed to run '/cmd.exe': No such file or directory

Here's the InstallationLog.txt, but nothing in there seems to indicate an obvious error during installation.

The latest release from 2022-01-18 has an empty msys64/usr/ssl/certs/ca-bundle.crt and a number of other crt bundles are empty as well.

$ tar tavf msys2-base-x86_64-20220118.tar.xz | grep \\.crt\$
-rw-r--r-- runneradmin/None     0 2021-10-04 05:48 msys64/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
-rw-r--r-- runneradmin/None        0 2021-10-04 05:48 msys64/usr/share/pki/ca-trust-legacy/ca-bundle.legacy.default.crt
-rw-r--r-- runneradmin/None        0 2021-10-04 05:48 msys64/usr/share/pki/ca-trust-legacy/ca-bundle.legacy.disable.crt
-rw-r--r-- runneradmin/None   863205 2021-10-04 05:48 msys64/usr/share/pki/ca-trust-source/ca-bundle.trust.crt
-rw-r--r-- runneradmin/None        0 2021-10-04 05:48 msys64/usr/ssl/certs/ca-bundle.crt
-rw-r--r-- runneradmin/None        0 2021-10-04 05:48 msys64/usr/ssl/certs/ca-bundle.trust.crt

vs previous release:

$ tar tavf msys2-base-x86_64-20211130.tar.xz | grep \\.crt\$
-r--r--r-- runneradmin/None 230529 2021-11-30 11:39 msys64/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
-rw-r--r-- runneradmin/None        0 2021-10-04 05:48 msys64/usr/share/pki/ca-trust-legacy/ca-bundle.legacy.default.crt
-rw-r--r-- runneradmin/None        0 2021-10-04 05:48 msys64/usr/share/pki/ca-trust-legacy/ca-bundle.legacy.disable.crt
-rw-r--r-- runneradmin/None   863205 2021-10-04 05:48 msys64/usr/share/pki/ca-trust-source/ca-bundle.trust.crt
-rw-r--r-- runneradmin/None   203117 2021-11-30 11:39 msys64/usr/ssl/certs/ca-bundle.crt
-rw-r--r-- runneradmin/None   230529 2021-11-30 11:39 msys64/usr/ssl/certs/ca-bundle.trust.crt

This prevents pacman from verifying mirrors and pulling any updates.

First attempt

Hangs on confirm dialog:

msys2 v20200720.0.0 [Approved]
msys2 package files install completed. Performing other installation steps.
The package msys2 wants to run 'chocolateyinstall.ps1'.
Note: If you don't run this script, the installation will fail.
Note: To confirm automatically next time, use '-y' or consider:
choco feature enable -n allowGlobalConfirmation

I cannot type any response to the prompt, and it will not go away.

force reinstall

Force reinstall fails. Possibly a separate bug, but who cares? I wanted one thing to just work, now I have three things that just do not.

PS C:\Windows\system32> choco install msys2
Chocolatey v0.10.15
Installing the following packages:
msys2
By installing you accept licenses for the packages.
msys2 v20200720.0.0 already installed.
 Use --force to reinstall, specify a version to install, or try upgrade.

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

Warnings:
 - msys2 - msys2 v20200720.0.0 already installed.
 Use --force to reinstall, specify a version to install, or try upgrade.

PS C:\Windows\system32> choco install msys2 --force
Chocolatey v0.10.15
Installing the following packages:
msys2
By installing you accept licenses for the packages.
msys2 v20200720.0.0 already installed. Forcing reinstall of version '20200720.0.0'.
 Please use upgrade if you meant to upgrade to a new version.
This is try 1/3. Retrying after 300 milliseconds.
 Error converted to warning:
 (5) Access is denied: [\\?\C:\ProgramData\chocolatey\lib-bkp\msys2]
This is try 2/3. Retrying after 400 milliseconds.
 Error converted to warning:
 (5) Access is denied: [\\?\C:\ProgramData\chocolatey\lib-bkp\msys2]
Maximum tries of 3 reached. Throwing error.
This is try 1/3. Retrying after 300 milliseconds.
 Error converted to warning:
 (32) The process cannot access the file because it is being used by another process: [\\?\C:\ProgramData\chocolatey\lib-bkp\msys2\.chocolateyPending]
This is try 2/3. Retrying after 400 milliseconds.
 Error converted to warning:
 (32) The process cannot access the file because it is being used by another process: [\\?\C:\ProgramData\chocolatey\lib-bkp\msys2\.chocolateyPending]
Maximum tries of 3 reached. Throwing error.
Error during backup (move phase):
 (32) The process cannot access the file because it is being used by another process: [\\?\C:\ProgramData\chocolatey\lib-bkp\msys2\.chocolateyPending]
There was an error accessing files. This could mean there is a
 process locking the folder or files. Please make sure nothing is
 running that would lock the files or folders in this directory prior
 to upgrade. If the package fails to upgrade, this is likely the cause.
[NuGet] Uninstalling 'msys2 20200720.0.0' might cause 'haskell-dev 0.0.1' to be broken.
This is try 1/3. Retrying after 300 milliseconds.
 Error converted to warning:
 (32) The process cannot access the file because it is being used by another process: [\\?\C:\ProgramData\chocolatey\lib\msys2\.chocolateyPending]
This is try 2/3. Retrying after 400 milliseconds.
 Error converted to warning:
 (32) The process cannot access the file because it is being used by another process: [\\?\C:\ProgramData\chocolatey\lib\msys2\.chocolateyPending]
Maximum tries of 3 reached. Throwing error.
Unable to remove existing package prior to forced reinstall:
 (32) The process cannot access the file because it is being used by another process: [\\?\C:\ProgramData\chocolatey\lib\msys2\.chocolateyPending]

msys2 v20200720.0.0 (forced) [Approved]
msys2 not installed. An error occurred during installation:
 The process cannot access the file 'C:\ProgramData\chocolatey\lib\msys2\.chocolateyPending' because it is being used by another process.

Chocolatey installed 0/0 packages.
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
The process cannot access the file 'C:\ProgramData\chocolatey\lib\msys2\.chocolateyPending' because it is being used by another process.

Second attempt

PS C:\Windows\system32> choco install msys2
Chocolatey v0.10.15
Installing the following packages:
msys2
By installing you accept licenses for the packages.
Progress: Downloading msys2 20200720.0.0... 100%

msys2 v20200720.0.0 [Approved]
msys2 package files install completed. Performing other installation steps.
The package msys2 wants to run 'chocolateyinstall.ps1'.
Note: If you don't run this script, the installation will fail.
Note: To confirm automatically next time, use '-y' or consider:
choco feature enable -n allowGlobalConfirmation
Do you want to run the script?([Y]es/[A]ll - yes to all/[N]o/[P]rint): A

'C:\tools\msys64' already exists and will only be updated.
Invoking first run to setup things like bash profile, gpg etc...
Invoking msys2 shell command: -defterm -no-start -c "ps -ef | grep '[?]' | awk '{print $2}' | xargs -r kill"
ERROR: This command cannot be run due to the error: The system cannot find the file specified.
The install of msys2 was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\msys2\tools\chocolateyinstall.ps1'.
 See log for details.

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

Failures
 - msys2 (exited -1) - Error while running 'C:\ProgramData\chocolatey\lib\msys2\tools\chocolateyinstall.ps1'.
 See log for details.

I think this is the key phrase (copied from log):

2020-07-26 01:41:15,992 12880 [INFO ] - Invoking first run to setup things like bash profile, gpg etc...
2020-07-26 01:41:16,001 12880 [INFO ] - Invoking msys2 shell command: -defterm -no-start -c "ps -ef | grep '[?]' | awk '{print $2}' | xargs -r kill"
2020-07-26 01:41:16,035 12880 [ERROR] - ERROR: This command cannot be run due to the error: The system cannot find the file specified.

Deleted folder then tried reinstalling

deleted C:\tools\msys64

PS C:\WINDOWS\system32> choco install msys2
Chocolatey v0.10.15
Installing the following packages:
msys2
By installing you accept licenses for the packages.
Progress: Downloading msys2 20200720.0.0... 100%

msys2 v20200720.0.0 [Approved]
msys2 package files install completed. Performing other installation steps.
The package msys2 wants to run 'chocolateyinstall.ps1'.
Note: If you don't run this script, the installation will fail.
Note: To confirm automatically next time, use '-y' or consider:
choco feature enable -n allowGlobalConfirmation
Do you want to run the script?([Y]es/[A]ll - yes to all/[N]o/[P]rint): y

Installing to: C:\tools\msys64
Extracting 64-bit C:\ProgramData\chocolatey\lib\msys2\tools\msys2-base-x86_64-20200720.tar.xz to C:\tools\msys64...
C:\tools\msys64
Extracting C:\tools\msys64\msys2-base-x86_64-20200720.tar to C:\tools\msys64...
C:\tools\msys64
ERROR: The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: Access to the path 'C:\tools\msys64\msys64\usr' is denied.
The install of msys2 was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\msys2\tools\chocolateyinstall.ps1'.
 See log for details.

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

Failures
 - msys2 (exited -1) - Error while running 'C:\ProgramData\chocolatey\lib\msys2\tools\chocolateyinstall.ps1'.
 See log for details.

Administrator has full control over the folder that the script claims it cannot access:

Error Log:

2020-07-26 18:10:55,373 880 [INFO ] - C:\tools\msys64
2020-07-26 18:10:55,420 880 [ERROR] - ERROR: The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: Access to the path 'C:\tools\msys64\msys64\usr' is denied.
2020-07-26 18:10:55,422 880 [DEBUG] - Built-in PowerShell host called with ['[System.Threading.Thread]::CurrentThread.CurrentCulture = '';[System.Threading.Thread]::CurrentThread.CurrentUICulture = ''; & import-module -name 'C:\ProgramData\chocolatey\helpers\chocolateyInstaller.psm1'; & 'C:\ProgramData\chocolatey\helpers\chocolateyScriptRunner.ps1' -packageScript 'C:\ProgramData\chocolatey\lib\msys2\tools\chocolateyinstall.ps1' -installArguments '' -packageParameters '''] exited with '-1'.

Non-existent msys2_shell.cmd

I have suspended the install process (by not answering the prompt) in order to inspect the folder contents. Your script's function contains FilePath = Join-Path $InstallPath msys2_shell.cmd . There is no such thing as msys2_shell.cmd.

function Invoke-Msys2Shell($Arguments) {
    if (![string]::IsNullOrWhiteSpace($Arguments)) { $Arguments += "; " }
    $Arguments += "ps -ef | grep '[?]' | awk '{print `$2}' | xargs -r kill"

    $params = @{
        FilePath     = Join-Path $InstallPath msys2_shell.cmd
        NoNewWindow  = $true
        Wait         = $true
        ArgumentList = "-defterm", "-no-start", "-c", "`"$Arguments`""
    }
    Write-Host "Invoking msys2 shell command:" $params.ArgumentList
    Start-Process @params
}

Also there appears to be a typo: ArgumentList = "-defterm", "-no-start", "-c", "`"$Arguments`"" has "`"$Arguments`"" which clearly can't be correct. Either you're trying to quote the output of a variable or you're trying to use a variable that includes quotes, which seems unlikely since $, not "$, denotes a variable.

Install-Msys2 function bugged

Install-Msys2 function skips un-tarring the archive when it needs to do that to detect msys2_shell.cmd later.

function Install-Msys2 {
    if (Test-Path $InstallPath) { 
        Write-Host "'$InstallPath' already exists and will only be updated."
        return 
    }

    Write-Host "Installing to:" $InstallPath
    $packageArgs = @{
        PackageName    = $Env:ChocolateyPackageName
        FileFullPath   = Get-Item $ToolsPath\*-i686*
        FileFullPath64 = Get-Item $ToolsPath\*-x86_64*
        Destination    = $InstallPath
    }
    Get-ChocolateyUnzip @packageArgs
    Remove-Item $ToolsPath\*.xz -ea 0

    $tarFile = Get-Item "$InstallPath\*.tar"
    Get-ChocolateyUnzip $tarFile $InstallPath
    Remove-Item "$InstallPath\*.tar" -ea 0
    $tardir = Get-Item "$InstallPath\msys*"
    if ([String]::IsNullOrWhiteSpace($tardir)) { throw "Can't find msys* directory from tar archive" }
    Move-Item $tardir\* $InstallPath
    Remove-Item $tardir
}

Script looks in wrong folder. Needs to look deeper

If $InstallPath is "C:\tools\msys64" instead of the temporary installation files folder (ProgramData\chocolatey...), then it is highly likely that your script is looking in the wrong folder. msys2_shell.cmd is located at "C:\tools\msys64\msys64\msys2_shell.cmd" --not "C:\tools\msys64\msys2_shell.cmd"

It would be nice to be able to SEE what the damn value of $InstallPath is. Any script that runs on a user's computer should have an IDE installed that will simulate the runtime and visualize the state of variables so people aren't stuck here making guesses what the variable is.

I am not a chocolatey maintainer. I should not be debugging this or reading ps1 scripts just to get MSYS2 installed. This is utterly ridiculous.

And this further proves why file systems should not be hierarchical i-node-based namespaces.

https://doc.qt.io/qtinstallerframework/qtinstallerframework-systeminfo-example.html#checking-the-operating-system-type

Error out with <Win7. In the future we can bump this to <8.1

Hi,
I have downloaded the file from the official website https://www.msys2.org/ and am trying to install the mysy2 in my computer with Windows 10 64bit environment.
However, when I click the file, there is no response.
How could I install it?
Thank you very much.

Both installer.exe and tarballs have clang32/clang64/clangarm64 directories but they are empty. They don't harm but are weird.

I have tried
msys2-x86_64-20200602.exe
msys2-x86_64-20200629.exe
msys2-x86_64-20200719.exe
msys2-x86_64-20200720.exe

except msys2-x86_64-20200522.exe, all other installer failed to install to my E:\

If you've ever installed and used https://git-scm.com/, it provides the option during installation to add Git GUI Here and Git Bash Here to the mouse click. I use this all the time because it is faster than using windows search to open the program and the path when you open "here" is already the directory that you're in. I propose that the MSYS2 installer provides an option similar to this for MSYS, MINGW64, and possibly MINGW32. Checkboxes for all or a selected executable would be an added bonus.

Several weeks ago (maybe a few months by now) I setup the sfx archive (msys2-base-x86_64-20210725.sfx.exe) on my system. It took several minutes to go through several "key ring" updates. That particular setup is still working fine on that machine.

I'm trying to setup msys2 on another PC now (windows), and it's completing in under a minute with several failures.

I'm wondering if this has to do with some of the certificate issues happening lately...

Anyways, the end result is that now I have projects that used to compile fine, but now some references are being reported as not declared in "this scope".

I was hoping to find a complete log in the msys2 root dir, but i was only able to take the screenshot during initial setup.

Did you forget to update the provided checksum on the msys2.org website?

with windows certutil I got "2dacadcc70cc122054e60914cbc6b689f685bef5713915a90f4185dd9da7954e" instead of the provided "a4fd4e48f506618ee5eb8bbd439c2b37433edff5ada04c72db82ccbdbca35cd7" for the "msys2-x86_64-20200602" version.

First of all, I especially like the way pacman manages packages, but the latest msys2 uses pacman to install python by default to 3.9. because python3.9 not support jpype, so manually installs python3.8 , After installing through .pkg.tar.zst, pip, numpy, etc. will fail. Why can't I allow specifying a version when doing "pacman -S mingw-w64-i686-python"? For example "pacman -S mingw-w64-i686-python3.8" ? I like this style as pacman but it also brings a lot of troubles. I like the flexibility of cygwin and envy the simplicity of pacman. lol

Hi,

please add command line switches to the installer for a silent installation without user interaction. This is needed for software deployment. Or if this switches already exist add something to the documentation.

Thanks

There was a core package update since then. Ideally nightly installer updates should be triggered by push to this repo and updates to core packages that require MSYS2 restart and maybe some packages involved in installer creation.

Command:

COPY ./msys2 C:/TEMP/msys2
RUN C:\TEMP\msys2\msys2-x86_64-20200602.exe --platform minimal --script auto-install.js

Error:

Step 9/33 : RUN C:\TEMP\msys2\msys2-x86_64-20200602.exe --platform minimal
 ---> Running in 8f40a237133d
The command 'cmd /S /C C:\TEMP\msys2\msys2-x86_64-20200602.exe --platform minimal' returned a non-zero code: 3221225781
C:/Program Files/Docker/docker.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory

It seems some dlls are missing. Is it possible to remove these dependency from the final executable?

Both installer and tarball fail to fully install in docker.

The installer does extract partially, but is missing bash.exe and pacman.exe
For the installer, I am running:

Invoke-WebRequest https://github.com/msys2/msys2-installer/releases/download/2022-01-18/msys2-base-x86_64-20220118.sfx.exe -Outfile C:\tools\msys-setup.exe;
Start-Process "C:\tools\msys-setup.exe" -ArgumentList "-y -oC:\ " -Wait

The tarball extracts more, including bash.exe but is missing pacman.exe.
For the tarball, I am running:

Invoke-WebRequest http://repo.msys2.org/distrib/msys2-x86_64-latest.tar.xz -Outfile C:\tools\msys2.tar.xz
Start-process "7z" -ArgumentList "e C:\tools\msys2.tar.xz -oC:\tools " -NoNewWindow -Wait
Start-process "7z" -ArgumentList "x C:\tools\msys2.tar -oC:\ " -NoNewWindow -Wait

I have tried running docker 'build' and docker 'run':

docker build --memory 2GB --isolation process --build-arg BASE_TAG=$BASE_TAG --tag $TAG $COMPOSE_DIR

docker run -it --memory 2GB --isolation process docker-virtual.artifactory.york.lan/windows/servercore:2009-amd64 powershell

Wonder if it's due to permissions or antivirus (Carbon Black or Endpoint Protector).

I have tried other installers:

https://github.com/msys2/msys2-installer/releases/download/nightly-x86_64/msys2-base-x86_64-latest.sfx.exe
https://github.com/msys2/msys2-installer/releases/download/nightly-x86_64/msys2-x86_64-latest.exe

And other tarballs:

https://github.com/msys2/msys2-installer/releases/download/nightly-x86_64/msys2-base-x86_64-latest.tar.xz 

This was running for us with previous Windows versions, 1809-amd64 and 1909-amd64.

After the upgrade done (pacman -Syu)), the terminal crash and would not open...

The latest msys2 installer is flagged as malicious by BitDefenderTheta at https://virustotal.com:

Also, the checksum on the website is different than the one from GitHub release:

Verify with SHA256 checksum 5e188c7f3d564a2291d20b717712bb6f789a17b415e540f528c0025130ada4e1

Is it safe to install msys2-x86_64-20220118.exe? Thx!

I'm not sure where to post this. The issue revolves around scripting MSYS2 installation and update.

Some other recent issues (msys2/MSYS2-packages#1962, msys2/MSYS2-packages#1965) have touched on the issue.

I assume most of the breakage will be caused by commits to https://github.com/msys2/MSYS2-packages.

GitHub Actions (GHA) now has MSYS2 installed on their Windows images. Both 64 & 32 bit clang cmake llvm toolchain ragel packages/groups are installed. Custom Actions have also been developed to install/update MSYS2. Of concern is that the script GHA is using will reliably update MSYS2. Currently, the images are updated frequently, typically every 10 days or better.

Also mentioned is moving some CI to GHA. I think there are several people using MSYS2 that would be willing to help. GHA supports jobs that conditionally run based on file locations, so specific jobs could be ran if, for instance, gpg, msys2-runtime or pacman files were changed.

I have mostly worked with MinGW build scripts (and not a lot), so I'm not familiar with the MSYS2 code, but I'd certainly be willing to help with GHA workflows if they will help with CI.

Also, GHA isn't the only CI, so a 'recommended' script would be helpful.

This is a very general issue, but making MSYS2 robust as far as scripted install/update is important.

Describe the issue

At the tail end of installation, I get a popup that says an error occurred.

Then I look in InstallationLog.txt and find these lines:

[297893] Writing maintenance tool: "D:\\bin\\msys64/uninstall.exe.new"
[297893] Writing maintenance tool.
[297918] Critical: Error writing Maintenance Tool:  "Cannot open temporary file: The system cannot find the path specified."
[297918] WriteError : Error writing Maintenance Tool : Cannot open temporary file: The system cannot find the path specified.
[1029485] Installation finished!

I started MSYS2 MinGW 64-bit from the start menu and observed that ls and find work just fine. The installation was successful enough, excluding the "Maintenance Tool"?

Steps to Reproduce the Problem

Run installation with default options to a directory like d:\bin\msys2. Note sure if this matters: Run it as a user that is in the local Administrators group but do not use the "Run as administrator" feature.

Additional Context: Operating System, Screenshots

• OS: Windows Server 2019, Version 1809 (OS Build 17763.1879)
• Installer: msys2-x86_64-20210725.exe
• Machine: some kind of VMware
• Some tickets that I do not think are related:
  • msys2/MSYS2-packages#1727
  • msys2/MSYS2-packages#1532

after installing MSYS2 in the default folder and running it, executing the command 'pacman -Syu' result in the following error:
'error: no usable package repositories configured.'

Windows 11 x64 build 22621.160
Msys2 installer for Windows release of 2022-06-03

Recently I tried to update all my installed Win32 apps using Microsoft's Windows Package Manager aka "Winget" and I discovered this (first screenshot). MSYS2 does not update by any means.
At first, I thought that the installer somehow is not working correctly with Winget but then I discovered this issue and realized that the whole version reporting system is broken.
Please consider fixing this since that MSYS2 "package" alone breaks the whole Winget experience.
On the second screenshot I tried to update MSYS2 using the newer .exe manually.

P.S. I have some conjectures on why this problem is not still fixed since this is very obvious and easy to find problem and I am almost certainly not the first one discovering this. My thoughts is that if you fix this, something else may break (I am really only guessing). If so, I propose very strange quirk to resolve issues with Winget. @Biswa96 in the above mentioned issue said:

That version number in Control Panel is just the version number of the installer and it has nothing to with packages version.

If that is correct, then this might work out. As you may see on third screenshot, I have GOG Galaxy installed on my machine. The GOG version is not reported to Windows OS so Winget does not know which version is installed. Since Winget 1.3 by default will be hiding packages that does not report their version, you may just make the installer stop reporting it's version to Windows just like GOG does.
Please use this quirk only in case of emergency 😂.

Not sure if this is the right place to suggest this.

Over time, new MSYS profiles are created or updated.
The start menu shortcuts should be updated accordingly when using pacman -Syu.

For example, I have the profiles clang32, clang64, clangarm64, mingw32, mingw64, msys2 and ucrt64 in my installation directory.
In my start menu, there is only mingw32, mingw64, msys2 and ucrt64; these are the profiles from 2021.

We should test the installer before publishing the nightly:

• sfx in docker on 2016/2019 in servercore
• gui installer with auto-install.js on 2016/2019

This allows users to more safely depend on the nightly build.

Is there possibly a build artifact available which contains the debug information
for msys-2.0.dll or an unstripped version of it?
I tried to have a look at a bug report against wine for the msys2-installer, and now I receive a crash inside msys-2.0.dll, and debug information would help to tell if that is an already known wine issue.

I also failed to find instructions to rebuild the msys-2.0.dll
from the msys2-runtime repository, I hope I not just have overlooked it?

We have these restrictions on the main page for the install location "Enter your desired Installation Folder (short ASCII-only path on a NTFS volume, no accents, no spaces, no symlinks, no subst or network drives, no FAT).".

We should show this on the installer page where one selects the location.

Hello, I created a symlink to a folder on my C drive (where I keep my github projects). I had to uninstall MSYS2 while trying to fix a bug in another project's build. When uninstalling, the folder on my C drive (not properly part of the MSYS2 folder) was completely cleared. Most of the work in there is pushed to github, so I think I am OK, but I wanted to flag this.

I'll create a script that recreates the issue, if that is helpful, but I wanted to raise this now because I think it is critically dangerous, unexpected behaviour.

Thanks

--Adam

Conext

I use mys2 inside the WindowsTerminal. To do that I add the following profile in the settings.json.

            {
                "commandline": "C:\\msys64\\msys2_shell.cmd -defterm -mingw64 -no-start -use-full-path -here",
                "guid": "{2c4de342-38b7-51cf-b940-2309a097f519}",
                "hidden": false,
                "icon": "C:\\msys64\\msys2.ico",
                "name": "msys2",
                "startingDirectory": "%USERPROFILE%"
            }

I also use, for different contexts, the bash bundled with from Git For Windows.
The Git For Windows Installer has the option to install a WindowsTerminal default profile in Windows Terminal.

See below the installer option and then the json code added to the profile.

            {
                "guid": "{2ece5bfe-50ed-5f3a-ab87-5cd4baafed2b}",
                "hidden": false,
                "name": "Git Bash",
                "source": "Git",
                "startingDirectory": "%USERPROFILE%"
            },

In the WindowsTerminal, such profile installation is called Profile Fragments. The commit that creates such feature in Git For Windows is this one.

Feature request

That all said. I think it is interesting if the msys2-installer also install a profile for WindowsTerminal.