[Solved] GLIBC_2.33' not found

ppine · 2021-03-13 15:20:46

I haven't updated arch in a while, now it came with a message, removing pacman-git from repo and after that i am stuck with this:

"pacman -Syyu
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.12)"

I cannot downgrade pacman/glib...

Last edited by ppine (2021-03-16 17:38:00)

V1del · 2021-03-13 15:25:27

https://wiki.archlinux.org/index.php/Pa … an_upgrade

Don't think about downgrading make sure you're properly up to date. Also as you should've received glibc 2.33 as part of that update, if you din't actually get that you might want to double check your mirrors so that you pick actively updated ones.

Last edited by V1del (2021-03-13 15:30:58)

Scimmia · 2021-03-13 16:47:15

"a while" meaning how long, exactly?

ppine · 2021-03-13 17:31:50

V1del wrote:

https://wiki.archlinux.org/index.php/Pa … an_upgrade
Don't think about downgrading make sure you're properly up to date. Also as you should've received glibc 2.33 as part of that update.

I did not, when it gave a warning about pacman i interrupted the update.

Scimmia wrote:

"a while" meaning how long, exactly?

Month or 2.

This box is running this install since "2013-12-28"

Now since pacman is broken i cannot downgrade, nor upgrade.

loqs · 2021-03-13 17:44:36

Follow Pacman#Pacman_crashes_during_an_upgrade 1-3 then replace 4 with:

# pacman --root /mnt --cache /mnt/var/cache/pacman/pkg -Syu

Scimmia · 2021-03-13 17:49:45

You had to have done something after you canceled the updated, and that's what was the partial update. Once you start an update, you have to finish it before doing anything else.

ansak · 2021-03-13 21:08:32

I have a similar problem and upgrading GLIBC is dangerous enough that I'm stuck in caution.

I have been bitten often enough before with archlinux-keyring and pacman changes, so my approach is ALWAYS to run pacman -Su and say NO at the prompt if I see either of those packages in the list to be upgraded.

Then I upgrade archlinux-keyring and pacman as preliminary steps, then run pacman -Su. Excessively defensive? Maybe. But I've got burn scars in other places that say it's sensible.

Now, twice in a row, I've "upgraded" pacman ahead of the rest of the process, once today, once about a month ago, and in both cases, I've wound up with a pacman that cannot run. I overcame this last time through a persnickety downgrade to the 5.2.2-1 version and I'm trying to remember what I did that time, in order to do it again.

Are you (the brains) willing to swear on a stack of a selection of sacred texts that if I pacman -Su without doing pacman first, I'm gonna be okay? What are the chances, short of unfortunate power outages, cosmic rays and HD faults that I'll wind up with an unbootable system, which IS my primary desktop and which IS NOT not running in a VM that I can snapshot back to a most-recently-runnable state.

Maybe the right "progression", if I want to be "craeful" to this extent, is to upgrade GLIBC first .. but doesn't that come with its own set of risks? all answers appreciated, even "just shut up and pacman -Su" ones..

cheers...ank

seth · 2021-03-13 21:30:54

Please don't hijack threads, "pacman -Su" should™ be idempotent because you should™ really not have run "pacman -Sy" without updating the system (at least not if you feel insecure about updates and also not if you feel too secure about them) and chances that the sytem won't boot after an update where you didn't botch the /boot partition and that is not interrupted because the gods hate you are low, but to be sure it's a good idea to have a second kernel and the opportunity to fix the system offline (ie. the installation iso) because some gods are really mean.
What is more likely is a regression in one of your userspace processes (notably any major gnome update is gonna break stuff - that's apparently "normal") and that's baked into rolling releases.
If your usecase makes you scared of updates because there might be a new upstream bug somewhere with a major pointrelease, archlinux is the wrong distribution for that usecase.

In general you're absolutely *not* encouraged to update packages ahead unless there's a very specific reason that you understand and that is typically announced on the homepage (you can subscribe to those notes by mail)
You're essentially conducting a partial update which is still the number one reason how users manage to break their installation.
(You may have to pre-update the keyring if you didn't update in a long time)

ansak · 2021-03-13 21:43:16

<contrite, head hanging> sorry. this one has been bugging me for a few weeks and this was as close to on-topic as I could find. I try to follow the release notes but sometimes they're written in a way I just don't follow by default. Maybe I shouldn't be using arch then, but overall I've been happy. I'll crawl back under my rock now. Thanks for leaving your flamethrower at home when some gormless boomer walks in and without meaning any harm contravenes what even I can realize is a basic rule of engagement in a place like this.

utterances of "okay boomer" also accepted even if I'm kinda trailing edge for that ...ank

seth · 2021-03-13 22:26:47

If you face a constant problem or have a question you can really open a threaad any time.
If you're somewhat competently handling the system, there's really no reason to be afraid of updating the system and be left with a situation where you can absolutely not access it anymore, https://wiki.archlinux.org/index.php/Pa … leshooting

However, if you critically rely on the system, it's not necessarily a good idea to kick off an update Sunday evening with the plan to afterwards write the really important office thing you're gonna need Monday morning 8:00
Every change to any system (software or life) can be for better or worse which is why professional environments will have a test system that is identical to the productive system. Changes are applied to the test system, tested, monitored and then, when the result is known, applied to the productive system(s). That process didn't develop for no reason.

That being said, I cannot even remember when an update screwed some functionality that was important to me (what probably means that it's going to happen w/ the next update - because some gods are really mean…)

ppine · 2021-03-14 16:12:30

loqs wrote:

# pacman --root

Thanks, that got me in the right direction.
Fixed using pacman --sysroot on a live usb boot, in my pacman.conf i had pacman and glibc on hold, my bad

Also shoutout to @Ansak

eschwartz · 2021-03-14 20:24:44

ansak wrote:

I have a similar problem and upgrading GLIBC is dangerous enough that I'm stuck in caution.

CITATION NEEDED.

Why is upgrading glibc dangerous? On the contrary, updating ANYTHING else, ever, while there is a pending update for glibc is incredibly dangerous. As this thread proves.

glibc is intended to be rock-stable, and it is still using the same backward-compatible soname from 20 years ago. However, this only means any newer version of glibc can run older programs. It does NOT mean any older glibc can run NEWER programs.

... because it cannot. You'll be missing newer symbols and the universe will fail.

ansak wrote:

I have been bitten often enough before with archlinux-keyring and pacman changes, so my approach is ALWAYS to run pacman -Su and say NO at the prompt if I see either of those packages in the list to be upgraded.
Then I upgrade archlinux-keyring and pacman as preliminary steps, then run pacman -Su. Excessively defensive? Maybe. But I've got burn scars in other places that say it's sensible.

No, do not do this. archlinux-keyring is a data package and can be safely updated ahead of time -- it is explicitly called out at https://wiki.archlinux.org/index.php/Pa … ion_failed as something one should do to resolve issues.

Note: any keyring issue will be "pacman says these packages are invalid and refuses to update", so it's always safe to simply let it try.

pacman upgrades are NOT safe to "upgrade as preliminary steps"... because pacman is a program linked to:

- glibc
- curl
- openssl
- bsdtar
- GPGME

And if any of these are also being upgraded, then doing pacman on its own will likely produce a broken pacman.

In fact, in this case it did lead to a broken pacman.

ansak wrote:

Now, twice in a row, I've "upgraded" pacman ahead of the rest of the process, once today, once about a month ago, and in both cases, I've wound up with a pacman that cannot run. I overcame this last time through a persnickety downgrade to the 5.2.2-1 version and I'm trying to remember what I did that time, in order to do it again.

This is the universe giving you a subtle clue-by-four to not do that.

ansak wrote:

Are you (the brains) willing to swear on a stack of a selection of sacred texts that if I pacman -Su without doing pacman first, I'm gonna be okay? What are the chances, short of unfortunate power outages, cosmic rays and HD faults that I'll wind up with an unbootable system, which IS my primary desktop and which IS NOT not running in a VM that I can snapshot back to a most-recently-runnable state.
Maybe the right "progression", if I want to be "craeful" to this extent, is to upgrade GLIBC first .. but doesn't that come with its own set of risks? all answers appreciated, even "just shut up and pacman -Su" ones..
cheers...ank

I can guarantee you that your current method will not lead to you being okay. So switching to run pacman -Su without doing pacman first, can ONLY be an improvement.

It's extremely unlikely that you'll ever end up in an unbootable state if you follow the directions and pacman -Su properly.

Occasionally, we post to https://archlinux.org/news/ with situations that require manual intervention. In one case, that was a pacman change:

https://archlinux.org/news/required-upd … ibarchive/
https://archlinux.org/news/now-using-zs … mpression/

We gave people advance warning, we gave them time, we gave them another warning, and then we made a change.

If you're still concerned about updates, note that it should ALWAYS be safe to just update once a month or so, if you've gone six months since the last update and you'd like to be extra sure you don't mess up you can use https://wiki.archlinux.org/index.php/Arch_Linux_Archive and upgrade in one-month incremental snapshots.

You may also use, as the second referenced news post on zstd mentioned, my pacman-static binary builds: https://aur.archlinux.org/packages/pacm … ned-666894

These are safe to update on their own, because they are recovery binaries that don't link to anything, glibc or otherwise.

Arch Linux

#1 2021-03-13 15:20:46

[Solved] GLIBC_2.33' not found

#2 2021-03-13 15:25:27

Re: [Solved] GLIBC_2.33' not found

#3 2021-03-13 16:47:15

Re: [Solved] GLIBC_2.33' not found

#4 2021-03-13 17:31:50

Re: [Solved] GLIBC_2.33' not found

#5 2021-03-13 17:44:36

Re: [Solved] GLIBC_2.33' not found

#6 2021-03-13 17:49:45

Re: [Solved] GLIBC_2.33' not found

#7 2021-03-13 21:08:32

Re: [Solved] GLIBC_2.33' not found

#8 2021-03-13 21:30:54

Re: [Solved] GLIBC_2.33' not found

#9 2021-03-13 21:43:16

Re: [Solved] GLIBC_2.33' not found

#10 2021-03-13 22:26:47

Re: [Solved] GLIBC_2.33' not found

#11 2021-03-14 16:12:30

Re: [Solved] GLIBC_2.33' not found

#12 2021-03-14 20:24:44

Re: [Solved] GLIBC_2.33' not found

Board footer