Update package database and core system packages: Cannot open package file

[ZuBsPaCe]

Hi there. I'm new to MSYS2 and would like to evaluate it to build some software on windows which needs to be built with gcc.

Unfortunately I get an error on a fresh MSYS2 installation when running pacman -Suy. Sorry, can't tell if I did something stupid.

zub@space MSYS ~
$ pacman -Syu
:: Synchronizing package databases...
 mingw32 is up to date
 mingw64 is up to date
 msys is up to date
:: Starting core system upgrade...
warning: terminate other MSYS2 programs before proceeding
resolving dependencies...
looking for conflicting packages...

Packages (8) bash-4.4.023-2  filesystem-2020.02-2  libzstd-1.4.4-2  mintty-1~3.1.4-1  msys2-runtime-3.1.4-1  pacman-5.2.1-6  pacman-mirrors-20200329-1  zstd-1.4.4-2

Total Installed Size:  65.76 MiB
Net Upgrade Size:      -3.96 MiB

:: Proceed with installation? [Y/n] Y
(8/8) checking keys in keyring                                                                                [#################################################################] 100%
(8/8) checking package integrity                                                                              [#################################################################] 100%
(8/8) loading package files                                                                                   [#################################################################] 100%
error: could not open file /var/cache/pacman/pkg/msys2-runtime-3.1.4-1-x86_64.pkg.tar.zst: Child process exited with status 127
error: failed to commit transaction (cannot open package file)
Errors occurred, no packages were upgraded.

zub@space MSYS ~
$ ps
      PID    PPID    PGID     WINPID   TTY         UID    STIME COMMAND
     2172    2171    2172      18456  pty0     1049767 17:09:46 /usr/bin/bash
     2171       1    2171      18704  ?        1049767 17:09:46 /usr/bin/mintty
     1729       1    1729      27052  ?        1049767 17:00:47 /usr/bin/gpg-agent
     2285    2172    2285      31244  pty0     1049767 17:10:25 /usr/bin/ps

[nickives]

Came here to find info about this issue. Happened on two machines, one of which is a clean Windows VM

[lazka]

Sorry for the inconvenience :/ There is some breakage today with the upgrade path from the last stable installer.

Please try the nightly installer: https://github.com/msys2/msys2-installer/releases/download/nightly-x86_64/msys2-x86_64-latest.exe

[loganmc10]

This issue is also affecting AppVeyor builds

[nickives]

I seem to be able to install and get setup with that new installer. Thanks!

[mati865]

You can fix this issue by upgrading pacman first:

pacman -Sy pacman
pacman -Su

[ZuBsPaCe]

Thank you @mati865 . You're workaround worked, but there's a quirk. After updating pacman I called pacman -Su. During the installation, I got the prompt to close down the terminal window, restart msys2.exe and run the command again. The thing is, that msys2.exe did not start again. I tried multiple times and the process just quit right after.

It worked after a reboot, though. I could open msys2.exe successfully and the packman -Su ran through.

[mati865]

@ZuBsPaCe it should be printed in the terminal that you should close all remaining MSYS2 processes (or simply reboot) after the update before opening the shell again.

[ZuBsPaCe]

@mati865 Just for reference. The exact wording is:

warning: terminate MSYS2 without returning to shell and check for updates again
warning: for example close your terminal window instead of calling exit

I tried again, just to be sure. I close the terminal and mintty.exe shuts down. msys2.exe cannot be started thereafter. I see gpg-agent.exe and dimngr.exe hanging around, but that's all. Nowhere does it say, that you need a reboot, but I'm happy, that I figured that one out.

Thanks for your help. 👍

Edit: Found this in the troubleshooting section of the documentation:
Hunt down these processes in your favorite task manager and kill them, or just reboot your system. I better read the docs next time. 😅

[eine]

Sorry for the inconvenience :/ There is some breakage today with the upgrade path from the last stable installer.

Please try the nightly installer: msys2/msys2-installer@nightly-x86_64 msys2-x86_64-latest.exe (download)

Hi @lazka, I would like to put absolute no pressure, because this must be already stressful for you. However, I'm trying to setup MSYS2 on GitHub Actions, and there seems to be no solution since yesterday...

The context is setup-msys2, where the distributed release package is unpacked and (optionally) pacman -Syu --noconfirm is executed: https://github.com/eine/setup-msys2/blob/master/main.js#L24.

• It worked 5 days ago: https://github.com/eine/setup-msys2/actions/runs/104936430
• With 20200517, it works as long as pacman -Syu is not used: https://github.com/eine/setup-msys2/actions/runs/109156856
  • Otherwise, an error is produced: 0 [main] bash (7000) shared_info::initialize: size of shared memory region changed from 51128 to 40888.
• The "nightly" release produces the same result as 20200517. I think this is because, ATM, both are the same artifact: https://github.com/eine/setup-msys2/actions/runs/109159120

@k-takata (from #1961), note that I cannot reboot the system because this is being executed on a GitHub Actions workflow. As shown in the logs, I print tasklist after setup/update and before using it again. Unfortunately, I cannot see any process which belongs to MSYS2: https://github.com/eine/setup-msys2/runs/688612762?check_suite_focus=true#step:5:7. Killing gpg-agent explicitly was already tested by @Kha in leanprover/lean4#141.

Ref #1960

[mati865]

@eine as said above you can upgrade pacman first (assuming you installed with latest stable installed from 2019-05-24), then normal upgrade will work.

[eine]

@mati865, I would say I have already tried that with no success. However, I'm going to try it again.

[lazka]

@eine yeah, that needs fixing somehow. dirmngr.exe is also part of gnupg

@mati865 I think this is the "as long as any pre upgrade processes are still running nothing works" case, unrelated to pacman

[eine]

FTR, upgrading pacman first produces the same result, either with 20190524 or 20200517. See https://github.com/eine/setup-msys2/actions/runs/109176396 and https://github.com/eine/setup-msys2/runs/688664492.

@lazka, you rock! https://github.com/eine/setup-msys2/runs/688691639?check_suite_focus=true Of course, it'd be good to release a newer nightly (or hopefully "stable" release) which does not require this. Or to automatically handle it otherwise. However, it works for now! Thanks a lot! Is there any list of the tasks we should search for?

[SolarBear]

Hello! I just stumbled upon this problem on 2 machines.

1. Machine perl-Net-HTTP-6.06-1-any.pkg.tar.xz error #1 simply exits with error code 127 whatever the command, whether it's pacman or ls or....
2. Machine Package conflict #2 simply won't open msys2 anymore. I've tried opening it from a terminal and the command silently fails. Strangely enough, echo %ERRORLEVEL% returns 0.

[mati865]

Machine #1 simply exits with error code 127 whatever the command, whether it's pacman or ls or....

You might be missing some dll, maybe /usr/bin/msys-2.0.dll?

Machine #2 simply won't open msys2 anymore. I've tried opening it from a terminal and the command silently fails. Strangely enough, echo %ERRORLEVEL% returns 0.

You have running processes that have handle on msys-2.0.dll from before the update. Either kill them or reboot the system.

[SolarBear]

You might be missing some dll, maybe /usr/bin/msys-2.0.dll?

I compared the list of files in the directory with a working install: no missing files.

You have running processes that have handle on msys-2.0.dll from before the update. Either kill them or reboot the system.

Strange, but that was it! Thank you.

[lazka]

Here's another alternate way to clean up all the zombie processes

taskkill /f /fi "MODULES eq msys-2.0.dll"

This seems like a good solution to me. What about we run this at the end of every core update? (with confirmation in the tty case)

[emptyVoid]

I wouldn't recommend killing GnuPG daemons with taskkill since it does not discriminate by image (executable/library) path and will mess with unrelated MSYS2 installations (e.g. microsoft/vcpkg#9427).

[eine]

@jtanx, thanks a lot for that so valuable hint! I will test it in https://github.com/eine/setup-msys2/blob/master/main.js#L62-L63

This seems like a good solution to me. What about we run this at the end of every core update? (with confirmation in the tty case)

@lazka, I'd be willing to help test such an approach by contributing a GitHub Actions workflow. However, given the volume of repos and packages, I'd need some guidance.

[lazka]

@emptyVoid what about something like echo "taskkill /f$(for pid in $(cat /proc/*/winpid); do echo -n " /pid $pid"; done)" -> taskkill /f /pid 4084 /pid 5532 /pid 9272 /pid 9000 /pid 8476

[emptyVoid]

Looks good, going to try it out.
I guess you are planning to filter out the terminal's process, otherwise it would be a bit confusing for the user if gets suddenly closed.

[lazka]

I guess you are planning to filter out the terminal's process, otherwise it would be a bit confusing for the user if gets suddenly closed.

I was thinking about something like

:: To complete the update all MSYS2 processes including this terminal need to be closed. Confirm to proceed [Y/n]

[emptyVoid]

What about scripted installations -- will MSYS2 processes be auto-closed with --noconfirm?

[lazka]

What about scripted installations -- will MSYS2 processes be auto-closed with --noconfirm?

sure. I still need to figure out how to make those cases not report a non-error exit status. Maybe skip pacman itself and the parent process if it is a bash and we are noconfirm.

edit: SIGTERM and finally taskkill seems to do the trick
edit2: somehow not needed if I skip the calling process, shrug

[lazka]

core packges are .xz again now and pacman will autokill all msys packages on a runtime update.

I'll release a new installer later today which includes the new pacman version.

[gwilku]

Still not solved...