I’m on stable. For me, Is there a way to install this new verison via pacman -U http://www.example.com/repo/example.pkg.tar.zst or maybe download the file first, but from what source URL?
I’ve quickly looked and found Arch Linux / Packaging / Packages / glibc · GitLab
Do you mean https://archlinux.mailtunnel.eu/core/os/x86_64/glibc-2.38-7-x86_64.pkg.tar.zst
from Arch mirror?
Dowload it from Manjaro unstable branch:
https://mirror.alpix.eu/manjaro/unstable/core/x86_64/glibc-2.38-7-x86_64.pkg.tar.zst
Thank you!
sudo pacman -U 'glibc-2.38-7-x86_64.pkg.tar.zst'
… seems to work fine 
Does this require a reboot to be in effect?
You probably need to run $ sudo mkinitcpio -P to rebuild initramfs and then reboot.
PS: glibc is required by many dependencies, but they (from the stable branch) probably wouldn’t match glibc (from the unstable branch).
You try it at your own risk, not my responsibility.
1 Like
Thank you @Zesko !!
Downloading it
and then
sudo pacman -U 'glibc-2.38-7-x86_64.pkg.tar.zst'
and
sudo mkinitcpio -P
followed by
reboot #reboots your system instantly!!!
… is probably the way to go for everyone who wants to try updating this security-fixed package when you’re on Stable.
If a user needs latest version of glibc it would better to switch to testing branch
Partial updates are not supported
3 Likes
Probably has to do with what/how much they changed to be working.
So far everything is smooth, I’ll keep you posted. 
This thread should not only be locked but removed ASAP. Can’t really think of more stupid advice how to “brick” your system as this one. It’s on the order of rm -rf /.
And to answer OP: NO!!! glibc is the last package you should mismatch.
4 Likes
This why I have a test mule vm 
. I almost Nuked my main install.
1 Like
By doing the above?
Oh touching vconsole or what ever happened.
Mismatching rebuilt (pkgrel) version (2.38-1 → 2.38-2) might not be catastrophic. But sooner or later someone will do that with actual package version.
And then you can expect this:
sudo pacman -U https://archive.archlinux.org/repos/2023/05/01/core/os/x86_64/glibc-2.37-2-x86_64.pkg.tar.zst https://archive.archlinux.org/repos/2023/05/01/core/os/x86_64/lib32-glibc-2.37-2-x86_64.pkg.tar.zst
loading packages...
warning: downgrading package glibc (2.38-7 => 2.37-2)
warning: downgrading package lib32-glibc (2.38-5 => 2.37-2)
resolving dependencies...
looking for conflicting packages...
Packages (2) glibc-2.37-2 lib32-glibc-2.37-2
Total Installed Size: 65.47 MiB
Net Upgrade Size: 0.10 MiB
:: Proceed with installation? [Y/n]
(2/2) checking keys in keyring [------------------------------------------] 100%
(2/2) checking package integrity [------------------------------------------] 100%
(2/2) loading package files [------------------------------------------] 100%
(2/2) checking for file conflicts [------------------------------------------] 100%
(2/2) checking available disk space [------------------------------------------] 100%
:: Processing package changes...
(1/2) downgrading glibc [------------------------------------------] 100%
/usr/bin/bash: /usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by /usr/bin/bash)
error: command failed to execute correctly
(2/2) downgrading lib32-glibc [------------------------------------------] 100%
:: Running post-transaction hooks...
(1/5) Reloading system manager configuration...
/bin/sh: /usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by /bin/sh)
error: command failed to execute correctly
(2/5) Creating temporary files...
/bin/sh: /usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by /bin/sh)
error: command failed to execute correctly
(3/5) Arming ConditionNeedsUpdate...
/bin/sh: /usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by /bin/sh)
error: command failed to execute correctly
(4/5) Restarting cronie for libc upgrade...
/usr/bin/systemctl: /usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by /usr/bin/systemctl)
/usr/bin/systemctl: /usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by /usr/lib/systemd/libsystemd-shared-254.5-1.so)
/usr/bin/systemctl: /usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by /usr/lib/libblkid.so.1)
/usr/bin/systemctl: /usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by /usr/lib/libmount.so.1)
/usr/bin/systemctl: /usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by /usr/lib/libcrypto.so.3)
/usr/bin/systemctl: /usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by /usr/lib/libaudit.so.1)
error: command failed to execute correctly
(5/5) Updating the info directory file...
/bin/sh: /usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by /bin/sh)
error: command failed to execute correctly
~ > pacman -Q glibc
pacman: /usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by pacman)
pacman: /usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by /usr/lib/libalpm.so.13)
pacman: /usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by /usr/lib/libarchive.so.13)
pacman: /usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by /usr/lib/libcrypto.so.3)
pacman: /usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by /usr/lib/libgpgme.so.11)
~ > bash -c 'echo hello' zbe@manjaro
bash: /usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by bash)
2 Likes
The previous version was 2.38.5, not 2.37-2
Is the security flaw also in lib32-glibc ? I did not manually update that.
You’re scaring me now. And sorry I didn’t want to drain anyone’s energy on this. 
Do you for some reason run Manjaro as a server with other (unknown) users using it? If the answer is no, then you’ll be fine. If the answer is yes… well, then you have bigger problems. 
Instead of installing mismatched packages ask Manjaro team to fasttrack it (since it’s a security update).
See, another mistake - yet another mismatch.
I just installed random glibc to make a point.
1 Like
Think about semantic versioning rule, it would help us to consider backward compatibility
Version X.Y.Z
X = MAJOR version when you make incompatible API changes
Y = MINOR version when you add functionality in a backward compatible manner
Z = PATCH version when you make backward compatible bug fixes
But I do not think all packages/dependencies follow this rule except Kernel version.
No, no server. Prbb. be using Debian on that.
So if I’m misconfiguring, I should be misconfiguring the 32bit thing as well…