lib32-libx264-10bit and lib32-libx264-all seem to be packages from the AUR, right?
Try removing whatever you installed from the AUR that needs them (and by extension these packages) and see if the update goes forward now.

Since the update, Firefox (both stable release and Nightly) has WebGL (1+2) disabled.
I suspect it is a firefox problem with some of the updates (xorg-server?, libglvnd?..) because Chromium WebGL still works fine.
If anyone has a good clue what the problem is, here is the bugreport.

With this update, my Mate desktop running in a QEMU/KVM virtual machine boots to a blank desktop screen. (I have autologin enabled in this VM). Run level 3 and SSH login both work OK so it appears to be an issue with X.org, Mate, or the QXL video driver. Tried several experiments and finally found a set of changes that provides a working desktop:

Revert back to the VESA display driver instead of QXL. (Change 90-mhwd.conf symlink in /etc/X11/xorg.conf.d to point at /etc/X11/mhwd.d/vesa.conf).

I don’t understand the failure and the journalctl logs weren’t consistently reproducible between reboots. For example, I saw mate-settings-daemon crash one time. I also run the VM on a Linux host that has a HiDPI (3440x1440) screen so maybe there’s some HiDPI interaction?

Anyhow, hope this helps anyone with a similar issue running Manjaro in a QEMU/KVM guest with QXL.

Update went fine from terminal Syu apart from when i restart or shut down i see an error about “error unmount” something as it shuts down/restarts to quick to read it, does someone know if a log file might help track this down?

I’m sorry, but these no content posts only add noise to the update threads. If your update went fine, please just respond to the poll and/or give Phil a like. I’m reading this thread for issues and solutions, not “+1”.

At first blush, I tend to agree with you. Should I expound on that or would a simple “+1” suffice?

In Archlinux, we have updates daily. No announcement is made and only occasionally is there a need to post any warning about recalcitrant packages needing user-intervention during an update. In other words, it’s almost always No Big Effing Deal.

But Manjaro Linux is not Arch, and the updating procedures are not the same, either. Manjaro has always used a batch process, collecting updated packages over a longer period of time and then releasing them in batches once they have been made ultimately suitable for Manjaro (Stable). @philm or his designee then announces and provides the updated and batched packages to their appropriate channels. (The same processes also happen with Unstable and Testing, but to a lesser degree.)

The Poll says that this update had a reported success rate of 82%, and it was a problem for 18% of reporting users. 18%! That’s huge! If 18% of Arch users had problematic updates I doubt it would have survived this long.

And if 82% of the 131 posts here (107) had no updating problems, how is anyone expected to find help when their post (@ 18% = 24) gets lost in the shuffle?

So I end up with a mixed reaction. @philm & Co. most certainly need to know when everything works, but more importantly, when they don’t. That means @philm @ Co. has to read through every one of these posts, including all of the “It worked” posts in order to find the ones they are really looking for.