You are not logged in.
- Topics: Active | Unanswered
#1 2021-04-21 18:47:04
- SRG
- Member
- Registered: 2012-12-09
- Posts: 69
No more pacman binary after error during pacman upgrade
I was upgrading my system.
I got an error during the update - sadly, pacman itself was supposed to be upgrade.
So it has been removed, then the update has failed, and now i don't have any pacman installed anymore ...
How can i recover this situation ?
Thanks in advance.
Log of failure :
:: Synchronizing package databases...
core 131.5 KiB 3.89 MiB/s 00:00 [#####################################################################################################] 100%
extra 1607.3 KiB 29.6 MiB/s 00:00 [#####################################################################################################] 100%
community 5.5 MiB 47.2 MiB/s 00:00 [#####################################################################################################] 100%
multilib is up to date
archlinuxfr is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...Packages (11) avahi-0.8+20+gd1e71b3-1 dbus-glib-0.112-1 gnome-online-accounts-3.40.0-1 graphicsmagick-1.3.36-2 less-1:581-1 libmm-glib-1.16.4-1 linux-lts-5.10.32-1 linux-lts-headers-5.10.32-1 pacman-5.2.2-3 qt5-base-5.15.2+kde+r177-1 sqlite-3.35.5-1
Total Download Size: 117.01 MiB
Total Installed Size: 312.06 MiB
Net Upgrade Size: 0.05 MiB:: Proceed with installation? [Y/n]
:: Retrieving packages...
sqlite-3.35.5-1-x86_64 1748.4 KiB 22.2 MiB/s 00:00 [#####################################################################################################] 100%
less-1:581-1-x86_64 114.2 KiB 11.2 MiB/s 00:00 [#####################################################################################################] 100%
linux-lts-5.10.32-1-x86_64 74.6 MiB 11.8 MiB/s 00:06 [#####################################################################################################] 100%
linux-lts-headers-5.10.32-1-x86_64 22.9 MiB 12.4 MiB/s 00:02 [#####################################################################################################] 100%
pacman-5.2.2-3-x86_64 838.6 KiB 17.4 MiB/s 00:00 [#####################################################################################################] 100%
avahi-0.8+20+gd1e71b3-1-x86_64 437.0 KiB 18.6 MiB/s 00:00 [#####################################################################################################] 100%
dbus-glib-0.112-1-x86_64 130.0 KiB 0.00 B/s 00:00 [#####################################################################################################] 100%
gnome-online-accounts-3.40.0-1-x86_64 590.1 KiB 17.5 MiB/s 00:00 [#####################################################################################################] 100%
graphicsmagick-1.3.36-2-x86_64 2.4 MiB 12.6 MiB/s 00:00 [#####################################################################################################] 100%
libmm-glib-1.16.4-1-x86_64 446.5 KiB 10.1 MiB/s 00:00 [#####################################################################################################] 100%
qt5-base-5.15.2+kde+r177-1-x86_64 12.9 MiB 8.08 MiB/s 00:02 [#####################################################################################################] 100%
(11/11) checking keys in keyring [#####################################################################################################] 100%
(11/11) checking package integrity [#####################################################################################################] 100%
(11/11) loading package files [#####################################################################################################] 100%
(11/11) checking for file conflicts [#####################################################################################################] 100%
(11/11) checking available disk space [#####################################################################################################] 100%
:: Running pre-transaction hooks...
(1/2) Removing linux initcpios...
(2/2) Remove DKMS modules
==> dkms remove --no-depmod -m nvidia -v 465.24.02 -k 5.10.31-1-lts
==> dkms remove --no-depmod -m vboxhost -v 6.1.18_non_OSE -k 5.10.31-1-lts
==> depmod 5.10.31-1-lts
==> Unable to remove module nvidia/310.19 for kernel 5.10.31-1-lts: Not found in dkms status output.
:: Processing package changes...
( 1/11) upgrading avahi [#####################################################################################################] 100%
( 2/11) upgrading dbus-glib [#####################################################################################################] 100%
( 3/11) upgrading sqlite [#####################################################################################################] 100%
( 4/11) upgrading gnome-online-accounts [#####################################################################################################] 100%
( 5/11) upgrading graphicsmagick [#####################################################################################################] 100%
( 6/11) upgrading less [#####################################################################################################] 100%
( 7/11) upgrading libmm-glib [#####################################################################################################] 100%
( 8/11) upgrading linux-lts [#####################################################################################################] 100%
( 9/11) upgrading linux-lts-headers [#####################################################################################################] 100%
error: could not open file /var/cache/pacman/pkg/pacman-5.2.2-3-x86_64.pkg.tar.zst: No such file or directory
error: could not commit transaction
error: failed to commit transaction (transaction aborted)
Errors occurred, no packages were upgraded.
And now :
sh: line 1: pacman: command not found
Last edited by SRG (2021-04-21 18:47:36)
Offline
#2 2021-04-21 19:12:58
- SRG
- Member
- Registered: 2012-12-09
- Posts: 69
Re: No more pacman binary after error during pacman upgrade
So i installed "pacman-static" binary but now i'm unable on that machine (whereas network is working) to retrieve any databases ... (of course y tryed several mirrors + reflector : still the same)
pacman-static -Syu
:: Synchronizing package databases...
error: failed retrieving file 'core.db' from mirror.archlinux.ikoula.com :
error: failed to update core (download library error)
error: failed retrieving file 'extra.db' from mirror.archlinux.ikoula.com :
error: failed to update extra (download library error)
error: failed retrieving file 'community.db' from mirror.archlinux.ikoula.com :
error: failed to update community (download library error)
error: failed retrieving file 'multilib.db' from mirror.archlinux.ikoula.com :
error: failed to update multilib (download library error)
archlinuxfr 14.3 KiB 1018 KiB/s 00:00 [#####################################################################################################] 100%
error: failed to synchronize all databases
Offline
#3 2021-04-21 19:19:32
- SRG
- Member
- Registered: 2012-12-09
- Posts: 69
Re: No more pacman binary after error during pacman upgrade
Ok so i had ...
1) to install pacman-static manually (yay not working, of course)
2) to retrieve all the *.db from another up and running archlinux server and put them in /var/lib/pacman/sync
3) to retrieve the various files from the same server from /var/lib/pacman/local/pacman-5.2.2-3 (folder was available on the broken server, but was empty - not idea why)
4) after that i've been able to use pacman-static -U pacman-5.2.2-3.tar.xst
5) after that pacman working fine again (but still some weird network errors with pacman mirrors ... whereas everything else is working fine from network point of view)
Last edited by SRG (2021-04-21 19:24:58)
Offline
#4 2021-04-21 23:34:34
- Scimmia
- Fellow
- Registered: 2012-09-01
- Posts: 13,729
Re: No more pacman binary after error during pacman upgrade
The problem happened because you replaced a directory managed by pacman with a symlink. In this case, the cache dir. When pacman removed the old package, the symlink went away since it wasn't a populated dir, then pacman had no way to find the package to reinstall it.
Never, EVER replace a dir managed by the package manager with a symlink. Use the config (CacheDir), or use mounts/bind mounts.
Offline
#5 2021-04-22 04:17:39
- eschwartz
- Fellow
- Registered: 2014-08-08
- Posts: 4,097
Re: No more pacman binary after error during pacman upgrade
https://bugs.archlinux.org/task/58804
The correct thing for pacman to do is to *completely* refuse to upgrade because it isn't *safe* to, until you revert the broken mess that is replacing /var/cache/pacman/pkg with a symlink.
It is always wrong to do it, but ideally pacman would detect this by refusing to run, not by trying to run and aborting halfway through with unrecoverable errors.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
#6 2021-04-25 13:47:07
- SRG
- Member
- Registered: 2012-12-09
- Posts: 69
Re: No more pacman binary after error during pacman upgrade
The problem happened because you replaced a directory managed by pacman with a symlink. In this case, the cache dir. When pacman removed the old package, the symlink went away since it wasn't a populated dir, then pacman had no way to find the package to reinstall it.
Never, EVER replace a dir managed by the package manager with a symlink. Use the config (CacheDir), or use mounts/bind mounts.
Correct.
But sometimes some updates, when a lot of packages are about to be upgraded, are taking / needing so much spaces (in a temporary state = without needing additional space in the end) that it's difficult to find a solution (hence the creation of a symlink on another share - wasn't aware to it would break anything during the upgrade).
I agree with later post : as pacman is heavily relying on not having a symlink here, it should :
- either be checked before update
- either NOT be removed during uninstall
Offline
#7 2021-04-25 13:53:20
- Scimmia
- Fellow
- Registered: 2012-09-01
- Posts: 13,729
Re: No more pacman binary after error during pacman upgrade
I gave you solutions besides using a symlink, so your whole "But..." argument is moot.
Offline
#8 2021-04-25 15:04:05
- eschwartz
- Fellow
- Registered: 2014-08-08
- Posts: 4,097
Re: No more pacman binary after error during pacman upgrade
I agree with later post : as pacman is heavily relying on not having a symlink here, it should :
- either be checked before update
- either NOT be removed during uninstall
"let me use symlinks" is not an option. The only option here would be the data safety of checking, and refusing to do anything until you remove the symlink and replace it with the original directory, and optionally one of Scimmia's proposed solutions.
Either way, you NEED to stop using symlinks.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
#9 2021-04-25 17:43:05
- SRG
- Member
- Registered: 2012-12-09
- Posts: 69
Re: No more pacman binary after error during pacman upgrade
I gave you solutions besides using a symlink, so your whole "But..." argument is moot.
I got your point - but (again, a but ...) (and i'm not saying that in an aggressive way at all, just to be clear) can't you also get that symlinks are a default and very standard unix mechanizm + working fine in many, many places + that users not aware of all pacman configuration options may not be expecting any side issues when using a regular symlink just for what is - basically - a cache folder ? (of course if i have thought one second that it would break something, i would not have used that here ... but again, we are speaking about a folder containing package files, not rocket science kernel code)
Offline
#10 2021-04-25 17:45:00
- SRG
- Member
- Registered: 2012-12-09
- Posts: 69
Re: No more pacman binary after error during pacman upgrade
Either way, you NEED to stop using symlinks.
This is not where the discussion is at this time. Of course i will (in fact, i have no choice 
), i haven't said that i still want to use symlinks.
The discussion is (i think) about the fact that using symlinks is breaking the system + this is not obvious at all for (al least some) end users (broken system which is moreover not so easy to recover).
Offline
#11 2021-04-25 18:24:08
- eschwartz
- Fellow
- Registered: 2014-08-08
- Posts: 4,097
Re: No more pacman binary after error during pacman upgrade
not rocket science kernel code
Your flippancy is unwarranted.
The discussion is (i think) about the fact that using symlinks is breaking the system + this is not obvious at all for (al least some) end users (broken system which is moreover not so easy to recover).
can't you also get that symlinks are a default and very standard unix mechanizm + working fine in many, many places + that users not aware of all pacman configuration options may not be expecting any side issues when using a regular symlink just for what is - basically - a cache folder
It's never okay to replace managed files which you don't own and aren't registered backup files. The fact that it is a symlink is not really pertinent to the discussion.
Quite frankly, symlinks are not the magic trick you think they are. They will cause file reads/writes to be redirected in the simple case, but there are many things that operate on filesystem views which by design do not take symlinks into account. Backup software, version control systems, *pacman*... anything that manages files will not do what you expect with symlinks.
People utilize interesting partition schemes all the time, this is fine and perfectly reasonable.
Symlinks are not that. Do you think it's "okay" to replace /usr with a symlink to some secondary drive? Why do you suppose https://wiki.archlinux.org/index.php/Pa … partitions recommends using, well, partitions instead?
...
The ONLY reason I believe that makepkg should handle this case is because "people should be prevented from doing dumb things that violate the database transaction, if possible", and because it is best if doing dumb things and breaking your system doesn't *prevent you from having the tools to fix it* (which deleting pacman causes).
I still believe what you did was not the smartest thing you could have done... and in an avoidable "please use known best practices" kind of way. Now you know, do not symlink externally managed files/directories (but feel free to use novel partition schemes via mounts or bind mounts, for directories only). This should be a learning experience.
Continuing to maintain that you are wrong and "but people would not expect the problem" is quite missing the point -- Scimmia is trying to reiterate and clarify that no, you really should learn to expect symlinks to be potentially problematic, because the mindset of expecting it to be okay "because it's just a symlink" and then getting surprised when it breaks, is something we should be educating people away from thinking.
The bug report I linked still exists, for the purpose of making unwise decisions more recoverable in two different ways:
- silently overwrite your symlink, as now, but survive the experience by keeping an fd open to the packages which doesn't depend on path resolution
- actually check that files/directories are supposed to be what they are, before clobbering them, and refusing to operate if you done did wrong.
The second is harder. The first, will achieve the main goal here of being survivable, but NOT in the way you want I think? You may not actually find out that your symlink got clobbered.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline