You are not logged in.
EDIT
2018-05-29: Solved. Error caused by symlinking to /var/cache/pacman* in place of using pacman conf file (as I definitively should have done :~)
/EDIT
Just to let you know, pacman binary _and_ pkg cache disapeared today after I booted my desktop, played Steam a bit then run pacman through yaourt:
$ LANG=en_US.UTF-8 yaourt -Syu
...
==> Package upgrade only (new release):
core/pacman 5.0.2-2 2 -> 3
==> Software upgrade (new version) :
core/dhcpcd 7.0.1-1 -> 7.0.4-1
core/file 5.32-1 -> 5.33-1
core/libidn 1.33-2 -> 1.34-2
extra/libwbclient 4.8.0-2 -> 4.8.1-1
extra/libzip 1.5.0-1 -> 1.5.1-1
extra/smbclient 4.8.0-2 -> 4.8.1-1
...
(5/7) upgrading libzip [------------------------------------------------------------------------------------------------------------------------] 100%
error: could not open file /var/cache/pacman/pkg/pacman-5.0.2-3-x86_64.pkg.tar.xz: No such file or directory
error: could not commit transaction
error: failed to commit transaction (transaction aborted)
Errors occurred, no packages were upgraded.
package-query: error while loading shared libraries: libalpm.so.10: cannot open shared object file: No such file or directory
/usr/lib/yaourt/misc.sh: line 33: /usr/bin/pacman: No such file or directory
# pacman -Syyu
pacman: command not found
At this point /var/cache/pacman/pkg/ had been emptied.
tail /var/log/pacman.log
[2018-05-03 14:55] [PACMAN] Running 'pacman --color auto -Sy'
[2018-05-03 14:55] [PACMAN] synchronizing package lists
[2018-05-03 14:55] [PACMAN] Running 'pacman --color auto -S -u'
[2018-05-03 14:55] [PACMAN] starting full system upgrade
[2018-05-03 14:55] [ALPM] transaction started
[2018-05-03 14:55] [ALPM] upgraded libidn (1.33-2 -> 1.34-2)
[2018-05-03 14:55] [ALPM] upgraded dhcpcd (7.0.1-1 -> 7.0.4-1)
[2018-05-03 14:55] [ALPM] upgraded file (5.32-1 -> 5.33-1)
[2018-05-03 14:55] [ALPM] upgraded libwbclient (4.8.0-2 -> 4.8.1-1)
[2018-05-03 14:55] [ALPM] upgraded libzip (1.5.0-1 -> 1.5.1-1)
[2018-05-03 14:55] [ALPM] transaction failed
I adapted yochaigal post in sticky thread on top of this forum to [bold]reinstall pacman[/bold]:
wget http://mirror.rit.edu/archlinux/core/os/x86_64/pacman-5.0.2-3-x86_64.pkg.tar.xz
sudo tar -xJf pacman-5.0.2-3-x86_64.pkg.tar.xz -C / --exclude .PKGINFO --exclude .INSTALL
That did the job:
$ LANG=en_US pacman -Qi pacman
error: could not open file /var/lib/pacman/local/pacman-5.0.2-3/desc: No such file or directory
Name : pacman
Version : 5.0.2-3
Description : None
...
All seems good (I just updated smbclient and unison) now. Never seen that happening up to now I think.
Last edited by kozaki (2018-05-29 15:09:48)
Seeded last month: Arch 50 gig, derivatives 1 gig
Desktop @3.3GHz 8 gig RAM, linux-ck
laptop #1 Atom 2 gig RAM, Arch linux stock i686 (6H w/ 6yrs old battery ) #2: ARM Tegra K1, 4 gig RAM, ChrOS
Atom Z520 2 gig RAM, OMV (Debian 7) kernel 3.16 bpo on SDHC | PGP Key: 0xFF0157D9
Offline
So is there a question, or why is this here?
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Looks like disk/filesystem problems.
Offline
Somehow, even though pacman correctly verified the new pacman version was correctly downloaded and available before beginning the upgrade, the cached package disappeared halfway through, before it could be used.
error: could not open file /var/cache/pacman/pkg/pacman-5.0.2-3-x86_64.pkg.tar.xz: No such file or directory
You should find out why this happened. Either your hard drive is dying/corrupted or some root process is sneakily deleting your files for giggles...
Last edited by eschwartz (2018-05-03 14:34:04)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
You should find out why this happened. Either your hard drive is dying/corrupted or some root process is sneakily deleting your files for giggles...
Did you maybe create a paccache cron/systemd timer (bad idea) that was started while pacman was running?
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Is there a question, or why is this there?
Fair enough Trilby, I didn't specify this. Well, it's big enough, and I have myself _no_ clue or its shadow about how/why it happened. Out of luck I thought there might be a mechanism in pacman 5.0.2-2/3 that I ignore and may have caused the pkg cache disappears. In such cases I tend to share with other users, brains and eyes.
Somehow, even though pacman correctly verified the new pacman version was correctly downloaded and available before beginning the upgrade, the cached package disappeared halfway through, before it could be used.
Exactly.
@progandy: I have discounted the Disk/filesystem as a possible cause though please feel free to criticize or suggest otherwise:
Binaries and cache lie on two different LVM volumes using plain ext4 fs on this desktop. Binaries are on a SanDisk SSD, and caches on a Hitachi spinning drive (Deskstar T7K500). AFAIK the probability of both to fail at the same time is quite low. Specifically to make the both pacman binary and the entire-and-only pkgs cache to disapear entirely when upgrading pacman.
Also their S.M.A.R.T. attributes are fine; e.g. all of Program_Fail_Count, Erase_Fail_Count, Reported_Uncorrect,, ECC_Uncorr_Error_Count, Unc_Soft_Read_Err_Rate and Soft_ECC_Correct_Rate attributes are at "Failed: never" (raw value: zero) for the SSD.
In journalctl I can see no "bizarre" line at the time (14:55:33) when I launched the system update.
EDIT: I have absolutely no automated pkg cache cleaning. I do run `paccache -k 2 -r` from time to time though; last time was yesterday evening but all went as fine as usual.
Last edited by kozaki (2018-05-03 16:56:56)
Seeded last month: Arch 50 gig, derivatives 1 gig
Desktop @3.3GHz 8 gig RAM, linux-ck
laptop #1 Atom 2 gig RAM, Arch linux stock i686 (6H w/ 6yrs old battery ) #2: ARM Tegra K1, 4 gig RAM, ChrOS
Atom Z520 2 gig RAM, OMV (Debian 7) kernel 3.16 bpo on SDHC | PGP Key: 0xFF0157D9
Offline
Same thing for me just now:
$trizen -Syu
:: Synchronizing package databases...
core 129.8 KiB 630K/s 00:00 [######################] 100%
extra 1597.8 KiB 3.72M/s 00:00 [################################################] 100%
community 4.3 MiB 7.81M/s 00:01 [######################################################] 100%
multilib is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
Packages (9) dhcpcd-7.0.4-1 file-5.33-1 libidn-1.34-2 libwbclient-4.8.1-1 libzip-1.5.1-1 pacman-5.0.2-3 qtcreator-4.6.1-1 samba-4.8.1-1
smbclient-4.8.1-1
Total Installed Size: 202.63 MiB
Net Upgrade Size: -0.54 MiB
:: Proceed with installation? [Y/n]
(9/9) checking keys in keyring [######################################################] 100%
(9/9) checking package integrity [######################################################] 100%
(9/9) loading package files [######################################################] 100%
(9/9) checking for file conflicts [######################################################] 100%
(9/9) checking available disk space [######################################################] 100%
:: Processing package changes...
(1/9) upgrading libidn [######################################################] 100%
(2/9) upgrading dhcpcd [######################################################] 100%
(3/9) upgrading file [######################################################] 100%
(4/9) upgrading libwbclient [######################################################] 100%
(5/9) upgrading libzip [######################################################] 100%
error: could not open file /var/cache/pacman/pkg/pacman-5.0.2-3-x86_64.pkg.tar.xz: No such file or directory
error: could not commit transaction
error: failed to commit transaction (transaction aborted)
Errors occurred, no packages were upgraded.
I blame libzip
Last edited by jazztickets (2018-05-03 18:50:56)
Offline
I blame libzip
I think that's unfair, pacman doesn't use libzip. libidn2 is a more likely suspect, since pacman indirectly depends on it (libalpm.so.10 => libcurl.so.4 => libidn2.so.0), but 1) there wasn't a soname bump, 2) the soname would've been loaded onto the disk cache at the start of the transaction anyway, and 3) a temporary loss of a soname shouldn't result in an empty /var/cache/pacman/pkg directory.
I note you both used AUR helpers to perform this system update. Whereas I used pacman, and encountered no issues. There may be something to that, or it may just be bad luck.
If either of you is in a position where you need to fix pacman, then see https://bbs.archlinux.org/viewtopic.php?id=95007.
Note that this link is very, very outdated. You should read the advice within with the intent of learning how to fix pacman, and not looking for a list of commands to copy-paste.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
FWIW I just did the update with yaourt for shits and giggles half prepared for breakage, but nothing happened either.
Which makes this a very odd occurence, do both of you use LVM? No coredumps or some other indication something horribly crashed?
Offline
Yeah, quite an odd occurrence indeed. @V1del just to be sure, by « nothing happened » you mean nothing *odd* happened during your system update, correct?
WorMzy yes thanx. This is the post I used to reinstall pacman. Just had to adapt it slightly for pacman-5.0.2-3 as quoted above.
The packages that were to be updated today in this location, when pacman binary and cache suddenly disappeared:
core/pacman * 5.0.2-2 2 -> 3
core/dhcpcd * 7.0.1-1 -> 7.0.4-1
core/file * 5.32-1 -> 5.33-1
core/libidn * 1.33-2 -> 1.34-2
extra/libwbclient * 4.8.0-2 -> 4.8.1-1
extra/libzip * 1.5.0-1 -> 1.5.1-1
extra/smbclient 4.8.0-2 -> 4.8.1-1
(*) It look just like these in jazztickets' location, smbclient excepted.
Seeded last month: Arch 50 gig, derivatives 1 gig
Desktop @3.3GHz 8 gig RAM, linux-ck
laptop #1 Atom 2 gig RAM, Arch linux stock i686 (6H w/ 6yrs old battery ) #2: ARM Tegra K1, 4 gig RAM, ChrOS
Atom Z520 2 gig RAM, OMV (Debian 7) kernel 3.16 bpo on SDHC | PGP Key: 0xFF0157D9
Offline
@kozaki did you have a symlink to /var/cache/pacman/pkg on another drive like i did?
This explains it: https://redd.it/8h2r0j
Offline
Bad idea all around. Never, EVER replace dirs managed by pacman with a symlink.
Offline
I was affected by exactly the same issue. Found this thread thanks to #archlinux on IRC.
- Just a regular "pacman -Syu"
- No AUR helper, no "--force"
- No alias for the "pacman" command
- I had the /var/cache/pacman directory symlinked to a different disk
- No indication of any disk failure
Here's the log from the upgrade:
(30/51) upgrading mpc [###########] 100%
(31/51) upgrading nano [###########] 100%
(32/51) upgrading nvidia [###########] 100%
error: could not open file /var/cache/pacman/pkg/pacman-5.0.2-3-x86_64.pkg.tar.xz: No such file or directory
error: could not commit transaction
error: failed to commit transaction (transaction aborted)
Errors occurred, no packages were upgraded.
$ pacman
bash: pacman: command not found
I could recover pacman by using the instructions from the Reddit post (had to use --force for the first "pacman -S pacman" invocation though).
Maybe pacman could try to detect that the cache is symlinked, and warn that it's a bad idea?
"Freedom is the freedom to say that two plus two make four. If that is granted, all else follows." - George Orwell
Offline
It's not just the cache dir, it's any dir managed by pacman at all. Just don't do it.
There's configuration options for pacman to move the cache, or you can use mounts/bind mounts for other things. Using a symlink like this is just asking for trouble.
Last edited by Scimmia (2018-05-05 22:11:30)
Offline
I also had this issue, regular pacman, no symlink either.
Offline
I also had that problem. I did a regular yaourt -Syu and the transaction failed midway, leaving me unable to boot because the update included a kernel update. I managed to restore my system using an arch boot stick and running yaourt -Syu again in an arch-chroot, but every time I use pacman now, I get this error: could not open file /var/lib/pacman/local/pacman-5.0.2-3/desc: No such file or directory
Transactions do still work except for when I try to reinstall pacman.
# pacman -S pacman
warning: pacman-5.0.2-3 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
error: could not open file /var/lib/pacman/local/pacman-5.0.2-3/desc: No such file or directory
warning: could not fully load metadata for package pacman-5.0.2-3
error: failed to prepare transaction (invalid or corrupted package)
I removed the pacman package from my package cache to force a redownload, but pacman doesn't even attempt to download the package. The error is thrown right away. The error also occurs when I use --force or when I try to downgrade to an older version of pacman. How do I get this to work again?
Offline
Rapti: Just do "touch /var/lib/pacman/local/pacman-5.0.2-3/desc" and then install and reinstall pacman.
"Freedom is the freedom to say that two plus two make four. If that is granted, all else follows." - George Orwell
Offline
After I did that, I got a similar error about pacman-5.0.2-3/files not being found. Touched that too and now everything works. Thanks!
Offline
I also had that problem. I did a regular yaourt -Syu and the transaction failed midway,
Why and how did it fail, though?
I know a few people have had pacman error in the middle of upgrading pacman, because they exceedingly unwisely turned /var/cache/pacman/pkg into a symlink and pacman deleted the symlink when upgrading the pacman package itself, then was unable to extract the contents of the pacman package.
If this was the case, use pacman.conf's CacheDir properly. Otherwise you'll keep getting these errors every time pacman updates.
Last edited by eschwartz (2018-05-15 15:36:52)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
I'm not completely sure. I've been in a hurry, so I didn't pay much attention and I didn't get home for half a week afterwards. I did use a symlink for the cache dir though, so the scenario you just described is probably what happened to me. I'm already using the CacheDir property by now.
Offline
Edit ... On second read...
I did use a symlink for the cache dir though, so the scenario you just described is probably what happened to me.
Yeah, same here. /var/cache/pacman -> /mnt/stuff/var-cache-pacman. I did this years ago and completely forgot about it. "/mnt/stuff" is my raid array.
Last edited by bobpaul (2018-05-17 04:39:26)
Offline
is not pacman upgraded along with the upgrade system?
if your pacman disappears. how yaourt still work?
Offline
Of course it is, why else would this thread exist... stating that some people had a corrupted *pacman* update?
No, it won't work either. Did anyone imply it might?
...
Why did you think either answer might be different? I thought the former answer was obvious by this point, and the latter is not really related to this thread.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
@kozaki did you have a symlink to /var/cache/pacman/pkg on another drive like i did?
This explains it: https://www.reddit.com/r/archlinux/comm … npkg_as_a/
It's not just the cache dir, it's any dir managed by pacman at all. Just don't do it.
There's configuration options for pacman to move the cache, or you can use mounts/bind mounts for other things. Using a symlink like this is just asking for trouble.
I did have a symlink to /var/cache/pacman/pkg on another drive as well.
I'm very glad you guys thought/searched further and found *da* explanation behind that.
So, I just upgraded pacman (can't remember using the dreaded '--force' option before); replaced pacman conf file with that of pacman-5.1.0-1 then edited it appropriately this time.
Lesson learned here, thank you guys & lads
Seeded last month: Arch 50 gig, derivatives 1 gig
Desktop @3.3GHz 8 gig RAM, linux-ck
laptop #1 Atom 2 gig RAM, Arch linux stock i686 (6H w/ 6yrs old battery ) #2: ARM Tegra K1, 4 gig RAM, ChrOS
Atom Z520 2 gig RAM, OMV (Debian 7) kernel 3.16 bpo on SDHC | PGP Key: 0xFF0157D9
Offline
I am also affected,
shouldn't be warning at the first page (to read it before upgrade) in
Latest News?
Thanks
Offline