pacman -Syu Does Nothing
waynehamberg opened this issue · comments
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
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 ~
$
pacman also locks the database regardless of what I do.
Make sure there is no pacman process running and then remove lockfile: rm -f /var/lib/pacman/db.lck.
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
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.
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 thanmsys2-x86_64-20180531.exe - use
pacman -Syu --ignore pacmanrather thanpacman -Syu(givingwarning: pacman: ignoring package upgrade (5.0.1-1 => 5.1.0-4)) - use
pacman -Su --ignore pacman --forcerather thanpacman -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.
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.
@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.
For completeness, on my Windows 10 machine, I have not had any problem with msys2-x86_64-20180531.exe.
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.
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!
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:
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....).
A brief update, using Piscium work around actually worked for me too, so at least I have something to work with now.
B
Some tools are targeted by antivirus or anti-malware software, gnupg for example.
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
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.
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
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.
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.
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.
I have win 8.1, The problem is still occuring
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.
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.
Garbage software
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.
If you installed in the default location
c:\msys64the permissions are likely open. But if you installed underC:\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!
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.
@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.
What worked for me was just running as administrator
"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.
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.
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.
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.
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
If you installed in the default location
c:\msys64the permissions are likely open. But if you installed underC:\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!