In one of my computers, I had one small issue with nvidia-settings missing and one of my monitors changing resolution from 1920x1080 to 640x480 from my system after updating and rebooting.
The affected monitor has is named changed to nvidia and no other resolution was available.
Fix:
System Settings > Hardware Configuration > Right click video-nvidia-470xx and select reinstall
Once the re-installation completes successfully, reboot the system. The nvidia-settings utility will be again available. Disconnecting and reconnecting the DP cable of the affected monitor trigger the system to detect the monitor correctly and restore the proper resolution.
As @cscs suggested you can install the New Grub Maintainer Script that alot people using now in the community, its a no brainer but SecureBoot, ZFS and a fancy encryption are not yet supported as Philm said, all in all it should work flawless for the majority of people.
I simply installed it in the pamac GUI, it called install-grub just download this package, this script detects fresh downloaded Grub files. When a new release/stable release shows up, it will install Grub automatically to MBR/EFI.
But if you donāt want to wait for the next grub version download, you can use this command to trigger it in terminal after you downloaded install-grub:
sudo pacman -S grub
After a reboot you should see the new Grub version in the Grub Menue.
Ok, having a really weird issue on one machine - its KDE / Intel CPU / Intel / Nvidia Hybrid gfx (yes I know).
I am seeing the following error
flatpak: error while loading shared libraries: libicuuc.so.73: cannot open share object file: No such file or directory
Not entirely sure if its related yet, but when I boot into KDE (which is difficult with the input lag) I can see that the software renderer is currently running (hence the lag). Iām not yet sure if this is connected, but it certainly seems to be suspicious. KDE is hardly functioning at all due to the above flatpak issue.
libicuuc seems to have updated to 74.2, so not entirely sure why flatpak is still clinging on
Any clues? Machine is pretty much unusable at this point.
Never mind, its because of a dependancy problem due to not being able to update libxml2 due to other problems. Do you know it its safe to remove flatpak?
All branches should be on icu version 74.
And all supported packages likewise are built against 74.
If you have something trying to use 73 it is an unsupported package that needs to be rebuilt or removed (AUR?), or you are in a partial-upgrade state.
Okey, to your question flatpak is entirely optional.
Of course you need it for using ā¦ flatpak apps. Otherwise it is unnecessary.
At a guess, thereās a systemd service file which is configured to restart the process if it dies. As itās starting āafter a whileā, presumably thereās a timer triggering it to start a certain time after startup.
As far as I can see, there are no files in NextCloud client package which belongs to systemd.
Since the upgrade I have the same strange behaviour, too. When I start HandBrake (program name āghbā), automatically NextCloud client is started and HandBrake is not usable and has to be killed.
When NextCloud client is started beforeHandBrake, HandBrake can be used.
Before the upgrade using of HandBrake was complete independent from NextCloud client.
Until now I didnāt had the time for investigating this problem further. Problably someone already has a solution for this problem.
Iām using NextCloud client for synchronizing some data, so I have to keep it installed.
Before the last upgrade there were no such problems regarding NextCloud client and HandBrake.
In this upgrade seems to be a dependency introduced, which hasnāt been there before.
In my first short investigations I couldnāt find anything where this problem is related to.
Because of workaround for starting NextCloud before HandBrake I can postpone further investigations for me at the moment.
Iām not sure, but I suspect it has to do with the new update. Dolphin behaves strangely. After running it for sometime, with the embedded terminal, the terminal stops working. Then I closed Dolphin and restarted it from the menu, it doesnāt show up. ps shows itās running, but I canāt kill it, even with kill -9. I have to reboot.
I think I set pamac to keep 2 sets of history. Not sure if that allows me to revert back easily. But so far, I havenāt got a second occurrence of the strange behavior. Will see.
Could you advise what difference of updating from tty can make? Iāve always done it through the pamac gui.
From my experience, I can only advice to do it via tty with Plasma because of its bugs. I love KDE though.
Also Manjaro officially advices you to always do it via tty.
sudo pacman -Syu
flatpak update
And then check pacnews afterwards
pacdiff -s
Reason is, many config files get changed during an update. So it is safer when NOT any program is running.
error: failed to commit transaction (conflicting files)
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/.autotest exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/History.rdoc exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/Manifest.txt exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/README.rdoc exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/Rakefile exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/design_rationale.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/lib/hoe/minitest.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/lib/minitest.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/lib/minitest/assertions.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/lib/minitest/autorun.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/lib/minitest/benchmark.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/lib/minitest/expectations.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/lib/minitest/hell.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/lib/minitest/mock.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/lib/minitest/parallel.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/lib/minitest/pride.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/lib/minitest/pride_plugin.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/lib/minitest/spec.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/lib/minitest/test.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/lib/minitest/test_task.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/lib/minitest/unit.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/test/minitest/metametameta.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/test/minitest/test_minitest_assertions.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/test/minitest/test_minitest_benchmark.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/test/minitest/test_minitest_mock.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/test/minitest/test_minitest_reporter.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/test/minitest/test_minitest_spec.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/test/minitest/test_minitest_test.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/test/minitest/test_minitest_test_task.rb exists in filesystem
ruby-minitest: /usr/lib/ruby/gems/3.0.0/specifications/minitest-5.20.0.gemspec exists in filesystem
Deleting everything the folder /usr/lib/ruby/gems/3.0.0/gems/minitest-5.20.0/ and the file /usr/lib/ruby/gems/3.0.0/specifications/minitest-5.20.0.gemspec and running pacman -Syu again did the trick.
Manjaro update announcements recommended updating via tty one time on the old forum
(> 5 years ago)
Updating via tty is not needed most of the time
But it is better to update via terminal than using GUI
And it is good to be careful that the system does not turn on the screen saver, or try to sleep or hibernate while the update in the terminal/gui is not yet finished.
I have the opposite experience, i updated via tty in the first few month after i joind Manjaroā¦ then i saw Philms comment somewhere that he recommend using Pamac GUI, because there are some automatic decissions taking which Pamac decided for usersā¦
So i decided to use only pamac from now on, till i saw Aaragon was hardly talking against pamac in a stable update topic, where also was big changes about Audio Codec changes btw.
So i decided to use TTY with pacman again (on my PC) and it was a big fail decission because pacman recomment to use a āfakeā default audio codec reset and recomment me to install Ardour package, in the mean time i used pamac on my Laptop that didnt installed this 80MB big (useless) packageā¦ but till this day i regret using Pacman and at the end of the day i need to restart my PC anywaysā¦ so it didnt matter if i use Pacman because it can replace faster without a PC restartā¦ there are few files that waiting for a reboot anyways.
On the other hand i saw pamac crashing few month ago when i was browsing around and clicking on the Index Pages,
so it ācanā be dangerous and when its updating i recommend not to wildly click and play with the GUI while updating
For all unexperienced users, i recommend pamac GUI and to use Timeshift on a External HDD/SSD before doing updates.
or hibernate 
while the update in the terminal/gui is not yet finished.