So it’s probably best to wait a few days before applying any big update.
Sometimes I wait a week or more.
Not enough people run the testing branch,
so there’s always breakage soon after a big stable update.
As you can see, Phil and the team quickly push fixes into Stable,
so after a few days it’s pretty safe.
For this to happen, they need a lot of people to run the stable update promptly,
so I’m suggesting that the people who should wait a while are only
those who depend on their Manjaro box for some serious purpose.
Since the upgrade to 2023-06-04 with gnome/xorg/nvidia, I’m not able to launch games via steam-native nor steam-runtime. Steam gets stuck in the “Launching game xyz” modal. But the game itself never comes up. Any suggestions/recommendations how to tackle this issue?
try to start the steam launcher from a terminal to see if it gives you some output into the terminal window. Then you may find the reason it may not work maybe faster. For steam it is either steam or steam-runtime.
Downgrading to previous version of Brave (brave-browser-1.51.110-1-x86_64.pkg.tar.zst) solved the issue of brave-browser not remembering “Brave colors” setting at launch.
This leads to steam re-initializing itself and freshly setting up it’s runtime. I can only assume that it renews it’s links to the new manjaro 2023-06-04 libs and that this did the trick.
Hope that this helps others. Good luck.
running plasma the latest update is missing a “darkmode” support that was running before the update. hypnotix is missing XApp.Darkmodemanager that was avaiable before the update.
There’s an easy way to have the best of both worlds.
I have a “rescue” partition onto which I clone my root partition immediately prior to each update. Then if there are any showstopper problems with the update all I have to do is boot into that partition and I can carry on as before (and if necessary restoring the “real” root partition while I’m in the rescue system).
And if I’m uneasy about an update because people are reporting nasty problems, I can always do the update on the rescue partition first as a test.
That said, in about five years of using Manjaro I think there’s only been one occasion when I’ve had problems that necessitated using the rescue partition and even then it was a fairly minor problem (I seem to remember it was a problem with virtual machines).
In Gnome, minimizing and un-minimizing app windows (especially when the window is “maximized”) produces artifacts in the animation. This was not there before. Intel GPU.
I am encountering an issue where I cannot log back in after locking the screen in Manjaro with GNOME 44.1. From my observations, it seems that the problem stems from a specific gnome-extension. The issue is resolved when I disable these extensions, but I require their functionalities.
You can use the application Timeshift to achieve the same thing.
Create a Snapshot before the update. If you need to revert just click restore, and it will perform the restore and reboot back as your system was before the update.
It’s mostly just in a simple script I’ve put together to automate the process.
I start using dump to create a backup of my root partition (this is done as part of my pre-upgrade backups) then use restore to copy it all to the rescue partition (obviously this won’t work if you aren’t using EXTn filesystems).
Then the script edits the /etc/fstab on the rescue filesystem to change the root filesystem to the correct UUID. All my other filesystems can be shared between the two, so that’s the only one I need to edit.
Once that’s done I run update-grub on the base system to add the rescue one to the GRUB menu, so I can easily choose it at boot time.
One other useful idea is to have /var/cache on a discrete filesystem rather than on /. That way if I want to do an experimental upgrade on the rescue system before risking it on my base system, the packages only need to be downloaded once.
The only time I’d be unable to easily boot the rescue system would be if for some reason even GRUB was screwed on the base system. I have a USB image just in case of that, though so far I’ve never needed to use it.
The KDE Plasma X11 mouse acceleration issue from 2023-04-11 has been fixed so I just needed to change System Settings → Input Devices → Mouse → Acceleration profile back to Adaptive again.
No problems apart from that (I waited to apply this update after seeing the DKMS issue, looks to be all good now).
Please start a specific thread and provide the usual info and the extension(s) that are affected, troubleshooting this in a separate thread would keep things focused.
All the above issues, I am not affected of.
Went to set Adaptive mouse speed.
zsh working, no long start of Firefox or similar. Oh I see the update fixes that, removes xdg-desktop-portal-gnome and installs xdg-desktop-portal-kde . (I used pamac update).
Thank you for the fast fixes, Manjaro team.
I however found a small issue, baloo-file-extractor was highly active and wouldn’t stop for a longer period but eventually did. Maybe just on that first boot, because much file content was changed?
Probably, otherwise, no issues.
Shortly before the update I reinstalled video-nvidia
sudo mhwd -f -i pci video-nvidia
And I could not get to login screen anymore.
This happened to me for the second time, also before the last update.
Is it recommended to update-grub or run mkinitcpio or something after such reinstall? I’m getting offtopic here, or maybe it pulled newer version while the rest was not updated yet and this is update related.
Anyway logged in fine after the sudo pamac update.
Actually some people recommend reinstalling video-nvidia after every update but I am scared now …
Some apps made very slow to start after this update.
I have confirmed that the problem occurs in at least Firefox, Firefox Beta, Waterfox, Epiphany, and Gnome Screenshot.
We have confirmed that this problem occurs on two different machines (Ryzen9 5950X/Radeon RX7900XTX and Ryzen5 5600X/Radeon 5700XT) and does not appear to be environment specific.
. Can I ask you what application do you use for this cloning?