No effect ![]()
Ah ha, awesome, thank you @Yochanan !
The issue was not that zoom failed to run or join a meeting under wayland/xwayland… but there was a point-in-time where “sharing” and/or ending sharing under wayland froze zoom… hence the preference for X11 where it worked properly.
Not sure when this sharing issue was fixed in zoom, but glad to see it’s working great again under wayland.
… which is perfectly fine, systemd hook etc. is the new standard but the old can be expected to be still supported for quite a while.
Sigh…I am clearly with stupid the last few days. My udev rule is properly triggering but I had set KDE power management was set to performance…which sets Lowest Non-linear Performance as lower freq…sigh
old post
I ran pacdiff for mkinitprio.conf, merged the changed HOOKS from udev > systemd.
On reboot I noticed the custom udev rule, I am using to (revert) lower AMD idle min frequency down from Lowest Non-linear Performance back to Lowest Performance, was not triggered.
Min freq was at Lowest Non-linear Performance on login, running udevadm trigger triggered the rule.
Reverted my mkinitprio.conf.bak that has udev hook and regenerated mkinitprio. On reboot my custom udev rule now was no longer triggering.
Currently back using systemd hook, but after each reboot I have to manually run udevadm trigger to retrigger the rule to make it work properly.
This is the rule:
cat /etc/udev/rules.d/99-cpufreq-scaling-min-freq.rules
SUBSYSTEM=="cpu", KERNEL=="cpu[0-9]|cpu[0-9][0-9]", ACTION=="add|change", RUN="/usr/bin/bash -c 'echo 545000 > /sys/devices/system/cpu/%k/cpufreq/scaling_min_freq'"
What is going on with this?
8 posts were split to a new topic: Misunderstanding of mkinitcpio pacnew file
System update went fine for me except apparently the power settings got reset somewhere because my laptop sounded like a jet airplane taking off after my first reboot when it was plugged in. Running Gnome, any recommended extensions or applications to control CPU freq?
EDIT - a long time ago the power mode menu disappeared on my system and I had forgotten all about it. Turns out power.profiles.daemon wasn’t installed. Got it running, problem solved
3 posts were split to a new topic: Issues with Signal Desktop
Another problem this update brought - I can’t download or upload files on Tor Browser, the file picker doesn’t come up and crashes it. There’s not even any logs to share, launching from cli and the kernel messages don’t reveal anything.
Hi @Cheker
Check if you have problems with other programs, like Gimp, Thunderbird and Evince. If you do, probably is the same issue related by @jonnyabu (post #158 [Stable Update] 2025-12-08 - 25.1 Anh-Linh Preview - #158 by jonnyabu ). His tip helped me to solve my problems.
5 posts were split to a new topic: Various issues after updating
I am having an issue where power-profiles-daemon is no longer starting via systemd. I confirmed that it was definitely running prior to restarting after the update. I have tried uninstalling and reinstalling, and that didn’t help.
However, I also tried running sudo /usr/lib/power-profiles-daemon -vv which does work.
/usr/lib/systemd/system/power-profiles-daemon.service
[Unit]
Description=Power Profiles daemon
Conflicts=tuned.service tlp.service auto-cpufreq.service system76-power.service
After=multi-user.target display-manager.target
[Service]
Type=dbus
BusName=org.freedesktop.UPower.PowerProfiles
# To enable debugging add a -vv to the ExecStart line
ExecStart=/usr/lib/power-profiles-daemon -vv
Restart=on-failure
# This always corresponds to /var/lib/power-profiles-daemon
StateDirectory=power-profiles-daemon
# Lockdown
CapabilityBoundingSet=CAP_SYS_ADMIN
DevicePolicy=closed
IPAddressDeny=any
KeyringMode=private
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
PrivateDevices=yes
PrivateTmp=yes
PrivateNetwork=yes
PrivateUsers=yes
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectProc=invisible
ProtectSystem=strict
RemoveIPC=yes
RestrictAddressFamilies=AF_UNIX AF_LOCAL AF_NETLINK
MemoryDenyWriteExecute=true
RestrictRealtime=true
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
SystemCallFilter=@system-service
SystemCallFilter=~@resources @privileged
SystemCallErrorNumber=EPERM
SystemCallArchitectures=native
[Install]
WantedBy=graphical.target
System info
Operating System: Manjaro Linux
KDE Plasma Version: 6.5.3
KDE Frameworks Version: 6.20.0
Qt Version: 6.10.1
Kernel Version: 6.12.61-1-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 7640U w/ Radeon 760M Graphics
Memory: 32 GiB of RAM (27.2 GiB usable)
Graphics Processor: AMD Radeon 760M Graphics
Manufacturer: Framework
Product Name: Laptop 13 (AMD Ryzen 7040Series)
System Version: A5
After the update im experience with KDE that my Taskbar Icon’s are smaller then before that update.
Anyone know how to restore or adjust my Taskbar Icon Size?
Were you using X11 before? It may have swapped over to Wayland which scales differently.
10 posts were split to a new topic: Plasma adjust size of icons in Application Launcher
I installed manjaro-kde-25.1-pre1-minimal-251208-linux618.iso on a laptop. I verified the checksums and they checked out. After installation, I was met with a muted audio that can’t be unmuted, and when I checked the logs, I see
pw.conf: could not load mandatory module "libpipewire-module-client-node": No such file or directory
This is a clean install of the ISO. I fixed the issue by doing
# pacman -S libpipewire
Also I noticed a different HOOKS= value in /etc/mkinitcpio.conf on this ISO vs on another laptop where I have installed Manjaro Cinnamon and have updated it to stable-2025-12-08. Both mkinitcpio on the two installs are at version 40-3:
# manjaro-kde
HOOKS=(base udev autodetect microcode kms modconf block keyboard keymap consolefont plymouth filesystems)
# manjaro-cinnamon
HOOKS=(base systemd autodetect microcode modconf kms keyboard keymap sd-vconsole block filesystems fsck)
I’d like to highlight that on both laptops, /etc/mkinitcpio.conf remained stock as distributed by the package. Could anyone tell me why this is the case?
I was surprised that my rolling release wasn’t rolling. Then I found the thread where others were also surprised. Then the tone became harsher and I too became downright indignant that there had been no update for so long. What are they thinking? If there’s no update, then I’ll… yes, they’ll see!
Various posts, written with patience, showed me that a small team invests a lot of time, effort, and personal commitment so that I have had my Manjaro for years. The best operating system I have ever had to date. I was ashamed; few people do so much to ensure that everyone has an up-to-date and stable system, and I took myself so seriously.
That’s why I can’t get behind a rant or lengthy texts about what this team should and shouldn’t do to satisfy this one individual.
Hello.
Update was not successful here.
Same problem of this guy ![]()
Only 1920x1080@60Hz, my monitor is 2560x1080@75Hz.
I’ve tried changing to Nvidia 575, but can’t, give me a message of conflict with actual nvidia.
Since I was stuck, “timeshfited” and I will wait for a solution.
In my reasearch, NVIDIA guys are aware and working in a solution, but for now, there is nothing I can do…
![]()
Let’s call stable branch semi-rolling ![]()
unstable branch updates very, very often - how often is reflected by the package manager’s schedule, how his Arch Linux system reacts to updates and of course the personal life outside Manjaro.
testing branch updates not so often - this is where all the gears are connected - and the motion is checked - is there any crazy sounds from the gearbox, does the current kernel and the Nvidia drivers play nice, is there issues which stable branch users should be spared of - this is where it is decided if and when the branch is ready to go to stable.
A lot of consideration goes into that process - specifically handled by @philm - Philip Müller is to Manjaro what Linux Torvalds is to the kernel - you may not like his wording or what he say - but he is more often right than wrong.
stable branch will roll much, much slower than testing and unstable, appreciate the slower pace… instead of a hasty - update now - many issues can be avoided by due diligence and preparation.
Yes - the inter dependencies can be a pain with Nvidia - and the solution is not always a smooth ride.
But it is doable but you have to resist the urge to reboot.
![]()
How? It just stops and don’t allow me to change the driver version to 575.
Once on the restored snapshot, install the Nouveau driver:
sudo mhwd --install video-linux
and uninstall the Nvidia one:
sudo mhwd --remove video-nvidia
Reboot and retry the other one:
sudo mhwd --install video-nvidia-570xx
That’s the one I’m using at the moment, and all is fine.