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.
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 done running '30-systemd-update.hook'... transaction started transaction failed
tac /var/log/pacman.log | less
shows the log, last entry first
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:
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:
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.
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
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?
I will ask the guy if he can send me it.
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.
-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. 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?
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.
manjaro-system DID NOT remove
glibc. YOU DID.