Hi, it’s always recommended to run the update from a terminal because the GUI tends to crash with large updates (30+ packages).
These are the steps I follow every time I update: [Stable Update] 2024-10-01 - Kernels, Plasma 6.1.5, KDE Gear 24.08.1, LibreOffice, Virtualbox 7.1 - #84 by r0nin
I suggest you try updating again before rebooting, at least to make sure all packages are updated.
I ran manjaro for more than 5 years and it never crashed the GUI, on several computers. YMMV but it does not seem to be something commonly experienced.
Only times i used TTY was when the update message said that this one is better performed on TTY, i recall the last one being a particularly problematic systemd update.
If the update includes the GUI itself I think it is just a fact that problems can arise. You are using some files from the GUI (and they are loaded in memory). As soon as you update the filesystem files, new files that are needed are going to be from the new version. So you are going to have a mix of old files and new files in memory.
Maybe some library has been updated. Maybe the update includes some internal API change… There are countless ways things can be wrong if you do the update from the GUI. Most probably during the update there are going to be no problems, but longer you use the system after that, higher risk of running into some problem.
You have been lucky, but that doesn’t change the fact that is not a good idea to change “on the fly” the files that back up a live system.
I always do big updates from the console (not terminal). Once I did a test to see how problematic a GUI updated can be, and at least in my case, I didn’t needed many tries to get a freeze after an update (it was after the update itself, but before I restarted the system)
all called files are mapped into memory and if they update on disk it won’t matter. Only if the program happens to load some new files as a result to the actions being taken can mismatch occur.
Critical components like DE should load all that is needed for normal operation at boot. Configuration changes etc. that expect to load new files should be gated to detect updates and prompt for restart, even firefox is able to do this when necessary.
Yes, that’s why I said “longer” you use the system, higher the risk you encounter some problem, because it is more probably that new files are going to be needed and loaded.
anyhow, a crash from this is a bug, and should be fixed, not just encouraged for users to work around it to drop to TTY and restart. That’s windows ■■■■■
Not always. Some files may only be read from in small chunks “as needed”, and they are being held in an open state in the filesystem layer. This goes back to the days when entire UNIX systems with multiple users had to fit into only 4 KiB of RAM.
wouldn’t that be direct io and it’s not done as a way to load application libraries. At least extremely uncommon, and irresponsible in the case of a DE.
True, but due to caching, you still stand a chance of overwriting a library that needs to be loaded at a later point in time, and which then won’t be compatible anymore with the already in-use routines and symbols.
Perhaps a bit of a bad analogy, but think of the scenario where ldconfig gets updated, or glibc, or something similarly low-level.
I was expressing myself badly in the previous post, but it actually has more to do with the linking. A running system is in a constant state of flux. Things get loaded in and unloaded from memory all the time.
So if the desktop environment — or some application that gets started after completing the update but without rebooting — wants to load a freshly overwritten library, then that may cause problems in the running environment.
Absolutely. There is, or should be, no need to update from the terminal.
Yes — but anyway, it should work anyway. The Unix philosophy is that the file is unlinked, but it stays there if there is any program that uses it (and that should take into account the file mapping in case of an executable). So really, until all references to the file are closed, there is a phantom of the old file, and the executable should never notice any change “in flight”.
Now, if the program actively opens a file or executes something after the update, and it is not prepared for the fact that it can have been changed, that’s another matter. But I agree that in this case, this is a bug.
To be honest, pamac never died in my system, and I am doing updates in DE in Ubuntu Gnome for at least 20 years, and I had no crashes. So this thing must be something else.
That, and the user not rebooting right away after updating.
That’s the other weak link in the chain. pamac works perfectly fine, until it doesn’t. The forum is rife with reports of instability of the pamac GUI.
octopi is actually far more reliable. And pacman is as perfect as it gets.
…and to demonstrate that karma does exist and has a strange sense of humor, pamac-manager hung on me in the last update (but I could recover via command line).
The problem has been that pamac-manager fired the password gnome dialog, then it lost focus (I have focus-follow-mouse) while I was typing the password. The dialog disappeared, and pamac-manager got stuck. I rapidly killed it and updated via the command line, without any problem. But maybe it could be a hint to find the problem…
So that is another app to add to the list “misbehave with focus follow mouse”, together with globalprotect and most Windows applications through wine. That is why I had to write a Gnome extension to switch focus mode…
I have been using pamac upgrade in the terminal for several years with no issue’s.I do open pamac gui once in awhile and clear the cache and check to see how many orphans I have if any.I guess I am old school as I have pretty much used the terminal to upgrade since I have been using linux.
You can do all that from the command line as well. 
pacman -Qdt
sudo pacman -Rns $(pacman -Qdtq)
sudo paccache -rvk0
If you want to run that last one without the excess verbosity, then you can use -rk0 instead.
pamac list -o
pamac remove -o
Yes, but apparently there’s an issue with that.
I’m not sure on the details because I prefer the tried-and-trusted pacman for that, but I remember @cscs regularly bringing it to people’s attention that pamac tends to default to removing too much by default in terms of dependencies.
Personally I only use pamac — the command-line version — for updating my AUR packages, although I have on several occasions had to resort to an AUR helper like yay or trizen due to issues with pamac.
Also, if you insist on using a GUI, then I recommend octopi, which really does use pacman (and an AUR helper) in the backend, as opposed to pamac, which uses libalpm but does everything differently.
Besides, I’m running Plasma, and octopi is qt-based, whereas pamac is gtk-only. For a short while, there was a qt-based version of pamac as well, but it was seriously lagging behind on the gtk version and was then ultimately abandoned.
Interesting…
If I am to believe everything I read here. Every tool developed specifically for Manjaro, seems to be faulty in some manner.
Well, not every tool. mhwd is pretty good at what it does, even if it’s a little… weird in how it handles graphics drivers.
And manjaro-chroot — which is on the install media only — is quite adequate too, provided that you have ext4 filesystems. It still needs to be ported to btrfs, but considering that we’ve recently made btrfs the default for new installations, I expect that it’ll be enhanced with btrfs compatibility in the near future — it’s only the autodetection that doesn’t work with btrfs.
There are more Manjaro-specific tools and meta-packages that also do what it says on the tin. But pamac has always been a bit of a problem child. And as you could already discern for yourself, manjaro-settings-manager was not particularly well-designed.
More interesting stuff.
Looking at manjaro-settings-manager I see there is manjaro-settings-manager and manjaro-settings-manager-notifier but according pamac there are 2 versions, one specifically for Plasma5 (which is installed on my machine) and another one showing no plasma preference (currently not installed), both have the same version number 0.5.8-4