I’ve tackled this as always when dealing with packages I think I don’t need: I set the install reason to “installed as dependency” and check/clean orphans afterwards.
They will go away when all depending packages have made the switch to their newer counterparts.
2 Likes
For consistency for a “basic manjaro user”, before plasma 6 moves to stable.
I have a laptop on testing, not changed much in form of theming other than the SDDM background and my desktop background.
After update to plasma 6 on this machine (and supposedly on lots of other manjaro installs as well) the icon on the application menu is now plasma logo, not manjaro.
It’s a tiny thing, but I point this out so it does not fall between the cracks.
And for consistency of manjaro, the icon should still be Manjaro.
Not sure this is possible to push through the update though but still wanted to point it out.
Fix is obv: just change the icon manually.
Also have to add a new profile in Konsole with the MesloLGS NF font to get the manjaro zsh theme to work properly.
Otherwise the update went through flawlessly.
Also, don’t forget to remind about pacnews.
Yesterday I updated to Plasma 6.
Even before update I was using the Breeze dark theme, so I didn’t actually need to perform any changes at all to get a fully working system while I stayed on X11.
I also tried switching to Wayland, where I encountered some stuttering, especially during various animations (window movement, system tray menus open/close, Yakuake open/close).
For me it helped to go into “Display Configuration” and set “Adaptive sync” to “Never” - that seems to have resolved any such visual stutter as far as I can see.
2 Likes
On one of my laptops, I have a hybrid setup with Nvidia GTX 970M (an old card) and I didn’t have to do anything, it just worked (although in the past it didn’t). However, the thing is, the desktop is run on Intel via modesetting driver, while Nvidia is on demand for games. This works flawlessly. I haven’t tried full Nvidia mode, because I see no benefits of running desktop through Nvidia. Additionally, the hybrid mode is created by optimus-manager. I could do pure MHWD hybrid from Manjaro, but then multimonitors wouldn’t work for me, no idea why. I tried to debug it or solve it but couldn’t figure it out. There is too little info about how Wayland and graphics on Wayland works and forum users were not overly helpful, because they didn’t know either. So I dropped the topic and returned to optimus-manager, which fixed the multimonitor support. However, even without optimus-manager, hybrid MHWD setup worked on Wayland automatically.
Mkinitcpio hooks need to be changed manually. There is a chance that if you don’t do that, some fallback GRUB settings will be used and the system will still boot, but not for everyone. Basically, you need to add microcode hook in mkinitcpio and regenerate it. At least this is how it was explained in the announcement regarding unstable update. I did that and all works, no errors or warnings during the boot. The packages that need to be upgraded together were also important, but they come in update together, so nothing to do here.
Wow, what a simple and brilliant idea :). I’ll do that. However, how do I mark packages as installed as dependencies? It’s easy to do the opposite, because there is a button in pamac that changes from “installed as dependency” to “installed directly”, but it doesn’t show any option when package is marked as installed directly.
Ah, nevermind, found it:
sudo pacman -D --asdeps package-name
Welp, yolo. I’ll wait for further, more obvious, direct and on point instructions I suppose, if there’s any to provide.
EDIT: OK so, I read a bit in this thread [Unstable Update] March 2024 Edition and read the .pacnew file, and the article on microcodes on Arch Linux wiki (at the same time Yochanan posted it).
But is it really necessary? I don’t think it is a mandatory thing to do for most people and I don’t understand what the panic is about actually and why we are expecting the next unbootable armageddon suddenly. I mean for GRUB users, which is 99% of people on Manjaro will have anyway since it is provided with GRUB by default, the microcode updates are added automatically in the boot process independently of the initramfs and how it has been generated if you have the microcode packages installed on your system, at least according to Arch Wiki and assuming Manjaro’s implementation of GRUB follows the same rule:
-Microcode in a separate initramfs file
Early microcode updates must otherwise be enabled by adding /boot/amd-ucode.img or /boot/intel-ucode.img as the first initrd in the bootloader configuration file. This is before the normal initrd file. See below for instructions for common bootloaders.
In the following sections replace cpu_manufacturer with your CPU manufacturer, i.e. amd or intel.
-GRUB
grub-mkconfig will automatically detect the microcode update and configure GRUB appropriately. After installing the microcode package, regenerate the GRUB configuration to activate loading the microcode update by running:
# grub-mkconfig -o /boot/grub/grub.cfg
Alternatively, users that manage their GRUB configuration file manually can add /boot/cpu_manufacturer-ucode.img (or /cpu_manufacturer-ucode.img if /boot is a separate partition) as follows:
/boot/grub/grub.cfg
...
echo 'Loading initial ramdisk'
initrd /boot/cpu_manufacturer-ucode.img /boot/initramfs-linux.img
...
Repeat it for each menu entry.
As far as I understand it, it only has to be done if one actually desires to add the microcode updates into the initramfs and doesn’t want to have to apply the microcode updates at the boot process separately in the initrd configuration, and doing it twice is pointless. For those specific uses, that would be extremely important to implement the change or else, the microcode updates won’t be applied anymore. But for everyone else? I would not even bother to touch /etc/mkinitcpio.conf in this instance.
The Microcode Arch wiki page was just updated yesterday and is still being improved based on recent upstream and Mkinitcpio changes. 
1 Like
Yup I just read that while editing my post, but after reading it, I have even more doubts that a manual intervention is actually necessary for most people and I don’t get why many people are making a big deal about it.
I found one more thing not working after update to plasma 6.
If you have any Dolphin context menues, they migh have dissapeared but are still visible in the settings of Dolphin.
Re download them from the Dophin settings > context menu > download new services (to download the version ported to plasma 6), in my case it was “open as root”.
Remove the old desktop file in ~/.local/share/kio/servicemenus/ and the menu works again.
It’s necessary for ALL people (that use mkinitcpio at least) regardless of whatever you think. But you can do whatever you want of course. 
Are you able to untick this service menu from Dolphin setting in Context Menu, and can you confirm that unticking it removes the context menu? For me the whole service menu thing is broken I can’t configure service menus, ALL entries show up (example with Root Actions from AUR, or Meld Menu, all their entries show up in context menu when you right click inside a folder).
//EDIT: in the file /home/omano/.config/kservicemenurc I can see my configuration, where all the actions from my service menus are set to FALSE but they still show in Doplhin.
You are correct, it does NOT remove the menu. LOL
The focus I had was to get it to appear.
I will look into if this is reported to kde or not. clearly a bug.
But “open as root” works for me, it asks for password and then opens Dolphin as root.
As for the AUR context menus, they are probably not ported to plasma 6, just as the old “open as root” was not.
Before I installed the ported menu, “open as root” was still showing in the context menu settings in Dolphin, and it was clicked, but the menu was not showing.
So I suspect it somehow accepts the old plasma 5 menus in the settings, but the actual menu (when right clicking) demands ported versions to plasma 6.
Yep the actions themselves work, but you can not hide the actions you do not want to appear in context menu. Thanks for confirming.
For fun, if you want to, try changing the file names from using _ to -, ie cp open_as_root.desktop open-as-root.desktop
Because just as you state, if you open the desktop file, and run the exec line in a terminal, it still worked with the old plasma 5 desktop file.
Hi, yeah my profile is a little misleading currently, I’ll fix that. My desktop-pc is on the testing branch while my laptop is on the stable branch. This issue appeared dicrectly after this update. This is also why I noted this here as an issue/comment, as it might be a correlation instead of a causality.
Edit: Maybe it’s worth to wait for the upcoming gnome release, maybe that helps
Another Edit: I kinda “solved” it by rolling back via timeshift to the previous state, updated again and changed the mkinitcpio.conf like before, rebuild and then rebooted - without issues. Whatever…Guess I was just unlucky and there was a random error while updating.
I have encountered a strange problem with dying X11 server. Added a topic for it: Sometimes X11 server die after left-click after the last update (Maybe Qt problem)
Care to explain? I already made my point earlier but whatever.
Explain what? That occasionally there are manual interventions needed because some logic or whatever of a package changed? Well, there are.
I have same doubt after seeing that in /boot/grub/grub.cfg still have the ucode.img:
initrd /amd-ucode.img /initramfs-6.6-x86_64.img
Is it a duplication?
Another thing I done after this update, like after every update, I examined the terminal output (I use pacman) and I saw for optional packages dependencies and for pacnew files.
After adjusting the mkinitcpio.conf, taking a cue from the pacnew (with the doubt explained before); I saw the /etc/pam.d/kde.pacnew and moved entirely at place of the original file /etc/pam.d/kde. Is it correct? Someone that didn’t change that file had some issues?
lmfao r u srs
That the manual intervention we are talking about is actually relevant or if it’s actually absolutely useless. You don’t ask users to do manual interventions they risk to screw up if it is not a necessity.
Well, yes, if you made the microcode being included in the initramfs, loading the microcode updates in initrd is redundant… If not, well, it’s fine to leave it like that.
I didn’t touch that file and I have nothing to say so far.