🔥 Upgrading manjaro-system removed glibc

The package manjaro-system doesn’t have anything to do with glibc and doesn’t even touch glibc from a mile away. The 2023.01.24 update to [Stable] did however include an updated glibc-locales package, and presumably, due to your own admission that “the upgrade failed” (as per your quote), you probably ended up with a broken system.

Either way, you should by now already know that you can repair your system by chroot-ing from a live USB and rerunning the upgrade process from there. If you don’t know how to do this, then please search the forum, as the procedure has already been explained a gazillion times — including by myself earlier today.


manjaro-system upgrades various components atomically, using pacman -S [package] instead of pacman -Syu [package].

Since that first method is not really supported, it could be that one of those atomic upgrades removed glibc temporally, making any further upgrading commands to fail.

chrooting didn’t work because glibc was broken.

I had to manually copy glibc libs into the system for making it work.

Logs or didn’t happen. You’ve been around long enough to know better.

Please see:


It was something like:

Running 'pacman --sync --refresh'
synchronizing package lists
Running 'pacman --upgrade --needed --noconfirm manjaro-system-20221227-1-any.pkg.tar.zst
upgraded manjaro-system (20210612-1 -> 20221227-1)
We will reenable 'os-prober' for you ...
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-linux-zen
Found initrd image: /boot/amd-ucode.img /boot/initramfs-linux-zen.img
Found initrd fallback image: /boot/initramfs-linux-zen-fallback.img
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
Root filesystem isn't btrfs
If you think an error has occurred, please file a bug report at "https://github.com/Antynea/grub-btrfs"
Found memtest86+ image: /boot/memtest86+/memtest.bin
running '30-systemd-update.hook'...
transaction started
transaction failed

tac /var/log/pacman.log | less
for example
shows the log, last entry first

or just:
less /var/log/pacman.log
and go to the end

it will show you what actually happened, and when

That’s what happened at 10:16.

No more explanation than:

transaction started
transaction failed

a bit of context before and after that would probably be more … helpful

that is not how the complete log entries look like, btw

Because that’s not the actual log. I deleted it when I reinstalled the system, after reading it.

Ahh - so thats your way of saying that this whole topic is mute/solved/whatever - not requiring any attention anymore?


I thought you where responding to my comment above:

apparently not

Look at the script last addition:

rm $(pacman-conf DBPath)db.lck
pacman --noconfirm -Rdd dbus-x11
pacman --noconfirm -S dbus
touch $(pacman-conf DBPath)db.lck

Next read the manual:

-d, --nodeps

Skips dependency version checks. Package names are still checked. Normally, pacman will always check a package’s dependency fields to ensure that all dependencies are installed and there are no package conflicts in the system. Specify this option twice to skip all dependency checks.

From there you have two options. Or give constructive responses, or I stop responding while I remove this package.

I suspect this is related with a particularity of my Manjaro installations, which use pacman-auto-update.

For security, pacman-auto-update don’t perform upgrades right away. But first it downloads all the packages, and only them attempts to install them (if the computer hasn’t requested to power off).

Now pacman in Manjaro is patched to upgrade manjaro-system before performing any other action, and manjaro-system performs syncs and removals fully ignoring dependency checks. While also manually removing the db.lock.

Probably this is just caused by manjaro-system assuming that the only way it can be properly upgraded is via pacman --sync --refresh --sysupgrade, ignoring that pacman --sync --refresh --sysupgrade --downloadonly is valid too.


By the way my system wasn’t the only affected. I had to visit someone else today to fix the same problem, while warning a few more people not to upgrade.

If this was indeed a general issue, what about the couple of hundred people in the update announcement poll that said they had no issues?

manjaro-system is installed on every manjaro install, so if this update was to remove glibc, no user would have put no issue there, because it would have happened to everyone.

I think it’s something specific to you and your friends setup, if it did indeed happen.


Surely you have saved that log then?

1 Like

I will ask the guy if he can send me it.

1 Like

pacman -S is fine as long as the local database is consistent with what’s installed on your system. -Sy is what causes problems, it updates your package databases but not your system, then because your local database is no longer consistent you may install an incompatible version when you use -S. Just don’t use -Sy and it’s all good.

Also, if manjaro-system used -Syu it would try to update the system whilst in the middle of an update. This doesn’t seem sensible.

Seems like it’s replacing dbus-x11 with dbus. It first removes the lock so it can use pacman again, removes dbus-x11 without removing it’s dependancies (which is a good thing) and then installs dbus and replaces the lock so things can continue normally.

So what’s your point?

As for pacman-auto-update:

Keeps packages from compiled repositories updated hourly.

Who needs hourly updates. IMO monthly is a good time frame and updates shouldn’t be automated.

If you’re going to modify your system, make sure your modifications work, especially if others are using this stuff. You have to fit your modifications to the system not the other way round.


It doesn’t seem to be the reason.

In pacman-auto-update the only time -Sy is used is before doing anything else, for checking if there are upgrades.

update-system.sh doesn’t seem to do that either.

Wondering if sync-first.patch changes that behavior…

Maybe it confuses the function updateKeyringsFromRepo (), as that one is atomic for each key-ring. Probably “manjaro-system” is upgraded too there. I will investigate.

Actually it worked flawlessly for two years, and it was tested by multiple developers.

Sometimes you can’t simply anticipate where problems will be found, and the only way to move forward is to assume the short term risks.

That or you write everything on a wiki, and cross your fingers that now the user knows what they are doing.

Actually it is my belief that if no more people uses Linux it isn’t because people is dumb, but because people is smart. And how popular Linux is by the desktop is by its own merits.

Hence I will automate EVERYTHING. Even things you cannot imagine.

…until it breaks.

Updating manjaro-system DID NOT remove glibc. YOU DID.