You are not logged in.
I hadn't upgraded my archlinux32 system for several months and tried to do a full system upgrade today.
I first upgraded archlinux32-keyring. That went smoothly.
Then, I thought it would be good idea to upgrade pacman itself before I proceeded with the system upgrade. That seemed to go okay, BUT...
now every time I try to do anything with pacman I get:
pacman: /usr/lib/libc.so.6: version 'GLIBC_2.33' not found (required by pacman)
pacman: /usr/lib/libc.so.6: version 'GLIBC_2.33' not found (required by /usr/lib/libalpm.so.13)
I tried to upgrade glibc, but, since pacman is now broken, I just get:
[root@mainpc ~]# pacman -S glibc
pacman: /usr/lib/libc.so.6: version 'GLIBC_2.33' not found (required by pacman)
pacman: /usr/lib/libc.so.6: version 'GLIBC_2.33' not found (required by /usr/lib/libalpm.so.13)
How do I get myself out of this mess? It looks like I need to either restore pacman to the version I had before, or somehow upgrade glibc independently of pacman. Does pacman store the previous version somewhere when upgrading itself?
Any suggestions appreciated.
Charles Bailey
Last edited by levi (2021-07-02 05:10:00)
Offline
Answered my own question.
I found the previous version of pacman in /var/cache/pacman/pkg/pacman-5.2.1-6.0-pentium4.pkg.tar.zst
After some more google searching I found what to do with this type of file. I executed:
zstd -d pacman-5.2.1-6.0-pentium4.pkg.tar.zst
which created pacman-5.2.1-6.0-pentium4.pkg.tar
Then I did:
cd /
tar -xf /var/cache/pacman/pkg/pacman-5.2.1-6.0-pentium4.pkg.tar
and that restored pacman to working order again.
I tried a system upgrade again and it finished successfully
Charles Bailey.
Offline
Well, you should be able to git clone it's repo and makepkg it, and dependencies shouldn't be too bad on a -static project. The only gotcha with a broken pacman is you won't be able to pacman -U it, but as our previous poster has demonstrated you can install it just using tar (or better bsdtar) after decrypting it. That will leave you with pacman-static binaries lying around the filesystem which aren't in the pacman db, but presumable a special incantation of pacman-static can resolve that by trying to install the package again with some overwrite flag I've not yet discovered.
The last time I had to do something like this, I powered off accidentally during a pacman -Su update, and apparently I did it in the middle of an inkscape update. I booted from a live disc the next morning, mounted the discs, arch-chrooted in and did a pacman -Su to resolve most of my mistake. That left me with a system that would boot, but no inkscape installed, but I had most of the inkscape binaries in my /usr filesystem. I resolved that in the end by trying to install inkscape from the repo and noting the file conflict errors and deleting those files manually before reinstalling inkscape. I was then I disovered that inkscape was actually broken when I tried to do that, so even after installing it properly it was still failing, but that in the end was shortly resolved after posting here.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
logic_guy76 thank you, so much. You really saved my life the other night. I was kind of stuck with numerous errors during a pacman -Syu
And I thought it could be a seemingly good idea to try pacman -S pacman. It was not!
Exactly same error you describe in your initial message and applying your suggested solution brought pacman back to life.
After this and some research, I managed the full system update with two things:
* first, launch this: pacman -S archlinux-keyring
* then ignore some file conflict in a dynamic library, by doing something like this: pacman -Syu --overwrite /usr/lib\*/p11-kit-trust.so
And after this I could even upgrade pacman (which means it is not done during the -Syu update).
Offline