MSYS2 doesn't run anymore after update with pacman

[muellerto]

Description / Steps to reproduce the issue

1. Download a fresh msys2-x86_64-20240113.exe
2. install it
3. start mingw64.exe

This runs as expected. You can start what you want from there. Good so.

4. run pacman -Syu

This starts, updates as expected and comes then to the point where the current terminal is to be closed. After this it will never start anymore. Also the others (msys2.exe, mingw32.exe, ucrt64.exe) will not start.

Expected behavior

Expected is that pacman installs updates and then everything works as it has been for years.

Actual behavior

At the moment nothing works.

Since mingw64.exe doesn't run anymore I tried other command prompts like cmd.exe or wt.exe. When you start mingw64.exe from there it says nothing but doesn't run.

When you start ls.exe it says

> ls
      0 [main] ls (23032) shared_info::initialize: size of shared memory region changed from 58296 to 57272

This message comes now with the very most msys applications. I think the runtime is broken at a very central point. And because pacman.exe himself doesn't run anymore it can't fixed by another update. The user must uninstall it completely and install again a version that runs.

Note: uname.exe does also not run, so I can't provide a concrete Version number. I'm on a Windows 11 Pro 23H2, msys2 has been running very well for years on this machine, until today.

I will now go back to the plain msys2-x86_64-20240113.exe which seems to run well, avoiding updates int the next days. But what then?

Verification

• I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

?

Are you willing to submit a PR?

No response

[lazka]

Thanks.

I can't reproduce sadly. I'm also on Windows 11 Pro 23H2.

[muellerto]

Thanks.

I can't reproduce sadly. I'm also on Windows 11 Pro 23H2.

Can be it depends also on Windows updates.

Is msys related to dynamic Microsoft runtime libraries? My machine is a developer machine, I have a large Visual Studio 2022 installation on my disk and several versions of runtime DLLs.

I reinstalled now the whole package and didn't update since then. uname.exe says MSYS_NT-10.0-22631.

As far as I know I could set pacman packages on hold, so they never get an update until I allow it again. Until now I never did this. Perhaps this could be a workaround.

[muellerto]

I added now the following line to my pacman.conf:

IgnorePkg = msys2-runtime

With this I can do updates as expected, I get a lot of stuff, but at least msys2-runtime-3.5.3-1 is skipped. I hope that the binaries run well with the previous version.

[lazka]

I've just reverted some recent changes. Would you be so kind and test again?

[muellerto]

No, still no function at all with msys2-runtime-3.5.3-2.

>  ls
    0 [main] ls (17984) shared_info::initialize: size of shared memory region changed from 58296 to 57272

[lazka]

:(

[lazka]

What if you run taskkill /F /FI "MODULES eq msys-2.0.dll" in cmd?

[muellerto]

Oh.

I did now the following:

1. install a fresh msys2-x86_64-20240113.exe
2. run pacman -Syu (this gets msys2-runtime-3.5.3-2) until the window closes
3. then, without any MSYS window, run taskkill /F /FI "MODULES eq msys-2.0.dll" in a cmd.exe
4. start mintty.exe

And it runs. I can also call pacman -Syu to get the rest of the updates and all will be installed properly. When I check the runtime I get indeed:

$ pacman -Ss msys2-runtime
msys/msys2-runtime 3.5.3-2 [Installed]
    Posix emulation engine for Windows
[...]

Indeed it's pacman.exe which doesn't stop. There's no window anymore but pacman still runs with some conhost sub processes. Taskkill names one process to kill and that is probably this pacman.

[weberjn]

Same here. On a Windows 11 machine the msys-2.0.dll kill helped, but not on Windows 10.

Edit: After rebooting works on Windows 10, too.

[muellerto]

Good is that the runtime library seems to be OK. After that kill-operation you can indeed update it to the latest version and everything will run. It seems to be the update itself that fails when you don't kill pacman manually in the right moment. So the problem is at least much smaller than thought.

[WatermelonRei]

Same problem here. Just kill the pacman.exe process by taskmgr, run msys2.exe again and everything thing goes well.
Windows OS build: 22631.3447

[silverqx]

I have the same problem after an upgrade from msys2-runtime 3.4.x to 3.5.3 I get this:

0 [main] bash (38988) shared_info::initialize: size of shared memory region changed from 58296 to 57272

After manually killing the bash.exe process it started working. Some ABI changed I suppose, I don't know for what is this bash.exe process needed, but should be killed as part of the upgrade process?

[silverqx]

I'm not sure why I had this bash.exe running but before I killed it I saw something /tmp/tmate-xx or something like that and the only one who is using the tmate on my machine is Windows self-hosted runner and I used tmate a week ago and didn't restart from then, so this process has been running since then.