Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

pacman -Syu Does Nothing #1298

Closed
waynehamberg opened this issue Jun 13, 2018 · 39 comments
Closed

pacman -Syu Does Nothing #1298

waynehamberg opened this issue Jun 13, 2018 · 39 comments
Labels
external Issues caused by external software or project

Comments

@waynehamberg
Copy link

Hi Everybody,

I am trying to install Netbeans C++ on a new machine and I've done this several times in the past without issue however when I attempt to do it today "pacman -Syu" or "pacman -Su" do absolutely nothing. I have followed the instructions for installing MSYS2 (I've tried 32 and 64 bit versions) as specified on the following webpage (https://www.msys2.org/)

What's the problem?

Wayne
@waynehamberg
Copy link
Author

whamberg@USSA1LPJJF3CS1 MSYS ~
$ pacman -Syu
:: Synchronizing package databases...

whamberg@USSA1LPJJF3CS1 MSYS ~
$ pacman -Su
error: failed to init transaction (unable to lock database)
error: could not lock database: File exists
if you're sure a package manager is not already
running, you can remove /var/lib/pacman/db.lck

whamberg@USSA1LPJJF3CS1 MSYS ~
$

@waynehamberg
Copy link
Author

pacman also locks the database regardless of what I do.

@mati865
Copy link
Collaborator

mati865 commented Jun 14, 2018

Make sure there is no pacman process running and then remove lockfile: rm -f /var/lib/pacman/db.lck.

@waynehamberg
Copy link
Author

waynehamberg commented Jun 14, 2018 via email

@mati865
Copy link
Collaborator

mati865 commented Jun 14, 2018 via email

@eminence
Copy link

I am seeing this same problem. pacman from msys2-x86_64-20161025.exe works OK, but after upgrading to the latest (via pacman -Syu), I see the same thing that @waynehamberg is reporting -- running pacman Syu prints "Synchronizing package databases..." but then nothing else

@mpilgrem
Copy link

mpilgrem commented Jul 19, 2018 •
edited
Loading

I have the exact same problem on Windows 7 following a restart and a clean, accept-all-defaults install of msys2-x86_64-20180531.exe from https://www.msys2.org/. An earlier version of MSYS2 used to work (cannot say what version, though). EDIT: I also have the same experience as @eminence with msys2-x86_64-20161025.exe: once pacman upgrades, it is broken.

@mpilgrem
Copy link

The following seems to be a work-around to my problems:

  • install msys2-x86_64-20161025.exe (from http://repo.msys2.org/distrib/x86_64/) rather than msys2-x86_64-20180531.exe
  • use pacman -Syu --ignore pacman rather than pacman -Syu (giving warning: pacman: ignoring package upgrade (5.0.1-1 => 5.1.0-4))
  • use pacman -Su --ignore pacman --force rather than pacman -Su

The --force option above appears to be required to avoid this error:

error: failed to commit transaction (conflicting files)
coreutils: /usr/lib/coreutils/libstdbuf.so exists in filesystem
Errors occurred, no packages were upgraded.

See #1024.

@StarWolf3000
Copy link
Contributor

Yes, because of how pacman does version comparison.

But recently I did a clean install on another system using msys2-x86_64-20180531.exe and did a pacman -Syyuu (override database and full system upgrade), and it worked fine, no errors.

@mpilgrem
Copy link

@StarWolf3000, on my Windows 7 machine, a clean install of msys2-x86_64-20180531.exe followed by pacman -Syyuu is no cure, because the version of pacman that comes with it seems to be the one exhibiting the problem experienced by @waynehamberg and me.

@waynehamberg
Copy link
Author

waynehamberg commented Jul 20, 2018 via email

@mpilgrem
Copy link

For completeness, on my Windows 10 machine, I have not had any problem with msys2-x86_64-20180531.exe.

@StarWolf3000
Copy link
Contributor

I did a reinstall on Windows 8.1 and 10, both successful. Maybe there really is something on Windows 7 that prevents pacman to do anything.

@Piscium
Copy link

Piscium commented Aug 2, 2018

I have the same issue as in the first post as waynehamberg on Windows 7, but on Windows 10 in another machine all is fine (as mpilgrem reports).

I found a workaround for Windows 7 which worked for me, which is to edit /etc/pacman.conf and uncomment the following line:
XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u

I found the workaround above in this comment:
#1022 (comment)

However then I ran into another problem when running "pacman -Syu" whereby updating gnupg fails because the gpg-agent cannot connect. The workaround for this other issue is to disable update of the gnupg package by modifying pacman.conf as follows:

IgnorePkg = gnupg

Of course the above is a temporary workaround!

@bernhardcl
Copy link

Any working solution to this on Windows 7? I am struggling to get a working shell again. Installation of the msys2-x86_64-20161025.exe doesnt work either:
image

BTW often failed installations of msys2-x86_64-20180531.exe remove the installer from the directory and lock it. All very odd. After failing for almost a day I am desperate to get a working msys2 going again (note the old installation got completely corrupted up an update....).

@bernhardcl
Copy link

A brief update, using Piscium work around actually worked for me too, so at least I have something to work with now.
B

@StarWolf3000
Copy link
Contributor

Some tools are targeted by antivirus or anti-malware software, gnupg for example.

@YBDecawave
Copy link

Hi guys,

I've the same issue on Windows 10 with the following version of msys2 : msys2-x86_64-20180531.exe

Any update regarding a potential fix ?

Thanks
Yves

@fandjelo
Copy link

fandjelo commented Mar 7, 2019

Same problem here, pacman crashes trying to download anything leaving the lock file there. I'm running Windows 10. The workaround posted by @Piscium works. Just tell pacman to use wget instead of internal downloader.

@vnluc
Copy link

vnluc commented Dec 20, 2019 •
edited
Loading

I got same issue with msys2-base-x86_64-20181211.tar.xz. I install on Windows 10.

Actually it success the first time, from 2nd time it always fails:

:: Synchronising package databases...
error: failed to update mingw32 (unable to lock database)
error: failed to update mingw64 (unable to lock database)
error: failed to update msys (unable to lock database)
error: failed to synchronize all databases

@darrencl darrencl mentioned this issue Feb 14, 2020
Closed
@nift4
Copy link

nift4 commented May 25, 2020

I got same issue with msys2-base-x86_64-20181211.tar.xz. I install on Windows 10.

Actually it success the first time, from 2nd time it always fails:

:: Synchronising package databases...
error: failed to update mingw32 (unable to lock database)
error: failed to update mingw64 (unable to lock database)
error: failed to update msys (unable to lock database)
error: failed to synchronize all databases

Same issue. Did you got any solution? I used 20200522 installer.

@elieux
Copy link
Member

elieux commented May 25, 2020

Try using pacman -Sy --debug -vvv. If that doesn't say anything interesting, try strace or procmon to find out what exactly is wrong with the locking.

@waynehamberg
Copy link
Author

waynehamberg commented May 25, 2020 via email

@nift4
Copy link

nift4 commented May 26, 2020

Try using pacman -Sy --debug -vvv. If that doesn't say anything interesting, try strace or procmon to find out what exactly is wrong with the locking.

Sorry, but after hours of struggling with this issue I just installed Cygwin.

@ecentell-CPF ecentell-CPF mentioned this issue Jun 8, 2020
Closed
@humza-uddin
Copy link

I have win 8.1, The problem is still occuring

@juhavlintula
Copy link

Have you tried to run it as Admin? I got the same error, when I was running the command in a standard window, but when I started MSYS2 as admin, I didn't have any problems.

@TokisanGames
Copy link

If you installed in the default location c:\msys64 the permissions are likely open. But if you installed under C:\Program Files, write permissions are restricted to admins. Edit the file security on the folder and add your user account to enable Modify permissions. Or run as admin. Or reinstall into a different directory that doesn't restrict to admin access.

@vichvich4444

This comment has been minimized.

Sign in to view
@naine
Copy link

naine commented Oct 19, 2020 •
edited
Loading

Try using pacman -Sy --debug -vvv. If that doesn't say anything interesting, try strace or procmon to find out what exactly is wrong with the locking.

It is not an issue with the locking. It appears as such on retry, because after first attempt pacman leaves the lock file on the disk, thus subsequent attempts refuse to lock.

$ rm -f /var/lib/pacman/db.lck && pacman -Syuu --debug -vvv
debug: pacman v5.2.2 - libalpm v12.0.2
debug: config: attempting to read file /etc/pacman.conf
debug: config: new section 'options'
debug: config: HoldPkg: pacman
debug: config: arch: x86_64
debug: config: SigLevel: Required
debug: config: SigLevel: DatabaseOptional
debug: config: LocalFileSigLevel: Optional
debug: config: new section 'mingw32'
debug: config file /etc/pacman.conf, line 72: including /etc/pacman.d/mirrorlist.mingw32
debug: config: new section 'mingw64'
debug: config file /etc/pacman.conf, line 75: including /etc/pacman.d/mirrorlist.mingw64
debug: config: new section 'msys'
debug: config file /etc/pacman.conf, line 78: including /etc/pacman.d/mirrorlist.msys
debug: config: finished parsing /etc/pacman.conf
debug: setup_libalpm called
debug: option 'logfile' = /var/log/pacman.log
debug: option 'gpgdir' = /etc/pacman.d/gnupg/
debug: option 'hookdir' = /etc/pacman.d/hooks/
debug: option 'cachedir' = /var/cache/pacman/pkg/
debug: registering sync database 'mingw32'
debug: database path for tree mingw32 set to /var/lib/pacman/sync/mingw32.db
debug: GPGME version: 1.14.0-unknown
debug: GPGME engine info: file=/usr/bin/gpg, home=/etc/pacman.d/gnupg/
debug: checking signature for /var/lib/pacman/sync/mingw32.db
debug: 1 signatures returned
debug: fingerprint: 4A6129F4E4B84AE46ED7F635628F528CF3053E04
debug: summary: valid
debug: summary: green
debug: status: Success
debug: timestamp: 1599152759
debug: exp_timestamp: 0
debug: validity: full; reason: Success
debug: key: 87771331B3F1FF5263856A6D974C8BE49078F532, David Macek <david.macek.0@gmail.com>, owner_trust unknown, disabled 0
debug: signature is valid
debug: signature is fully trusted
debug: setting usage of 15 for mingw32 repository
debug: adding new server URL to database 'mingw32': http://repo.msys2.org/mingw/i686
debug: adding new server URL to database 'mingw32': https://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686
debug: adding new server URL to database 'mingw32': https://www2.futureware.at/~nickoe/msys2-mirror/mingw/i686
debug: adding new server URL to database 'mingw32': https://mirror.yandex.ru/mirrors/msys2/mingw/i686
debug: adding new server URL to database 'mingw32': https://mirrors.tuna.tsinghua.edu.cn/msys2/mingw/i686
debug: adding new server URL to database 'mingw32': http://mirrors.ustc.edu.cn/msys2/mingw/i686
debug: adding new server URL to database 'mingw32': http://mirror.bit.edu.cn/msys2/mingw/i686
debug: adding new server URL to database 'mingw32': https://mirror.selfnet.de/msys2/mingw/i686
debug: registering sync database 'mingw64'
debug: database path for tree mingw64 set to /var/lib/pacman/sync/mingw64.db
debug: checking signature for /var/lib/pacman/sync/mingw64.db
debug: 1 signatures returned
debug: fingerprint: 4A6129F4E4B84AE46ED7F635628F528CF3053E04
debug: summary: valid
debug: summary: green
debug: status: Success
debug: timestamp: 1599152750
debug: exp_timestamp: 0
debug: validity: full; reason: Success
debug: key: 87771331B3F1FF5263856A6D974C8BE49078F532, David Macek <david.macek.0@gmail.com>, owner_trust unknown, disabled 0
debug: signature is valid
debug: signature is fully trusted
debug: setting usage of 15 for mingw64 repository
debug: adding new server URL to database 'mingw64': http://repo.msys2.org/mingw/x86_64
debug: adding new server URL to database 'mingw64': https://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64
debug: adding new server URL to database 'mingw64': https://www2.futureware.at/~nickoe/msys2-mirror/mingw/x86_64
debug: adding new server URL to database 'mingw64': https://mirror.yandex.ru/mirrors/msys2/mingw/x86_64
debug: adding new server URL to database 'mingw64': https://mirrors.tuna.tsinghua.edu.cn/msys2/mingw/x86_64
debug: adding new server URL to database 'mingw64': http://mirrors.ustc.edu.cn/msys2/mingw/x86_64
debug: adding new server URL to database 'mingw64': http://mirror.bit.edu.cn/msys2/mingw/x86_64
debug: adding new server URL to database 'mingw64': https://mirror.selfnet.de/msys2/mingw/x86_64
debug: registering sync database 'msys'
debug: database path for tree msys set to /var/lib/pacman/sync/msys.db
debug: checking signature for /var/lib/pacman/sync/msys.db
debug: 1 signatures returned
debug: fingerprint: 4A6129F4E4B84AE46ED7F635628F528CF3053E04
debug: summary: valid
debug: summary: green
debug: status: Success
debug: timestamp: 1599152769
debug: exp_timestamp: 0
debug: validity: full; reason: Success
debug: key: 87771331B3F1FF5263856A6D974C8BE49078F532, David Macek <david.macek.0@gmail.com>, owner_trust unknown, disabled 0
debug: signature is valid
debug: signature is fully trusted
debug: setting usage of 15 for msys repository
debug: adding new server URL to database 'msys': http://repo.msys2.org/msys/x86_64
debug: adding new server URL to database 'msys': https://sourceforge.net/projects/msys2/files/REPOS/MSYS2/x86_64
debug: adding new server URL to database 'msys': https://www2.futureware.at/~nickoe/msys2-mirror/msys/x86_64
debug: adding new server URL to database 'msys': https://mirror.yandex.ru/mirrors/msys2/msys/x86_64
debug: adding new server URL to database 'msys': https://mirrors.tuna.tsinghua.edu.cn/msys2/msys/x86_64
debug: adding new server URL to database 'msys': http://mirrors.ustc.edu.cn/msys2/msys/x86_64
debug: adding new server URL to database 'msys': http://mirror.bit.edu.cn/msys2/msys/x86_64
debug: adding new server URL to database 'msys': https://mirror.selfnet.de/msys2/msys/x86_64
Root      : /
Conf File : /etc/pacman.conf
DB Path   : /var/lib/pacman/
Cache Dirs: /var/cache/pacman/pkg/
Hook Dirs : /usr/share/libalpm/hooks/  /etc/pacman.d/hooks/
Lock File : /var/lib/pacman/db.lck
Log File  : /var/log/pacman.log
GPG Dir   : /etc/pacman.d/gnupg/
Targets   : None
:: Synchronising package databases...
debug: url: http://repo.msys2.org/mingw/i686/mingw32.db
debug: maxsize: 134217728
debug: using time condition: 1599152757
debug: opened tempfile for download: /var/lib/pacman/sync/mingw32.db.part (wb)

Pacman exits immediately after opening mingw32.db.part, this file is left on the disk at 0 bytes. db.lck is also left on the disk.

Above is from fresh install using msys2-x86_64-20200903.exe on win10.

@ghost
Copy link

ghost commented Feb 6, 2021

If you installed in the default location c:\msys64 the permissions are likely open. But if you installed under C:\Program Files, write permissions are restricted to admins. Edit the file security on the folder and add your user account to enable Modify permissions. Or run as admin. Or reinstall into a different directory that doesn't restrict to admin access.

This was exactly my case. Thanks!

@Jillinger
Copy link

Jillinger commented Mar 5, 2021 •
edited
Loading

This probably has been solved by now, but just in case... I got a message, to remove the db.lck file in the pacman directory, if no package manager is running. Deleting that file solved the problem.

@naine
Copy link

naine commented Mar 5, 2021 •
edited
Loading

@Jillinger This hasn't been solved, and a leftover db.lck is a symptom of the problem, not the cause. Your issue was probably different.

@That-Human-Being
Copy link

What worked for me was just running as administrator

@phmikas
Copy link

phmikas commented Sep 13, 2021

"What worked for me was just running as administrator" - Same for me!! Why isn't that mentioned on the msys2 installation guide??!! Would save hours of pointless trying for so many users.

@Biswa96
Copy link
Member

Biswa96 commented Sep 13, 2021

msys2 does NOT require administrative permission. There may be something is blocking the pacman process, most of the time it is crappy antivirus software include M$ Windows Defender.

@naine
Copy link

naine commented Sep 13, 2021 •
edited
Loading

Why isn't that mentioned on the msys2 installation guide??!!

Because if you install in the default location, you should not ever need to do this. In fact if you don't have write permission to the msys root then you probably have bigger issues not limited to pacman.

For what it's worth, when I was experiencing this, I did try running as administrator and it made no difference.

@bilditup1
Copy link

One thing that could interfere with this is Windows' ransomware protection, if it's on and you've added your msys2 folder or its parent to the list of folders to be protected. If you do this you need to manually whitelist each app that is allowed to modify that location even if the app being run is itself stored within that protected folder.

@ghost
Copy link

ghost commented Feb 14, 2022

whamberg@USSA1LPJJF3CS1 MSYS ~ $ pacman -Syu :: Đồng bộ hóa cơ sở dữ liệu gói ...

whamberg@USSA1LPJJF3CS1 lỗi MSYS ~ $ pacman -Su: lỗi không thành công (không thể khóa cơ sở dữ liệu): không thể khóa cơ sở dữ liệu: Tệp tồn tại nếu bạn chắc chắn trình quản lý gói chưa chạy, bạn có thể loại bỏ / var / lib / pacman / db.lck

whamberg@USSA1LPJJF3CS1 MSYS ~ $

tôi chạy trên vai trò quản trị viên là thành công

@BerezkovN
Copy link

If you installed in the default location c:\msys64 the permissions are likely open. But if you installed under C:\Program Files, write permissions are restricted to admins. Edit the file security on the folder and add your user account to enable Modify permissions. Or run as admin. Or reinstall into a different directory that doesn't restrict to admin access.

This worked. Replying for more people to see!

@Biswa96 Biswa96 added the external Issues caused by external software or project label Apr 27, 2023
@Biswa96 Biswa96 closed this as completed Apr 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
external Issues caused by external software or project
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix initial upgrade on Windows